Re: Distinguishing trivial and non-trivial merge commits

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

 



Eli Barzilay <eli@xxxxxxxxxxxx> writes:

> Good -- the first paragraph is what I thought it would do, the second
> makes it even better.  Perhaps it would be nice to show such manual
> reoslutions from one parent, but I think that that certainly qualifies
> as stuff that is much less interesting than work that was done to
> combine content inside a file, or one of those evil merges.

You need to be careful here.

If you see a conflicted hunk and the result ends up being the same from
one of the parents in that area, then the _result_ is trivial as far as
the merge (and hence --cc) is concerned, even though you may have spent
considerable braincycle to stare at the conflict to decide that taking a
change from one side is the right thing to do.

You keep saying "manual resolutions", but --cc doesn't have much to do
with the resolution being manual, nor if the initial mechanical merge
attempt left conflict markers.  You would need to redo the merge to find
that out, and it can be fairly cheaply done with a temporary index and an
empty temporary working tree elsewhere in the filesystem.

--
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]