Re: how do you review auto-resolved files

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

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

Show 5 quoted lines

> When git does a merges (merge/rebase/cherry-pick) it auto-resolves same-file 
> changes that do not conflict on the same line(s).
>
> Technical Question:  What are the recommended commands for reviewing the 
> files that auto-resolved after a "merge"?

Imagine that you are the maintainer of the mainline and are reviewing the work made on a side branch that you just merged, but pretend that the contribution came as a patch instead. How would you assess the damage to your mainline?

You would use "git show --first-parent $commit" for that.

And then look at what the sideline wanted to do to the old baseline:

	git log -p $commit^..$commit

which would, unless the person who worked on the side branch did a shoddy job describing his work, explain what the side branch wanted to achieve and also _how_ it wanted to achieve it.

And then re-read the first "git show" output with that knowledge, together with the knowledge you have on your mainline codebase, and decide if the solution used by the side branch is still valid. If it makes sense, you are done. If the advance in your mainline since the side branch forked invalidated some assumption the side branch made (e.g. a helper function the side branch used has changed its meaning, a helper function the side branch changed its meaning gained more callsite on the mainline, etc.), you have a semantic conflict that you would need to address.

It is unclear what exactly you consider "auto-resolve" in your message, so I'd refrain from commenting on the "Philosophical" part, at least for now.