Re: Can git tell me which uncommitted files clash with the incoming changes?

From: Jeff King <peff@peff.net>
Date: Dec 17, 2018, 19:35 UTC
Message-ID: <20181217193514.GB9853@sigill.intra.peff.net>
In-Reply-To: <877eg80z1f.fsf@evledraar.gmail.com>

On Mon, Dec 17, 2018 at 07:49:00PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 11 quoted lines

> > The answer that gives will be overly broad (e.g., in a case where our
> > local branch had touched file "foo" but other side had not, we'd
> > consider "foo" as a difference the two-point diff-tree, whereas a real
> > 3-way merge would realize that we'd keep our version of "foo"). But it
> > might be good enough for your purposes.
> 
> Isn't this done more simply with just running the merge with
> git-merge-tree? Maybe I'm missing something. E.g. earlier I had a
> conflict between a WIP series of mine in next in
> parse-options-cb.c. Just using git-merge-tree and grepping for conflict
> markers gives me what conflicted:

I forgot about the existence of merge-tree (though TBH I don't have a huge amount of faith in antique plumbing tools like that that very few people actually run these days).

It won't look at the working tree at all, but it could be used instead of diff-tree to find the set of touched paths, and then that can be correlated with the diff-files output. We'd want to see all paths, not just conflicted ones, so you'd have to be a little fancy with the parsing.

It's also not _quite_ the same as what git-pull is doing to merge, since merge-recursive does fancy stuff like renames. But the distinction would probably be OK for casual use.

-Peff