From: Junio C Hamano <hidden> Date: 2016-06-15 22:53:15
Johannes Sixt [off-list ref] writes:
I have wished for such a thing several times already.
It happens when I have a topic with changes that trigger a complete
rebuild of the project. When I merge it to master, I have to
# on topic
git checkout master #1
git merge topic #2
#1 triggers a rebuild, but I don't do a build. Then #2 again triggers a
rebuild, but in reality the only changes since the last build are those
from master since the topic forked (no, I can't use ccache).
To avoid the situation,...
This would not be necessary if the order of the merge parents could be
specified, e.g.:
# on topic
git merge --into master
I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.
With the "crazy idea", you merge the other branch that happened to
be the mainline into your work in reverse. You would explain such a
merge as "I am merging early part of my topic that will eventually
do X to mainline now, to make later conflict resolution easier, even
though it is not yet complete" or something like that, and you will
continue working on your topic starting from the resulting merge.
The real project mainline will not be updated with this merge until
the topic is complete (in other words, you do not push).
I have a feeling that your "git merge-to master" may be different.
You may explain the resulting commit as "This topic is complete for
now and is ready for master", and the master gets updated with the
result, but you may want to keep "topic" free of unrelated random
other development that happened on "master" since they diverged.
That way, "topic" can further be polished and you will leave the
door open to merge it down to even older releases than "master".
To avoid the situation,...
This would not be necessary if the order of the merge parents could be
specified, e.g.:
# on topic
git merge --into master
I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.
I don't think there is much question that you should still be in the
same branch. Not because you necessarily want to be in that branch. But
because it would be surprising if git-merge changed your branch
sometimes and most times not.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:53:15
Am 3/9/2012 13:05, schrieb Holger Hellmuth:
On 08.03.2012 18:30, Junio C Hamano wrote:
quoted
Johannes Sixt[off-list ref] writes:
quoted
To avoid the situation,...
This would not be necessary if the order of the merge parents could be
specified, e.g.:
# on topic
git merge --into master
I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.
I don't think there is much question that you should still be in the same
branch. Not because you necessarily want to be in that branch. But because
it would be surprising if git-merge changed your branch sometimes and most
times not.
I don't think that it is so clear-cut. And for this reason, I would even
go as far as to suggest that you should end up with a detached HEAD.
Before the merge we have this situation:
--o--o--o--o <- master
\
o--o--o--X <- topic
The result of 'git merge --into master' must advance branch master by the
merge commit (I think there is no doubt about this):
--o--o--o--o---M <- master
\ /
o--o--o--X <- topic
Also, the index and worktree must match M (no doubt, either, IMO). But
what does HEAD refer to? I see three possibilities:
1. master; as you say, this may be surprising if we were on topic before
the branch.
2. topic; but then the index would be dirty because it does not match X.
3. M, i.e. a detached HEAD; this is just a compromise and a fat warning at
the end of the merge output would be necessary that instructs the user to
checkout a suitable branch.
Now that I have tossed around these ideas, there's another caveat: What if
the merge fails due to a conflict? After the conflicts were resolved, 'git
commit' is needed to complete the merge. But this would create the commit
where HEAD points to. IOW, we have to chose option 1 so that the merge
commit advances master.
Would this be less surprising if the option were named --checkout-into?
-- Hannes
To avoid the situation,...
This would not be necessary if the order of the merge parents could be
specified, e.g.:
# on topic
git merge --into master
I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.
I don't think there is much question that you should still be in the same
branch. Not because you necessarily want to be in that branch. But because
it would be surprising if git-merge changed your branch sometimes and most
times not.
I don't think that it is so clear-cut. And for this reason, I would even
go as far as to suggest that you should end up with a detached HEAD.
Before the merge we have this situation:
--o--o--o--o<- master
\
o--o--o--X<- topic
The result of 'git merge --into master' must advance branch master by the
merge commit (I think there is no doubt about this):
--o--o--o--o---M<- master
\ /
o--o--o--X<- topic
Also, the index and worktree must match M (no doubt, either, IMO). But
what does HEAD refer to? I see three possibilities:
I see we have different ideas. I envisioned --into to be the equivalent of
git checkout master
git merge topic
git checkout topic
and in that case index and worktree would be topic naturally.
But your caveat below would be even more problematic in this case.
1. master; as you say, this may be surprising if we were on topic before
the branch.
2. topic; but then the index would be dirty because it does not match X.
3. M, i.e. a detached HEAD; this is just a compromise and a fat warning at
the end of the merge output would be necessary that instructs the user to
checkout a suitable branch.
Now that I have tossed around these ideas, there's another caveat: What if
the merge fails due to a conflict? After the conflicts were resolved, 'git
commit' is needed to complete the merge. But this would create the commit
where HEAD points to. IOW, we have to chose option 1 so that the merge
commit advances master.
Would this be less surprising if the option were named --checkout-into?
Don't think so. It would make it clear where you end up but it would
muddle/hide the original purpose of the parameter. "git merge --into
xxx" sounds like a real sentence (Larry Wall would approve ;-).
Guess we would have to rely on the documentation to make it clear that a
branch switch happens. And a message "Changing to branch xxx" on STDOUT
wouldn't hurt either.