From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:21
Jeff King [off-list ref] writes:
I suspect it is too late to change it due to compatibility issues. OTOH,
I think the intent of v1.7.0 is to allow a few small breakages like
these. You could always write an RFC patch and generate some discussion;
I'm not 100% sure that there are enough people that agree with us to
change the default.
The intent of 1.7.0 is to fix usability glitches and warts that everybody
has long agreed are problematic. People have *just started* discussing
about this---it is not remotely close to "everybody has long agreed are
problematic" criteria. It is too late for 1.7.0.
I agree that there are parts of git that is very whole tree oriented, and
the later "usability" part that are cwd centric. "add -u" and "grep" are
examples of the latter.
I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root. Why should "add -u" sans argument behave drastically
differently?
Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
this is in "if we had known better we would have designed it differently,
but because we didn't, because many scripts already depend on the current
behaviour, and because we have an --full-name escape hatch, we are not
likely to change it, ever" category.
If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal. I would say the commands that are used to incrementally build
towards the next commit should be friendly to the practice of limiting the
scope of the work by chdir, i.e. they should be cwd centric. On the other
hand, the commands that are used to review the next commit as a whole,
e.g. diff and patch, should be whole-tree oriented.
Oh, "git grep -e foo ../..", however, does not seem to work. That might be
something people may want to tackle.
From: Jeff King <hidden> Date: 2016-06-15 22:47:21
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
The intent of 1.7.0 is to fix usability glitches and warts that everybody
has long agreed are problematic. People have *just started* discussing
about this---it is not remotely close to "everybody has long agreed are
problematic" criteria. It is too late for 1.7.0.
What about a config option that could change the behavior? True, the
time-frame for discussion is much shorter, but we are not proposing to
make a change that would affect users who do not agree to it. And I
think the point of giving a long time-frame for discussion is to let
people decide whether a change that users do not agree to may affect
them in a bad way.
The real danger here is that users of the config option may be breaking
an interface that is used by scripts. But I feel that 1.7.0 is probably
the best time in the forseeable future to do that, as script-writers
already must be wary of the version change.
I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root. Why should "add -u" sans argument behave drastically
differently?
I agree that there is a certain consistency to the current behavior. But
I also find it terribly annoying, because I _always_ want it to do the
other thing, and it silently accepts the command without even telling
me, leaving me to find out ten minutes later that what I thought was
added was not ("git add", by contrast, yells at you in the same
situation).
I also happen to prefer the other behavior because it is easy to switch
the two options: "git add -u" versus "git add -u .", whereas with
current behavior I am stuck calculating (and typing) the correct number
of "../" markers.
But I respect the fact that even if we had infinite time for discussion,
there would be people who prefer it the opposite way to me. So how about
that config option?
Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
this is in "if we had known better we would have designed it differently,
but because we didn't, because many scripts already depend on the current
behaviour, and because we have an --full-name escape hatch, we are not
likely to change it, ever" category.
I assume you mean "ls-files". I have every once in a while been annoyed
by that, but given how infrequently I run ls-files, it is not a big
deal. :)
If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal. I would say the commands that are used to incrementally build
As I mentioned above, not only is that annoying to use, but the real
problem is that I _expect_ the other behavior and it silently does the
opposite of what I want. You can argue that my brain is defective (for
not remembering, I mean -- we _know_ it's defective in other ways), but
certainly a config option would be useful to me.
Oh, "git grep -e foo ../..", however, does not seem to work. That might be
something people may want to tackle.
Thanks for mentioning "git grep"; I had forgotten that I have been
bitten by expecting full-tree behavior from that in the past, too. A
config option should cover that, too. ;)
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:47:21
On Sat, Sep 05, 2009 at 03:20:17AM -0400, Jeff King wrote:
As I mentioned above, not only is that annoying to use, but the real
problem is that I _expect_ the other behavior and it silently does the
opposite of what I want. You can argue that my brain is defective (for
not remembering, I mean -- we _know_ it's defective in other ways), but
certainly a config option would be useful to me.
Bah. Even after this long thread, I _still_ forgot. I just now typed
"git add -u" from t/ and got annoyed that my changes in the root weren't
added.
-Peff
From: Clemens Buchacher <hidden> Date: 2016-06-15 22:47:21
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root. Why should "add -u" sans argument behave drastically
differently?
Sorry for stating the obvious here, but the following commands affect the
entire repository, even though they limit themselves to the current
directory, if passed a '.'.
git commit
git log
git diff
git checkout
git reset
Due to the frequent use of these commands, I believe many users (myself
included) expect "git add" and "git grep" to do the same. AFAICT the
following commands are the only non-plumbing ones that behave differently:
git add -u
git add -A
git grep
So I argue that _that_ is the real inconsistency.
If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal.
I would say the commands that are used to incrementally build
towards the next commit should be friendly to the practice of limiting the
scope of the work by chdir.
"git add -u ." is friendly enough. Just like "git commit ." versus "git
commit -a", which is exactly the same concept and should therefore have the
same behavior.
You are assuming that people are in a subdirectory because they want to
limit the scope. But I am usually in a subdirectory for totally
versioning-unrelated reasons. Like running tests in git.git:t/ . I
mistakenly use "git add -u" in there all the time, because I think I don't
have to worry about which directory I'm in. Except in this instance I do.
In any case, I think it is better to have consistent behavior than to try
and read users' minds with defaults.
Clemens
Sorry for stating the obvious here, but the following commands affect the
entire repository, even though they limit themselves to the current
directory, if passed a '.'.
git commit
git log
git diff
git checkout
git reset
Due to the frequent use of these commands, I believe many users (myself
included) expect "git add" and "git grep" to do the same. AFAICT the
following commands are the only non-plumbing ones that behave differently:
git add -u
git add -A
git grep
So I argue that _that_ is the real inconsistency.
The default behavior for 'git-grep' has already been discussed in length, and I don't think it is likely to change. See
http://thread.gmane.org/gmane.comp.version-control.git/111519/focus=111717
The original design for the other two in your list was to be a whole tree operation. This commit broke it.
2ed2c22 "git-add -u paths... now works from subdirectory".
'git-add -u' in a subdirectory without any other argument used to work on the entire working tree before that commit, but it didn't prefix the current directory in front of the paths... arguments.
That commit 2ed2c22 fixed 'git-add -u paths...' by prepending the prefix to the arguments, but it broke 'git-add -u' to always limit the updates to the current directory.
I think it is a good idea to fix this as an old regression in the maint branch. You don't have to introduce "git add -a". In fact the -a option was explicitly rejected when "git add -A" option was added with this commit.
3ba1f11 "git-add --all: add all files"
because "git commit -a" will never include new files and it will be inconsistent if "git add -a" did so.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:22
Nanako Shiraishi [off-list ref] writes:
[jc: sometimes but not always your messages have looooooooooooooong lines.
please line-wrap for readability. I learned to type W Q so often I do not
complain but other people would find them irritating.]
Interesting.
The first message in that thread lists things we have scheduled for 1.7.0
but it has another item. It is an off-topic for the thread, but we might
want to resurrect the "core.quotepath defaults to false" proposal, before
it gets too late for 1.7.0.
As to "grep", I am open to the proposal to make git commands consistent by
letting them operate on everything when no path argument is given, if grep
is really the single odd-man out remaining after changing the "add -u" and
"add -A" to work on the whole tree from subdirectories when given no paths.
The original design for the other two in your list was to be a whole
tree operation. This commit broke it.
2ed2c22 "git-add -u paths... now works from subdirectory".
...
I think it is a good idea to fix this as an old regression in the maint
branch. You don't have to introduce "git add -a". In fact the -a option
was explicitly rejected when "git add -A" option was added with this
commit.
Geez, you are good at digging things up.
It is very tempting to follow the suggestion above, but I suspect that,
even though it may be a regression from historical point of view, some
people who are used to the current behaviour may look at the corrected
one as a regression. We've had the change by 2ed2c22 for a long time.
I dunno.
Actually, most responded with the request for a command or config option,
and did not refuse the idea outright. One was not even aware that this is
how "git grep" behaves. And neither was I until a few days ago.
And that is kind of dangerous with this command. You expect it to behave
analogously to other git commands, but it doesn't. And because grep simply
does not search superdirectories, you may think that there are in fact no
matches so you don't even notice that behavior!
I think it is a good idea to fix this as an old regression in the maint
branch. You don't have to introduce "git add -a". In fact the -a option
was explicitly rejected when "git add -A" option was added with this
commit.
3ba1f11 "git-add --all: add all files"
because "git commit -a" will never include new files and it will be inconsistent if "git add -a" did so.
I certainly don't mind fixing "git add -u". But I was not suggesting "git
add -a" instead of "git add -A". The idea was to introduce it instead of
"git add -u" (which can be deprecated later), so that the following are
exactly the same.
"git add -a; git commit"
"git commit -a"
That way, scripts are not silently broken.
OTOH, "git add --all" is already inconsistent with "git commit --all". And
we would still need a new command for 'global' "add -A". *sigh*
Clemens