Re: Can git tell me which uncommitted files clash with the incoming changes?
- Date: Mon, 17 Dec 2018 14:35:14 -0500
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Can git tell me which uncommitted files clash with the incoming changes?
On Mon, Dec 17, 2018 at 07:49:00PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > 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
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.