Re: [PATCH] xdl_merge(): fix and simplify conflict handling

From: Junio C Hamano <junkio@cox.net>
Date: Dec 5, 2006, 22:54 UTC
Message-ID: <7v3b7ueyxc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0612052320320.28348@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Speaking about a builtin merge: I like the fact that git-apply also works 
> outside of git repositories. It makes life easier to have a sane patcher 
> around.

Well, git-apply is designed as a better "patch", so it is natural that it works in a non-git directory [*1*].

I am not sure what you mean by a builtin merge that works outside the context of git. Do you mean a pure RCS merge replacement that takes three files and spits out the result in one of them? If so that would probably deserve to be a separate command, because I do not think of a use for such a thing inside git. We've done merge-recursive.c already so it would not need an external 'merge'. If somebody is so inclined to to do the "merge-resolve" strategy, I think the right way is to make a single program that does what git-merge-index and merge-one-file does without fork nor exec, so it would not need an external 'merge' either.

> Now, I'd like the same with git-diff, and an RCS merge replacement...

Yes, back when I was actively hacking git-diff, I dreamt about a variant that takes two or more (non-git managed) directories and does an equivalent of diff-tree with -M/-C/.../-c/--cc. It would be cool and useful.

I understand your aversion to new commands, but I do not think you can avoid it if what you mean is an RCS merge replacement.

The diff that works on "two or more directories without anything git" could be just a new option to "git diff", though.

But I am not going to do it myself; it's usually a lot faster for me to just do "git init-db; git add . " on an extracted tarball.

[Footnote]

*1* ... and that is one of the reasons why it does not even try to read the index unless it is told to do so.

And we should not make it "detect we are in git repository" and default to --index either. Often running without --index is useful inside a git repository. I would say roughly 50% of the time I use the command with --index and the rest without, so "more often" argument unfortunately does not apply to "apply".

I wish it were "2% without --index, 98% with --index". Then we could easily say "add '--no-index if you do not want to".