Re: "git add -u" broken in git 1.7.4?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 9, 2011, 22:40 UTC
- Message-ID
- <7vipwsomq8.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110209210312.GB2083@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The most compelling I have seen is "you tend to notice accidental > full-tree sooner than accidental relative behavior". Which you mentioned > in your email.
Hmph. You earlier mentioned "oops, I just pushed this commit and it turns out that I screwed up "git add" five minutes ago and it only had half of the files I intended" problem, but "oops, I just pushed this commit and it turns out that I screwed up "git add" five minutes ago and it had more changes than I intended" problem would be equally annoying, and I don't think one is inherently more likely to be noticed than the other; IOW, it is not compelling, but is just an arbitrary and a biased observation, no?
The most compelling, especially if we _were_ designing from scratch to make things consistent across the command set, would be "limiting to cwd with single dot is a lot easier to type than counting ../, using / to mean the root of the working tree is confusing, and saying --full-tree is annoying". I fully agree with that.
Can somebody volunteer to come up with a comprehensive list of operations that will change their behaviour when we switch to "full-tree without pathspec" semantics? We mentioned "grep" and "add -u" already.