Re: who's on first? - following first parent and merge-management

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".