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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> 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).

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]