Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config

From: Junio C Hamano <junkio@cox.net>
Date: Feb 18, 2007, 01:20 UTC
Message-ID: <7vhctkp8gk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0702180151060.22628@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 7 quoted lines

> And I use git-apply to apply patches way more often than "patch" these 
> days. And I _think_ that it is a feature that it does not cd-up before 
> trying to apply the stuff. In git.git, I cannot think of a reasonable use 
> case for applying something not relative-to-root, but I had that use case 
> in some other (git-tracked) project.
>
> So my vote is to leave the cwd where it is in git-apply.

I strongly disagree from my recent day-job experience. I was feeding some changes to my co-worker's repository from my uncommitted changes (because it was incomplete but the part needed to unstuck him was ready). The day job project is much deeper than git.git, and the changes were to two files in a directory somewhat deep.

So I went there and said "git apply --index P.diff", which applied cleanly. But the other "git apply --index Q.diff" didn't.

So naturally I said:

	$ git apply --reject Q.diff
        error: filfre/frotz/nitfol.c: No such file or directory

I ended up editing filfre/frotz/ out of Q.diff in his editor. Explaining why P.diff and Q.diff, both of which were about the files in the same dirrectly, behaved differently was not pretty to git uninitiated.

Leaving --index case and working-tree-only case inconsistent is bad. We really should fix it (I really wish I found it out before 1.5.0 went out).