Re: Merge priority

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

 



Alex Riesen <raa.lkml@xxxxxxxxx> writes:

> You can take a look at rerere, though. It should help resolving repeating
> conflicts  by recording a resolution of your choice.

Use of rerere often helps but there is a caveat.

Even if two branches (e.g. 'master' and 'maint') currently has the same
tree, the desired outcome of merging the same commit into them could be
different depending on the purpose of these branches.  You may want to
resolve a conflicted merge into 'maint' more conservatively than the way
you would resolve the exact same merge into 'master'.

Imagine a case where 'master' branch added a better helper functions in
other files, but they are not in 'maint' yet, and the conflicted part
could be resolved better if you made it call these newer helper functions
available only in 'master'.

Unfortunately the conflicts would look exactly the same to rerere, so if
you record the result of the merge to 'master', replaying that resolution
while merging the same commit to 'maint' would produce undesirable result.

As to "does the aggregated result make sense if you blindly add changes in
'stable' for only conflicted parts to an automerge result?", which was
your other point, you may refer your readers to Avery's recent updates to
resurrect -Xours option to "git merge".
--
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]