Re: [RFC/PATCH] Option to revert order of parents in merge commit
At 09:58 -0800 26 Nov 2012, Junio C Hamano wrote: Kacper Kornet writes: The change of order of parents happens at the very last moment, so "ours" in merge options is local version and "theirs" upstream. That may be something that wants to go to the proposed commit log message. I am neutral on the "feature" (i.e. not against it but not extremely enthusiastic about it either). That should also be included in the (currently nonexistent) documentation of the proposed option. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Option to revert order of parents in merge commit
Kacper Kornet writes: >> Is there any interaction between this "pull --reverse-parents" >> change and possible conflict resolution when the command stops and >> asks the user for help? For example, whom should "--ours" and "-X >> ours" refer to? Us, or the upstream? > > The change of order of parents happens at the very last moment, so > "ours" in merge options is local version and "theirs" upstream. That may be something that wants to go to the proposed commit log message. I am neutral on the "feature" (i.e. not against it but not extremely enthusiastic about it either). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Option to revert order of parents in merge commit
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote: > Kacper Kornet writes: > > The following patch is an attempt to implement this idea. > I think "revert" is a wrong word (implying you have already done > something and you are trying to defeat the effect of that old > something), and you meant to say "reverse" (i.e. the opposite of > normal) or something. You are right. Probably transpose is the best description what the patch really does. > I am unsure about the usefulness of this, though. > After completing a topic on branch A, you would merge it to your own > copy of the integration branch (e.g. 'master') and try to push, > which may be rejected due to non-fast-forwardness: > $ git checkout master > $ git merge A > $ git push > At that point, if you _care_ about the merge parent order, you could > do this (still on 'master'): > $ git fetch origin > $ git reset --hard origin/master > $ git merge A > $ test test test > $ git push > With --reverse-parents, it would become: > $ git pull --reverse-parents > $ test test test > $ git push > which certainly is shorter and looks simpler. The workflow however > would encourage people to work directly on the master branch, which > is a bit of downside. Our developers work mainly on master branches. The project consists of many thousands independent git repositories, and at the given time a developer usually wants to make only one commit in the given repository and push his changes upstream. So he usually doesn't care to make a branch. Then after failed pushed, one needs to add creation and removal of temporary branch (see the commit message of the suggested patch). The possibility to do git pull --reverse-parent would make the life easier in this case. > Is there any interaction between this "pull --reverse-parents" > change and possible conflict resolution when the command stops and > asks the user for help? For example, whom should "--ours" and "-X > ours" refer to? Us, or the upstream? The change of order of parents happens at the very last moment, so "ours" in merge options is local version and "theirs" upstream. -- Kacper Kornet -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Option to revert order of parents in merge commit
Kacper Kornet writes: > The following patch is an attempt to implement this idea. I think "revert" is a wrong word (implying you have already done something and you are trying to defeat the effect of that old something), and you meant to say "reverse" (i.e. the opposite of normal) or something. I am unsure about the usefulness of this, though. After completing a topic on branch A, you would merge it to your own copy of the integration branch (e.g. 'master') and try to push, which may be rejected due to non-fast-forwardness: $ git checkout master $ git merge A $ git push At that point, if you _care_ about the merge parent order, you could do this (still on 'master'): $ git fetch origin $ git reset --hard origin/master $ git merge A $ test test test $ git push With --reverse-parents, it would become: $ git pull --reverse-parents $ test test test $ git push which certainly is shorter and looks simpler. The workflow however would encourage people to work directly on the master branch, which is a bit of downside. Is there any interaction between this "pull --reverse-parents" change and possible conflict resolution when the command stops and asks the user for help? For example, whom should "--ours" and "-X ours" refer to? Us, or the upstream? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
