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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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 unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]