Re: how do you review auto-resolved files

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 21, 2012, 23:52 UTC
Message-ID: <7vobsreocm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <ji0vik$e48$1@dough.gmane.org>

"Neal Kreitzinger" <neal@rsss.com> writes:

Show 13 quoted lines

> If I expect/assume you are going to review the 
> auto-resolutions after-the-fact then you can neglect this because you:
>
>   - have become complacent that git usually does-what-you-want so "you don't 
>     really need to do it",
>   - are lazy and do it half-way,
>   - forget to do it,
>   - think "git magically does your work for you",
>   - don't know how to do it,
>   - don't even realize that anything auto-resolved or what auto-resolved,
>   - decide you don't have to do it because that is what testing if for,
>   - you think that your time is so valuable that an ounce-of-prevention on 
>     your part is not worth a pound-of-cure on the part of others.

A couple more bullet points I can think of off the top of my head, after making sure that you do not count what "rerere" does as part of the "auto-resolution", to add to the above list are:

 - know git is stupid and errs on the safe side, punting anything remotely
   complex;

 - know that textual non-conflicts that occur in the same file have the
   same risk of having semantic conflict across different files, so
   singling out "touched the same file but did not conflict" any special
   is pointless, but in either case, the chance of having such a conflict
   is small enough that completing the merge (and other merges) first and
   then checking the overall result is more efficient use of your time,
   because you have to eyeball the result at least once anyway before
   pushing it out.