You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Darryl L. Pierce" <dp...@redhat.com> on 2014/12/11 17:30:29 UTC
Fixing the merge commit in the git repo?
Would it be possible for someone (Rafi?) to fix the merge commits in the
Git repo? I'm working on some stuff and, when I tried to do a rebase I
accidentally went a few commits further back and git wanted to then
rebase 65 commits...
On our individual ends, once it's done, we should be able to just do:
$ git pull --rebase
and have our individual repos fixed as a result.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
If you pushed invalid commits the easier way is to revert them.
If you really want commits out then you will need someone from infra to push -f as forced is disabled at Apache repos.
> On Dec 11, 2014, at 15:36, Rafael Schloming <rh...@alum.mit.edu> wrote:
>
> Can you provide a bit more detail? I'm not the most expert git user, so I'm
> not sure exactly what you're asking for, much less how to do it.
>
> --Rafael
>
> On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce <dp...@redhat.com>
> wrote:
>>
>> Would it be possible for someone (Rafi?) to fix the merge commits in the
>> Git repo? I'm working on some stuff and, when I tried to do a rebase I
>> accidentally went a few commits further back and git wanted to then
>> rebase 65 commits...
>>
>> On our individual ends, once it's done, we should be able to just do:
>>
>> $ git pull --rebase
>>
>> and have our individual repos fixed as a result.
>>
>> --
>> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
>> Delivering value year after year.
>> Red Hat ranks #1 in value among software vendors.
>> http://www.redhat.com/promo/vendor/
>>
>>
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
> On Dec 12, 2014, at 9:57 AM, Darryl L. Pierce <dp...@redhat.com> wrote:
>
> On Fri, Dec 12, 2014 at 09:48:05AM -0500, Clebert Suconic wrote:
>> In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys.
>
> I feel like my comment, which was just a joke, might have been taken the
> wrong way. For that I apologize…
Not at all… I was answering based at a later point you mentioned that PRs were considered and decided against.
Anyways.. I’m just trying to help you guys and bring you some POV from us since we have been using git longer than you guys…
You guys know where to find me if you want to have a chat about it.
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Dec 12, 2014 at 09:48:05AM -0500, Clebert Suconic wrote:
> In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys.
I feel like my comment, which was just a joke, might have been taken the
wrong way. For that I apologize...
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
> On Dec 12, 2014, at 9:38 AM, Darryl L. Pierce <dp...@redhat.com> wrote:
>
> On Fri, Dec 12, 2014 at 01:43:45PM +0000, Gordon Sim wrote:
>> On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
>>> I like the idea of pull requests and explicit peer reviews for changes.
>>> But it's above my pay grade to do anything more than envy such a work
>>> flow. :D
>>
>> Pay grade isn't relevant on an Apache project.
>
> I was being facetious. I had mentioned pull requests a while back and
> got the response that (at least then) it wasn't being considered.
In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys.
this has been working very well for us… it has even increased our productivity instead of being an extra step…
For instance… I just captured an error from Andy Taylor on this PR: https://github.com/apache/activemq-6/pull/43 <https://github.com/apache/activemq-6/pull/43>… he then fixed now we are ready to merge it
You could even setup automated builds for PRs. and it’s quite easy to do it. no more breaking the build for instance!
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
> On Dec 12, 2014, at 11:44 AM, Gordon Sim <gs...@redhat.com> wrote:
>
> On 12/12/2014 02:38 PM, Darryl L. Pierce wrote:
>> On Fri, Dec 12, 2014 at 01:43:45PM +0000, Gordon Sim wrote:
>>> On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
>>>> I like the idea of pull requests and explicit peer reviews for changes.
>>>> But it's above my pay grade to do anything more than envy such a work
>>>> flow. :D
>>>
>>> Pay grade isn't relevant on an Apache project.
>>
>> I was being facetious.
>
> I was being pompous.
Is it Friday yet?
Better: is it Xmas break yet?
Re: Fixing the merge commit in the git repo?
Posted by Gordon Sim <gs...@redhat.com>.
On 12/12/2014 02:38 PM, Darryl L. Pierce wrote:
> On Fri, Dec 12, 2014 at 01:43:45PM +0000, Gordon Sim wrote:
>> On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
>>> I like the idea of pull requests and explicit peer reviews for changes.
>>> But it's above my pay grade to do anything more than envy such a work
>>> flow. :D
>>
>> Pay grade isn't relevant on an Apache project.
>
> I was being facetious.
I was being pompous.
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Dec 12, 2014 at 01:43:45PM +0000, Gordon Sim wrote:
> On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
> >I like the idea of pull requests and explicit peer reviews for changes.
> >But it's above my pay grade to do anything more than envy such a work
> >flow. :D
>
> Pay grade isn't relevant on an Apache project.
I was being facetious. I had mentioned pull requests a while back and
got the response that (at least then) it wasn't being considered.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Gordon Sim <gs...@redhat.com>.
On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
> I like the idea of pull requests and explicit peer reviews for changes.
> But it's above my pay grade to do anything more than envy such a work
> flow. :D
Pay grade isn't relevant on an Apache project.
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 11, 2014 at 06:47:06PM -0500, Clebert Suconic wrote:
> We do a slightly different approach. If you guys are doing git I really think you guys should consider it.
> > 1. create a task branch : git checkout -b my-working-branch
> > 2. create that voodoo that you do
> > 3. when done, rebase your task branch on master : git rebase -i master
>
> 4. push to your github fork
> 5. send a github Pull Request towards the github fork of the apache project
>
> 6. Someone else (yeah… someone who was not the original committer) should merge it after review
>
> 7 That someone else will do: git merge --no-ff github/pr/PRNumber
> ( We ellected to have merge committs with our committs, so we always have two people to blame in case things go wrong)
>
> If you elect to not have the merge commit like we have, you can simply use git pull.. and that should presever the Hashes from the original commit.
>
> 8. The apache bot will close the PR unless you rebased the commit (which you are not supposed to)
>
>
>
> Why we do that?
>
>
> I - to avoid merge errors like it just happened
> II - it increases community
> iii - we have a theory that everyone will do stupid things eventually... this is an extra layer of protection :)
>
>
> You could look at our README for more information: We are still getting started with it and we have based this on how other apache projects are using git and github:
>
>
> https://github.com/apache/activemq-6/blob/master/README.md
I like the idea of pull requests and explicit peer reviews for changes.
But it's above my pay grade to do anything more than envy such a work
flow. :D
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
We do a slightly different approach. If you guys are doing git I really think you guys should consider it.
> 1. create a task branch : git checkout -b my-working-branch
> 2. create that voodoo that you do
> 3. when done, rebase your task branch on master : git rebase -i master
4. push to your github fork
5. send a github Pull Request towards the github fork of the apache project
6. Someone else (yeah… someone who was not the original committer) should merge it after review
7 That someone else will do: git merge --no-ff github/pr/PRNumber
( We ellected to have merge committs with our committs, so we always have two people to blame in case things go wrong)
If you elect to not have the merge commit like we have, you can simply use git pull.. and that should presever the Hashes from the original commit.
8. The apache bot will close the PR unless you rebased the commit (which you are not supposed to)
Why we do that?
I - to avoid merge errors like it just happened
II - it increases community
iii - we have a theory that everyone will do stupid things eventually... this is an extra layer of protection :)
You could look at our README for more information: We are still getting started with it and we have based this on how other apache projects are using git and github:
https://github.com/apache/activemq-6/blob/master/README.md
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
> Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us.
>
> Committing directly to Apachea may get you these issues.
>
> We can provide you guys more information on how we are doing on activemq6 if you are interested.
So if we don't want to go back and fix history (which is fine) can we
take steps to avoid pushing merge commits in future? It's just an ugly
and confusing situation to get into with them.
For anybody who's not familiar with a good git workflow:
1. create a task branch : git checkout -b my-working-branch
2. create that voodoo that you do
3. when done, rebase your task branch on master : git rebase -i master
4. checkout master and merge : git checkout master; git merge my-working-branch
5. make sure master is up to date : git pull --rebase
6. push your changes
7. profit!
This way we don't have those ugly diamonds in the gitg graph and issues
like this in future.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 11, 2014 at 07:19:13PM -0500, Clebert Suconic wrote:
> Right but you can’t ever push -f on an apache branch. you can rebase as much as you like .. and it’s awesome I agree…
> But others would lose reference if you rebased and pushed -f.. that’s why it’s forbidden at the apache git.
>
> And that’s why we are very careful on merging commits.
I agree, as it can cause issues for someone who wasn't expecting history
to have been fixed.
Way back in the day, on a previous project, we had a commit hook that
would reject merge commits, forcing the developer to fix their history
before pushing anything. Does Apache support such hooks in projects?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
> On Dec 11, 2014, at 5:11 PM, Darryl L. Pierce <dp...@redhat.com> wrote:
>
> On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
>> Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us.
>>
>> Committing directly to Apachea may get you these issues.
>>
>> We can provide you guys more information on how we are doing on activemq6 if you are interested.
>
> Additionally, while working on a task branch, to resynch with master do
> a rebase:
>
> $ rebase -i master
>
> rather than merging master down onto your task branch. I saw a *lot* of
> that while examining the merge commits. Rebasing is by far one of the
> most awesome features of git.
Right but you can’t ever push -f on an apache branch. you can rebase as much as you like .. and it’s awesome I agree…
But others would lose reference if you rebased and pushed -f.. that’s why it’s forbidden at the apache git.
And that’s why we are very careful on merging commits.
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
> On Dec 12, 2014, at 2:44 PM, Andrew Stitcher <as...@redhat.com> wrote:
>
> On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote:
>>> ..
>>> On the other hand I agree that merging from master just before merging
>>> to master is irritating and pointless.
>>
>> The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it.
>
> I think you are misinterpreting what I said (not that it matters, but it
> is Friday) - merging from master doesn't imply any sort of rebasing. In
> some recent merges to master there is an immediately previous merge from
> master to the topic branch, that is what is unnecessary - because you
> only need to merge to your local master then push that.
Sure of course… I was just referring that you can’t push -f on apache/master… so you are limited to how much rebasing you can do before pushing into apache copy/master.
Re: Fixing the merge commit in the git repo?
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote:
> > ..
> > On the other hand I agree that merging from master just before merging
> > to master is irritating and pointless.
>
> The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it.
I think you are misinterpreting what I said (not that it matters, but it
is Friday) - merging from master doesn't imply any sort of rebasing. In
some recent merges to master there is an immediately previous merge from
master to the topic branch, that is what is unnecessary - because you
only need to merge to your local master then push that.
Andrew
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
>
> I agree and disagree with this simplistic position.
>
> If (and only if) your task branch is yours and yours alone and no one
> has ever relied on it then you can safely rebase it. Actually I find
> that rebasing is a lot more useful to get my commits in a logical
> sequence of smaller working commits (by using rebase -i).
>
+1 … Yes.. as I said earlier.. you can rebase your branch as much as you want.
> On the other hand merging topic branches into master is also perfectly
> sensible to finish off work on a topic branch especially a long lived
> one.
+1. That’s why I’m suggesting the PR approach.
>
> A long lived topic branch will necessarily have some level of merging
> from master to keep it up to date.
>
> On the other hand I agree that merging from master just before merging
> to master is irritating and pointless.
The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it.
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Dec 12, 2014 at 02:15:21PM -0500, Andrew Stitcher wrote:
> On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote:
> > Additionally, while working on a task branch, to resynch with master do
> > a rebase:
> >
> > $ rebase -i master
> >
> > rather than merging master down onto your task branch. I saw a *lot* of
> > that while examining the merge commits. Rebasing is by far one of the
> > most awesome features of git.
>
> I agree and disagree with this simplistic position.
>
> If (and only if) your task branch is yours and yours alone and no one
> has ever relied on it then you can safely rebase it. Actually I find
> that rebasing is a lot more useful to get my commits in a logical
> sequence of smaller working commits (by using rebase -i).
Sorry, I should have clarified that this is my assumption, that a task
branch is a private branch that you are working on and not one you're
sharing with others.
> On the other hand merging topic branches into master is also perfectly
> sensible to finish off work on a topic branch especially a long lived
> one.
>
> A long lived topic branch will necessarily have some level of merging
> from master to keep it up to date.
>
> On the other hand I agree that merging from master just before merging
> to master is irritating and pointless.
>
> Andrew
>
>
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2014-12-12 at 14:37 -0500, Rafael Schloming wrote:
> ...
> > On the other hand I agree that merging from master just before merging
> > to master is irritating and pointless.
>
>
> So what was the right thing to do here? I have to admit I struggled a bit
> with the git portion of getting the whole thing landed. The changes were
> (mostly) isolated to a subdirectory, yet whatever git incantations I seemed
> to come up with forced me to painstakingly hand merge lots of conflicts
> over and over again. What I ended up doing was mostly stumbled into in an
> attempt to avoid all that grunge.
It's difficult to say, however I'm surprised that merging from master
saved you from the same manual merges you needed to do going the other
way.
Perhaps the history was complex and confused git - I think that merging
from branches with complex structures might need a non default merge
strategy "man git-merge" has some details.
Andrew
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Dec 12, 2014 at 02:37:53PM -0500, Rafael Schloming wrote:
> So what was the right thing to do here? I have to admit I struggled a bit
> with the git portion of getting the whole thing landed. The changes were
> (mostly) isolated to a subdirectory, yet whatever git incantations I seemed
> to come up with forced me to painstakingly hand merge lots of conflicts
> over and over again. What I ended up doing was mostly stumbled into in an
> attempt to avoid all that grunge.
Yeah, that's because there were several spots where master was merged
into the javascript branch. So all of the changes that lived in master
were already present in javascript (as a part of those merges) but were
not in the same deltas as they live on master. So git was seeing the
same changes show up in multiple separate commits and needed someone
else to decide which was the right one.
That's why rebasing your task branch in git is the Right Way(tm) to
prepare a task branch for merging up to master.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Dec 12, 2014 at 2:15 PM, Andrew Stitcher <as...@redhat.com>
wrote:
>
> On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote:
> > On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
> > > Rebasing and pushing is not a good option IMO. We have been using pull
> requests from GitHub and pushing them through Apache. It's working very
> well for us.
> > >
> > > Committing directly to Apachea may get you these issues.
> > >
> > > We can provide you guys more information on how we are doing on
> activemq6 if you are interested.
> >
> > Additionally, while working on a task branch, to resynch with master do
> > a rebase:
> >
> > $ rebase -i master
> >
> > rather than merging master down onto your task branch. I saw a *lot* of
> > that while examining the merge commits. Rebasing is by far one of the
> > most awesome features of git.
>
> I agree and disagree with this simplistic position.
>
> If (and only if) your task branch is yours and yours alone and no one
> has ever relied on it then you can safely rebase it. Actually I find
> that rebasing is a lot more useful to get my commits in a logical
> sequence of smaller working commits (by using rebase -i).
>
> On the other hand merging topic branches into master is also perfectly
> sensible to finish off work on a topic branch especially a long lived
> one.
>
> A long lived topic branch will necessarily have some level of merging
> from master to keep it up to date.
>
> On the other hand I agree that merging from master just before merging
> to master is irritating and pointless.
So what was the right thing to do here? I have to admit I struggled a bit
with the git portion of getting the whole thing landed. The changes were
(mostly) isolated to a subdirectory, yet whatever git incantations I seemed
to come up with forced me to painstakingly hand merge lots of conflicts
over and over again. What I ended up doing was mostly stumbled into in an
attempt to avoid all that grunge.
--Rafael
Re: Fixing the merge commit in the git repo?
Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote:
> On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
> > Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us.
> >
> > Committing directly to Apachea may get you these issues.
> >
> > We can provide you guys more information on how we are doing on activemq6 if you are interested.
>
> Additionally, while working on a task branch, to resynch with master do
> a rebase:
>
> $ rebase -i master
>
> rather than merging master down onto your task branch. I saw a *lot* of
> that while examining the merge commits. Rebasing is by far one of the
> most awesome features of git.
I agree and disagree with this simplistic position.
If (and only if) your task branch is yours and yours alone and no one
has ever relied on it then you can safely rebase it. Actually I find
that rebasing is a lot more useful to get my commits in a logical
sequence of smaller working commits (by using rebase -i).
On the other hand merging topic branches into master is also perfectly
sensible to finish off work on a topic branch especially a long lived
one.
A long lived topic branch will necessarily have some level of merging
from master to keep it up to date.
On the other hand I agree that merging from master just before merging
to master is irritating and pointless.
Andrew
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
> Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us.
>
> Committing directly to Apachea may get you these issues.
>
> We can provide you guys more information on how we are doing on activemq6 if you are interested.
Additionally, while working on a task branch, to resynch with master do
a rebase:
$ rebase -i master
rather than merging master down onto your task branch. I saw a *lot* of
that while examining the merge commits. Rebasing is by far one of the
most awesome features of git.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Clebert Suconic <cs...@redhat.com>.
Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us.
Committing directly to Apachea may get you these issues.
We can provide you guys more information on how we are doing on activemq6 if you are interested.
> On Dec 11, 2014, at 16:13, Darryl L. Pierce <dp...@redhat.com> wrote:
>
>> On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote:
>> Can you provide a bit more detail? I'm not the most expert git user, so I'm
>> not sure exactly what you're asking for, much less how to do it.
>
> In my case, my usual workflow is to do small changes and commit them
> locally. If a change goes with a commit a few back I'll do:
>
> $ git commit -a --fixup=[early commit's hash]
>
> Then, when I'm ready to commit I'll do:
>
> $ git rebase -i HEAD~[# of commits to process] --autosquash
>
> and git will put the commits in the right order so I can squash them
> down.
>
> Normally I just do "HEAD~25" rather than counting the commits since we
> usually had a nice, linear stream of commits in our old repo that was
> cloned from Subversion. But when I did it this time that the commits
> overlapped with this merge commit:
>
> ===[snip]===
> commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb
> Merge: db437cf a5cb27e
> Author: Rafael Schloming <rh...@alum.mit.edu>
> Date: Fri Nov 28 08:43:03 2014 -0500
>
> Merge branch 'javascript'
> ===[snip]===
>
> This made git them try to rebase all of those changes, which numbered up
> to about 60 or so commits that are out of sequence. So I had to abort
> that rebase and count the commits instead and do it again.
>
> When merging branches, etc. we can avoid this if, before merging branch
> A into master we go to branch A and rebase it on master. That way we
> avoid merge commits like this.
>
> To fix it, you would need to:
>
> 1. git rebase -i HEAD~[# of commits to the merge above]
> 2. when it pops up the list of commits, just save (you're not going to
> re-order them at that point)
> 3. check for any merge commits, dual adds or deletes with "git status"
> 4. fix any issues that you see: fix merges, etc.
> 5. git add (or del) files as needed
> 6. git rebase --continue
> 7. go to 3 as needed until all is fixed
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
Re: Fixing the merge commit in the git repo?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote:
> Can you provide a bit more detail? I'm not the most expert git user, so I'm
> not sure exactly what you're asking for, much less how to do it.
In my case, my usual workflow is to do small changes and commit them
locally. If a change goes with a commit a few back I'll do:
$ git commit -a --fixup=[early commit's hash]
Then, when I'm ready to commit I'll do:
$ git rebase -i HEAD~[# of commits to process] --autosquash
and git will put the commits in the right order so I can squash them
down.
Normally I just do "HEAD~25" rather than counting the commits since we
usually had a nice, linear stream of commits in our old repo that was
cloned from Subversion. But when I did it this time that the commits
overlapped with this merge commit:
===[snip]===
commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb
Merge: db437cf a5cb27e
Author: Rafael Schloming <rh...@alum.mit.edu>
Date: Fri Nov 28 08:43:03 2014 -0500
Merge branch 'javascript'
===[snip]===
This made git them try to rebase all of those changes, which numbered up
to about 60 or so commits that are out of sequence. So I had to abort
that rebase and count the commits instead and do it again.
When merging branches, etc. we can avoid this if, before merging branch
A into master we go to branch A and rebase it on master. That way we
avoid merge commits like this.
To fix it, you would need to:
1. git rebase -i HEAD~[# of commits to the merge above]
2. when it pops up the list of commits, just save (you're not going to
re-order them at that point)
3. check for any merge commits, dual adds or deletes with "git status"
4. fix any issues that you see: fix merges, etc.
5. git add (or del) files as needed
6. git rebase --continue
7. go to 3 as needed until all is fixed
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
Can you provide a bit more detail? I'm not the most expert git user, so I'm
not sure exactly what you're asking for, much less how to do it.
--Rafael
On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce <dp...@redhat.com>
wrote:
>
> Would it be possible for someone (Rafi?) to fix the merge commits in the
> Git repo? I'm working on some stuff and, when I tried to do a rebase I
> accidentally went a few commits further back and git wanted to then
> rebase 65 commits...
>
> On our individual ends, once it's done, we should be able to just do:
>
> $ git pull --rebase
>
> and have our individual repos fixed as a result.
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: Fixing the merge commit in the git repo?
Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2014-12-11 at 11:30 -0500, Darryl L. Pierce wrote:
> Would it be possible for someone (Rafi?) to fix the merge commits in the
Short answer is no!
I think you are asking for master's history to be changed and that is:
1) Not possible (fortunately) as the repo is locked down.
2) Not desirable, as you would screw up far more than you would fix.
If your workflow relies on a simpler master structure I'm afraid you
will just have to change your workflow.
Andrew