Matthieu Moy [off-list ref] writes:
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
The inconsistancy of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
* forbid 'git add -u|-A' without filepattern (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
tree-wide scope.
A nice side effect of this patch is that it makes the :/ special
filepattern easier to discover for users.
Nicely explained.
The first step should look like this patch. The message remains vague
about the next steps ("change in a future Git version", no mention of
the exact change nor of the exact version in which it will happen),
but I'm fine with refining it (perhaps this could be a 2.0 change,
like the change to push.default?).
I think rolling big changes line these to a single version bump
would make sense, if we were to do it.
I have to wonder if "git add -p" and "git add -e" are the ones that
are broken, and the migration suggested here is going in the wrong
direction, though. After all "add -p" and "add -e" are interactive
by their nature, so it is a _lot_ easier to change their default
behaviour in the name of "usability fix", "consistency fix", or
whatever. Wouldn't we achieve the same consistency across modes of
"add" if we made them relative to the current directory?
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano [off-list ref] wrote:
Matthieu Moy [off-list ref] writes:
quoted
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
The inconsistancy of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
* forbid 'git add -u|-A' without filepattern (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
tree-wide scope.
I have to wonder if "git add -p" and "git add -e" are the ones that
are broken, and the migration suggested here is going in the wrong
direction, though. After all "add -p" and "add -e" are interactive
by their nature, so it is a _lot_ easier to change their default
behaviour in the name of "usability fix", "consistency fix", or
whatever. Wouldn't we achieve the same consistency across modes of
"add" if we made them relative to the current directory?
Consistency is one issue. +1 for having consistent behavior. But even
if all "git add" modes work consistently on current subdirectory, they
will be inconsistent with other git command, for example "git status"
or "git diff". I think it'd be better to have all git command work the
same (is that possible? is there a list of all commands which work on
current dir vs those working on whole tree?). I believe changing all
commands to work on current subdir is not an option.
Another issue is usability. Can we definitely say which is better: add
all changes from current subdir, or add all changes from whole tree? I
don't know. At the moment I think whole tree is better. That's usually
what I want. If I want to add only some changes, I first list the
status or run diff, and then explicitly say what to add. OTOH "add" is
kind of dangerous command - adding content to index is not reversible
(i.e. if there already is a previous version in index with changes,
"add" will overwrite it). But at the same time, another "dangerous"
command, "git add -a" works on whole tree. I use it frequently and
never had any problem with it.
So, from me +1 on making all commands work on whole tree.
--
Piotr Krukowiecki