[RFC] git rm -u

[RFC] git rm -u

[Eric James Michael Ritz]

Hello everyone,

I am thinking about implementing a feature but I would appreciate any
feedback before I begin, because more experienced Git developers and
users may see some major problem that I do not.

Earlier today I deleted a file from a repository.  I deleted it
normally, not by using `git rm`.  So when I looked at `git status` on
my terminal it told me about the file no longer being there.  In my
sleepy state of mind I ran `git rm -u` without thinking about.  I did
this because I have a habit of using `git add -u`.  I know `git rm`
does not support that option, but I tried it anyways without thinking
about it.

When I came to my senses and realized that does not work I began to
wonder if `git rm -u` should exist.  If any deleted, tracked files are
not part of the index to commit then `git rm -u` would add that change
to the index.  This would save users the effort of having to type out
`git rm <filename>`, and could be useful when a user is deleting
multiple files.

Does this sound like a reasonable, useful feature to Git?  Or is there
already a way to accomplish this which I have missed out of ignorance?
Any thoughts and feedback would be greatly appreciated.

--
ejmr
南無妙法蓮華經

Re: [RFC] git rm -u

[Tomas Carnecky]

On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz <lobbyjones@gmail.com> wrote:
> Hello everyone,
> 
> I am thinking about implementing a feature but I would appreciate any
> feedback before I begin, because more experienced Git developers and
> users may see some major problem that I do not.
> 
> Earlier today I deleted a file from a repository.  I deleted it
> normally, not by using `git rm`.  So when I looked at `git status` on
> my terminal it told me about the file no longer being there.  In my
> sleepy state of mind I ran `git rm -u` without thinking about.  I did
> this because I have a habit of using `git add -u`.  I know `git rm`
> does not support that option, but I tried it anyways without thinking
> about it.
> 
> When I came to my senses and realized that does not work I began to
> wonder if `git rm -u` should exist.  If any deleted, tracked files are
> not part of the index to commit then `git rm -u` would add that change
> to the index.  This would save users the effort of having to type out
> `git rm <filename>`, and could be useful when a user is deleting
> multiple files.
> 
> Does this sound like a reasonable, useful feature to Git?  Or is there
> already a way to accomplish this which I have missed out of ignorance?
> Any thoughts and feedback would be greatly appreciated.

Does `git add -A` do what you want?

Re: [RFC] git rm -u

[Jonathan Nieder]

Eric James Michael Ritz wrote:

> When I came to my senses and realized that does not work I began to
> wonder if `git rm -u` should exist.  If any deleted, tracked files are
> not part of the index to commit then `git rm -u` would add that change
> to the index.

I like it.  If you have time to write such a patch, I'll be happy to
read it.

Thanks,
Jonathan

Re: [RFC] git rm -u

[Antoine Pelisse]

I think `git add -u` would be closer. It would stage removal of files,
but would not stage untracked files.
It would stage other type of changes though.

On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
<tomas.carnecky@gmail.com> wrote:
> On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz <lobbyjones@gmail.com> wrote:
>> Hello everyone,
>>
>> I am thinking about implementing a feature but I would appreciate any
>> feedback before I begin, because more experienced Git developers and
>> users may see some major problem that I do not.
>>
>> Earlier today I deleted a file from a repository.  I deleted it
>> normally, not by using `git rm`.  So when I looked at `git status` on
>> my terminal it told me about the file no longer being there.  In my
>> sleepy state of mind I ran `git rm -u` without thinking about.  I did
>> this because I have a habit of using `git add -u`.  I know `git rm`
>> does not support that option, but I tried it anyways without thinking
>> about it.
>>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist.  If any deleted, tracked files are
>> not part of the index to commit then `git rm -u` would add that change
>> to the index.  This would save users the effort of having to type out
>> `git rm <filename>`, and could be useful when a user is deleting
>> multiple files.
>>
>> Does this sound like a reasonable, useful feature to Git?  Or is there
>> already a way to accomplish this which I have missed out of ignorance?
>> Any thoughts and feedback would be greatly appreciated.
>
> Does `git add -A` do what you want?
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] git rm -u

[Eric James Michael Ritz]

On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
 > I think `git add -u` would be closer. It would stage removal of
 > files, but would not stage untracked files.  It would stage other
 > type of changes though.

On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
 > Does `git add -A` do what you want?

Thank you Tomas and Antoine.  Both of these commands do what I want:
stage deleted files on the index.  But does the idea of a `git rm -u`
still sound useful since these commands also stage changes besides
deleted files?

--
ejmr
南無妙法蓮華經

Re: [RFC] git rm -u

[Eric James Michael Ritz]

On 01/19/2013 04:49 PM, Jonathan Nieder wrote:
 > Eric James Michael Ritz wrote:
 >
 >> When I came to my senses and realized that does not work I began to
 >> wonder if `git rm -u` should exist.  If any deleted, tracked files
 >> are not part of the index to commit then `git rm -u` would add that
 >> change to the index.
 >
 > I like it.  If you have time to write such a patch, I'll be happy to
 > read it.

Thank you for the offer Jonathan.  I must go ahead and apologize for
my rusty ability with C; I haven’t needed to use the language in
years.  But I will familiarize myself with the Git source and try to
put a patch (or series of patches) together over the next week or two.

--
ejmr
南無妙法蓮華經

Re: [RFC] git rm -u

[Matthieu Moy]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Eric James Michael Ritz wrote:
>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist.  If any deleted, tracked files are
>> not part of the index to commit then `git rm -u` would add that change
>> to the index.
>
> I like it.  If you have time to write such a patch, I'll be happy to
> read it.

I can leave with "git add -u", but a "git rm -u" that would only look at
deletions, and not stage existing files changes would make sense.

One thing to be careful about is what to do when the command is called
from a subdirectory. In general, Git commands use this convention:

* git foo   => tree-wide command
* git foo . => restrict to current directory

"git add -u" is one of the only exceptions (with "git grep"). I consider
this as a bug, and think this should be changed. This has been discussed
several times here, but no one took the time to actually do the change
(changing is easy, but having a correct migration plan wrt backward
compatibility is not).

Implementing "git rm -u" as a tree-wide command would create a
discrepancy with "git add -u". Implementing it as a "current directory"
command would make the migration harder if we eventually try to change
"git add -u". Perhaps "git rm -u" should be forbidden from a
subdirectory (with an error message pointing to "git rm -u :/" and "git
rm -u ."), waiting for a possible "git add -u" change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> "git add -u" is one of the only exceptions (with "git grep"). I consider
> this as a bug, and think this should be changed. This has been discussed
> several times here, but no one took the time to actually do the change

Did we ever agree that it is a good change to begin with?  Pointers?

Re: [RFC] git rm -u

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Implementing "git rm -u" as a tree-wide command would create a
> discrepancy with "git add -u". Implementing it as a "current directory"
> command would make the migration harder if we eventually try to change
> "git add -u". Perhaps "git rm -u" should be forbidden from a
> subdirectory (with an error message pointing to "git rm -u :/" and "git
> rm -u ."), waiting for a possible "git add -u" change.

Yeah, that sounds sensible.  Start with a "'git rm -u' is forbidden
without arguments", give advise to use either "." or ":/".  And stop
there.

The first step of "git add -u" migration plan would be to warn when
no argument is given and update all the existing index entries, and
give the same advise to use either "." or ":/".  Keep this for three
cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.

The second step would be to forbid "git add -u", and keep the
advise.  That will make it in-line with "git rm -u".

Re: [RFC] git rm -u

[Eric James Michael Ritz]

On 01/20/2013 01:53 PM, Junio C Hamano wrote:
 > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
 >
 >> Implementing "git rm -u" as a tree-wide command would create a
 >> discrepancy with "git add -u". Implementing it as a "current
 >> directory" command would make the migration harder if we eventually
 >> try to change "git add -u". Perhaps "git rm -u" should be forbidden
 >> from a subdirectory (with an error message pointing to "git rm -u
 >> :/" and "git rm -u ."), waiting for a possible "git add -u" change.
 >
 > Yeah, that sounds sensible.  Start with a "'git rm -u' is forbidden
 > without arguments", give advise to use either "." or ":/".  And stop
 > there.

I was unaware of any plan to change `git add -u`, but the above makes
sense to me.  I will use those suggestions as guidelines for the
initial implementation of `git rm -u`.  In particular, it will require
an argument like `.` or `:/`.  It sounds like the future direction of
`git add -u` will play a role in how `git rm -u` should behave so that
there is consistency between the two, so I will try to take a
conservative approach in my implementation.  Thank you both for the
advice and insight.

--
ejmr
南無妙法蓮華經

Re: [RFC] git rm -u

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>> this as a bug, and think this should be changed. This has been discussed
>> several times here, but no one took the time to actually do the change
>
> Did we ever agree that it is a good change to begin with?  Pointers?

I think you can guess but I no longer need pointers.  Others may
still be helped, though.

The argument IIRC boils down to

 - "git add -u" was made a whole-tree operation when there weren't
   the ":/" magic pathspec, but "add -u" is very often something you
   want to do whole tree, and "(cd ../../..; git add -u)" or "git
   add -u ../../.." are too cumbersome to type.

 - "git add -u ." to limit it to the current directory is easy to
   type.

 - As we have the "from the root" magic pathspec these days,
   requiring "git add -u :/" when the user really means to add
   everything is no longer too much of a burden, but if we suddenly
   changed "git add -u" to mean "git add -u .", that is too much of
   a change in the semantics.

Re: [RFC] git rm -u

[Martin von Zweigbergk]

On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>>> this as a bug, and think this should be changed. This has been discussed
>>> several times here, but no one took the time to actually do the change
>
>  - As we have the "from the root" magic pathspec these days,
>    requiring "git add -u :/" when the user really means to add
>    everything is no longer too much of a burden, but if we suddenly
>    changed "git add -u" to mean "git add -u .", that is too much of
>    a change in the semantics.

And I think someone (Jeff?) pointed out that that last part is even
more true for "git clean", which also currently works on the current
directory if not told otherwise.

Re: [RFC] git rm -u

[Piotr Krukowiecki]

On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Implementing "git rm -u" as a tree-wide command would create a
>> discrepancy with "git add -u". Implementing it as a "current directory"
>> command would make the migration harder if we eventually try to change
>> "git add -u". Perhaps "git rm -u" should be forbidden from a
>> subdirectory (with an error message pointing to "git rm -u :/" and "git
>> rm -u ."), waiting for a possible "git add -u" change.
>
> Yeah, that sounds sensible.  Start with a "'git rm -u' is forbidden
> without arguments", give advise to use either "." or ":/".  And stop
> there.
>
> The first step of "git add -u" migration plan would be to warn when
> no argument is given and update all the existing index entries, and
> give the same advise to use either "." or ":/".  Keep this for three
> cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.
>
> The second step would be to forbid "git add -u", and keep the
> advise.  That will make it in-line with "git rm -u".

Do you mean "git add" will be disallowed without "." or ":/" argument?
Or will this change in future and "git add" without argument will me
"whole tree", same as ":/" ?

--
Piotr Krukowiecki

Re: [RFC] git rm -u

[Matthieu Moy]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

> Do you mean "git add" will be disallowed without "." or ":/" argument?
> Or will this change in future and "git add" without argument will me
> "whole tree", same as ":/" ?

Let's talk conditional, not future, for now.

If the idea is to change the semantics without argument, it has to be
done carefully, and implies disallowing the argumentless version for a
while (or some better idea) to avoid confusion.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>> this as a bug, and think this should be changed. This has been discussed
>> several times here, but no one took the time to actually do the change
>
> Did we ever agree that it is a good change to begin with?  Pointers?

I don't think a consensus was reached, but it has been discussed at
least once in this thread:

http://thread.gmane.org/gmane.comp.version-control.git/166223/focus=168238

Essentially, the discussion boiled down to "it would be cool to change,
but the migration won't be easy".

The main argument for change is (for me) consistency. Having
"git add -p" tree-wide and "git add -u" limited to . is really strange.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Junio C Hamano]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

> Do you mean "git add" will be disallowed without "." or ":/" argument?
> Or will this change in future and "git add" without argument will me
> "whole tree", same as ":/" ?

No.  This is only about "git add -u<RETURN>", not any other forms of
"git add ...with or without other args...".

"git add -u<RETURN>" historically meant, and it still means, to
"update the index with every change in the working tree", even when
you are in a subdirectory.

Back when "git add -u" was invented, we didn't have the ":/", which
lets us tell commands that take pathspecs "I want everything from
the top of the working tree.".  If "git add -u<RETURN>" limited its
operation to the current directory, after working everywhere in the
working tree, cd'ing around and ending up to be in a subdirectory
somwhere deep, you had to "cd ../../.. && git add -u", which was
cumbersome.  If "git add -u" always meant the whole tree, limiting
it to the current directory with "git add -u .<RETURN>" was easy,
and that is why the default was chosen to the "whole tree".

Because we have ":/" these days, changing something that limits its
action to the current directory by default to instead work on the
whole tree no longer makes much sense.  That is, if we _were_ to
change "git add -u<RETURN>", it would be in the opposite direction,
i.e. to update the index only with the paths below the current
directory.

Such a change has to be done carefully.  Existing users do expect
the current behaviour, so we have to first _break_ their fingers and
habits and train them to say "add -u :/" when they mean the whole
tree operation.  Silently accepting "add -u" and changing its
meaning to update the index only with the paths below the current
directory will cause them trouble by leaving changes they _thought_
they added out of the index, and is an unacceptable change.

The first step of migration is "git add -u<RETURN>" that loudly
warns, so that uses of that form in scripts are updated before the
second step to avoid a flag-day breakage and start traing fingers
and habits of the users.

The second step is to make "add -u<RETURN>" fail, again with a
message that tells users to be explicit and add ":/" or "." at the
end if they mean "the whole tree" or "the current directory".

After keeping Git in that secnd step for sufficiently long time to
train users to type ":/" or "." explicitly, we can then finally
switch the default of "git add -u<RETURN>" to limit it to the
current directory, instead of failing the command.

[RFC/PATCH] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

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.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Junio C Hamano <gitster@pobox.com> writes:

> The first step of "git add -u" migration plan would be to warn when
> no argument is given and update all the existing index entries, and
> give the same advise to use either "." or ":/".  Keep this for three
> cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.

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

 Documentation/git-add.txt |  7 ++++---
 builtin/add.c             | 30 +++++++++++++++++++++++++++++-
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
 	from the index if the corresponding files in the working tree
 	have been removed.
 +
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
 
 -A::
 --all::
diff --git a/builtin/add.c b/builtin/add.c
index e664100..e6eb829 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -373,6 +373,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	int add_new_files;
 	int require_pathspec;
 	char *seen = NULL;
+	const char *option_with_implicit_dot = NULL;
 
 	git_config(add_config, NULL);
 
@@ -392,7 +393,34 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 		die(_("-A and -u are mutually incompatible"));
 	if (!show_only && ignore_missing)
 		die(_("Option --ignore-missing can only be used together with --dry-run"));
-	if ((addremove || take_worktree_changes) && !argc) {
+	if (addremove)
+		option_with_implicit_dot = "--all";
+	if (take_worktree_changes)
+		option_with_implicit_dot = "--update";
+	if (option_with_implicit_dot && !argc) {
+		/*
+		 * To be consistant with "git add -p" and most Git
+		 * commands, we should default to being tree-wide, but
+		 * this is not the original behavior and can't be
+		 * changed until users trained themselves not to type
+		 * "git add -u" or "git add -A". For now, we warn and
+		 * keep the old behavior. Later, this warning can be
+		 * turned into a die(...), and eventually we may
+		 * reallow the command with a new behavior.
+		 */
+		warning(_("The behavior of 'git add %s' with no path argument will change in a future\n"
+			  "Git version and shouldn't be used anymore.  To add content for the whole tree, run:\n"
+			  "\n"
+			  "  git add %s :/\n"
+			  "\n"
+			  "To restrict the command to the current directory, run:\n"
+			  "\n"
+			  "  git add %s .\n"
+			  "\n"
+			  "With the current Git version, the command is restricted to the current directory."),
+			option_with_implicit_dot,
+			option_with_implicit_dot,
+			option_with_implicit_dot);
 		static const char *here[2] = { ".", NULL };
 		argc = 1;
 		argv = here;
-- 
1.8.0.319.g8abfee4

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Robin Rosenberg]

----- Ursprungligt meddelande -----
> 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)

git add -u without filepattern is, I believe very common, so no noisy
output there please.

git diff
#looks good
git add -u

-- robin

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

> git add -u without filepattern is, I believe very common, so no noisy
> output there please.

What are you exactly suggesting? That we keep the inconsistant semantics
of "git add -u" or "git add -A"? Or another migration plan?

> git diff
> #looks good
> git add -u

That's indeed the kind of mistake I'd like to avoid. In your example,
"git diff" is tree-wide, and "git add -u" is limited to ., so in general
"git add -u" won't stage the same thing as "git diff" just showed.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
>
>> Do you mean "git add" will be disallowed without "." or ":/" argument?
>> Or will this change in future and "git add" without argument will me
>> "whole tree", same as ":/" ?
>
> No.  This is only about "git add -u<RETURN>", not any other forms of
> "git add ...with or without other args...".

This part is still correct, but all the remainder of the message I
am responding to is a total garbage, written from faulty memory
without fact check.  Sorry about noise.

> "git add -u<RETURN>" historically meant,...

The very original "git add -u<RETURN>" done at v1.5.2-rc0~17^2
(git-add -u: match the index with working tree., 2007-04-20) did
update the index with every change under the root of the working
tree, no matter where you were.

But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
2007-08-16) changed the semantics to limit the operation to the
working tree.  The log message seems to suggest that this was a
deliberate semantics change post release (i.e. the "tree-wide" was a
bug); I do not recall if there was a discussion and concensus when
this change was made, though.

Re: [RFC] git rm -u

[Piotr Krukowiecki]

On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
> No.  This is only about "git add -u<RETURN>", not any other forms of
> "git add ...with or without other args...".
>
> "git add -u<RETURN>" historically meant, and it still means, to
> "update the index with every change in the working tree", even when
> you are in a subdirectory.

But it *currently* limits itself to a subdirectory - does not work on
whole tree:

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   dir2/file2.txt
#       modified:   file1.txt
#       modified:   ../file.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git add -u

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   dir2/file2.txt
#       modified:   file1.txt
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   ../file.txt
#

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git --version
git version 1.8.0.msysgit.0



--
Piotr Krukowiecki

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> 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?

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Piotr Krukowiecki]

On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> 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.
>>
>
> 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

Re: [RFC] git rm -u

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
> 2007-08-16) changed the semantics to limit the operation to the
> working tree.

Not really. It fixed "git add -u path", not plain "git add -u". A quick
test checking out and compiling v1.5.2.5~1^ shows that "git add -u ."
from a subdirectory was adding everything from the root.

My interpretation is that v1.5.2.5~1 fixed an actual bug, without
thinking about what would happen when "git add -u" was called without
path, so the behavior is "what happens to be the most natural to
implement". Indeed, the behavior was actually documented only later, in
v1.5.4.3~3 (Feb 21 00:29:39 2008, Clarified the meaning of git-add -u in
the documentation), the previous doc said only "If no paths are
specified, all tracked files are updated.".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

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

Hard to tell, depending on users, use-case, ...

But the good news is: whatever option is chosen, the other one is only a
few keystrokes away (git add -u . or git add -u :/).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Wouldn't we achieve the same consistency across modes of
> "add" if we made them relative to the current directory?

As other people already said, it would be nice to have consistency
accross most if not all commands. AFAICT, the only exceptions to
"tree-wide by default, say '.' to restrict to subdirectory" are git add
-u|-A, git grep and git clean.

Arguably, the "subtree by default" is a safety feature of "git clean",
and should be kept.

I don't care too deepely about "git grep". From previous discussions,
IIRC, other people didn't care either.

On the other hand, I can think of at least "git log", "git diff", "git
status" and to some extend "git commit" as tree-wide by default with
optional path restriction. I'd like "git add" to be on the same side.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Robin Rosenberg]

----- Ursprungligt meddelande -----

> > git diff
> > #looks good
> > git add -u
> 
> That's indeed the kind of mistake I'd like to avoid. In your example,
> "git diff" is tree-wide, and "git add -u" is limited to ., so in
> general
> "git add -u" won't stage the same thing as "git diff" just showed.

Good point. I rarely cd to anything but the top of the tree, but that
might be just me. OTOH, git diff after -u would remind me. It would bad if -u 
was tree wide and diff wasn't, but fortunately that's not the case.

The -A is a bit worse since it adds all the crap files lying around.

-- robin

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Jonathan Nieder]

Hi,

Matthieu Moy wrote:

> 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:

Thanks for tackling this.

> --- a/builtin/add.c
> +++ b/builtin/add.c
[...]
> +	if (option_with_implicit_dot && !argc) {
> +		/*
> +		 * To be consistant with "git add -p" and most Git
> +		 * commands, we should default to being tree-wide, but
> +		 * this is not the original behavior and can't be
> +		 * changed until users trained themselves not to type
> +		 * "git add -u" or "git add -A". For now, we warn and
> +		 * keep the old behavior. Later, this warning can be
> +		 * turned into a die(...), and eventually we may
> +		 * reallow the command with a new behavior.
> +		 */
> +		warning(_("The behavior of 'git add %s' with no path argument will change in a future\n"

Would it be possible to make this conditional on cwd not being at the
toplevel (the case where "git add -u :/" and "git add -u ." have
different behavior)?  E.g.,

		static const char *here[2] = { ".", NULL };
		if (prefix)
			warning(...);

Thanks,
Jonathan

Re: [RFC] git rm -u

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
>> 2007-08-16) changed the semantics to limit the operation to the
>> working tree.
>
> Not really. It fixed "git add -u path", not plain "git add -u". A quick
> test checking out and compiling v1.5.2.5~1^ shows that "git add -u ."
> from a subdirectory was adding everything from the root.
>
> My interpretation is that v1.5.2.5~1 fixed an actual bug, without
> thinking about what would happen when "git add -u" was called without
> path, so the behavior is "what happens to be the most natural to
> implement".

I guess at this point it does not matter that much if that was an
unintended consequence of a buggy fix, or a new behaviour by design.
We initially were tree-wide but later limited the operation to the
current directory.

I think your "Check 'git diff' then run 'git add -u'" example may be
a good enough argument that it is a good idea to restore the
originally intended "tree-wide" behaviour in any case.

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Duy Nguyen]

On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> 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.

What about 'grep' and 'clean'? I think at least 'clean' should go
tree-wide default too. I don't mind grep go the same way either but I
think people voiced preference in current behavior..
-- 
Duy

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> What about 'grep' and 'clean'? I think at least 'clean' should go
> tree-wide default too. I don't mind grep go the same way either but I
> think people voiced preference in current behavior..

I think the major argument for "git grep" to be the way it is is
because people expect it to be extension of running "grep -r" in the
same directory ("git grep" excludes untracked ones so you do not
have to suffer from --exclude=.git and such unpleasantries).

Shouldn't "git clean" be an extension of running "rm -r" in the same
directory ("git clean" does not lose tracked ones but otherwise it
is a recursive removal)?

Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Would it be possible to make this conditional on cwd not being at the
> toplevel (the case where "git add -u :/" and "git add -u ." have
> different behavior)?  E.g.,
>
> 		static const char *here[2] = { ".", NULL };
> 		if (prefix)
> 			warning(...);

I thought about this too, after writting the patch. Actually, I still I
it makes sense to warn even from the toplevel, since the point is to
teach people to stop using pathless "git add -u" for a while, so I'd say
it's easier to teach this in every condition. OTOH, the next step
(forbidding pathless "git add -u") can still allow it from the toplevel
to minimize the pain.

But I'm starting to be convinced ;-).

Any other thought on the question?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[PATCH v2] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

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.

When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Changes since v1:

* Do not warn from the root of the tree.

* Say explicitely "Git 2.0" to announce the change.

(plus fix a C99 style issue)

 Documentation/git-add.txt |  7 ++++---
 builtin/add.c             | 36 +++++++++++++++++++++++++++++++++++-
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
 	from the index if the corresponding files in the working tree
 	have been removed.
 +
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
 
 -A::
 --all::
diff --git a/builtin/add.c b/builtin/add.c
index e664100..8252d19 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -363,6 +363,33 @@ static int add_files(struct dir_struct *dir, int flags)
 	return exit_status;
 }
 
+static void warn_pathless_add(const char *option_name) {
+	/*
+	 * To be consistant with "git add -p" and most Git
+	 * commands, we should default to being tree-wide, but
+	 * this is not the original behavior and can't be
+	 * changed until users trained themselves not to type
+	 * "git add -u" or "git add -A". For now, we warn and
+	 * keep the old behavior. Later, this warning can be
+	 * turned into a die(...), and eventually we may
+	 * reallow the command with a new behavior.
+	 */
+	warning(_("The behavior of 'git add %s' with no path argument from a subdirectory of the\n"
+		  "tree will change in Git 2.0 and shouldn't be used anymore.\n"
+		  "To add content for the whole tree, run:\n"
+		  "\n"
+		  "  git add %s :/\n"
+		  "\n"
+		  "To restrict the command to the current directory, run:\n"
+		  "\n"
+		  "  git add %s .\n"
+		  "\n"
+		  "With the current Git version, the command is restricted to the current directory."),
+		option_name,
+		option_name,
+		option_name);
+}
+
 int cmd_add(int argc, const char **argv, const char *prefix)
 {
 	int exit_status = 0;
@@ -373,6 +400,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	int add_new_files;
 	int require_pathspec;
 	char *seen = NULL;
+	const char *option_with_implicit_dot = NULL;
 
 	git_config(add_config, NULL);
 
@@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 		die(_("-A and -u are mutually incompatible"));
 	if (!show_only && ignore_missing)
 		die(_("Option --ignore-missing can only be used together with --dry-run"));
-	if ((addremove || take_worktree_changes) && !argc) {
+	if (addremove)
+		option_with_implicit_dot = "--all";
+	if (take_worktree_changes)
+		option_with_implicit_dot = "--update";
+	if (option_with_implicit_dot && !argc) {
 		static const char *here[2] = { ".", NULL };
+		if (prefix)
+			warn_pathless_add(option_with_implicit_dot);
 		argc = 1;
 		argv = here;
 	}
-- 
1.8.0.1.527.gd366564.dirty

Re: [PATCH v2] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> 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

s/consistan/consisten/;

> diff --git a/builtin/add.c b/builtin/add.c
> index e664100..8252d19 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -363,6 +363,33 @@ static int add_files(struct dir_struct *dir, int flags)
>  	return exit_status;
>  }
>  
> +static void warn_pathless_add(const char *option_name) {
> +	/*
> +	 * To be consistant with "git add -p" and most Git

Likewise.

> +	warning(_("The behavior of 'git add %s' with no path argument from a subdirectory of the\n"
> ...
> +		option_name,
> +		option_name,
> +		option_name);
> +}
> +
>  int cmd_add(int argc, const char **argv, const char *prefix)
>  {
>  	int exit_status = 0;
> @@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  		die(_("-A and -u are mutually incompatible"));
>  	if (!show_only && ignore_missing)
>  		die(_("Option --ignore-missing can only be used together with --dry-run"));
> -	if ((addremove || take_worktree_changes) && !argc) {
> +	if (addremove)
> +		option_with_implicit_dot = "--all";
> +	if (take_worktree_changes)
> +		option_with_implicit_dot = "--update";

I wonder if we want to say in the message

	The behaviour of 'git add --all (or -A)'...

otherwise people who typed "git add -A" and got this message with
just "--all" may go "Huh?" for a brief moment.  I however do not
think replacing these strings to

	option_with_implicit_dot = "--all (-A)";

is a solution, given they are goven to _("l10n template %s").

Other than that the patch looks reasonable.

Thanks.

Re: [PATCH v2] add: warn when -u or -A is used without filepattern

[Jonathan Nieder]

Hi Matthieu,

Matthieu Moy wrote:

> --- a/builtin/add.c
> +++ b/builtin/add.c
[...]
> @@ -392,8 +420,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  		die(_("-A and -u are mutually incompatible"));
>  	if (!show_only && ignore_missing)
>  		die(_("Option --ignore-missing can only be used together with --dry-run"));
> -	if ((addremove || take_worktree_changes) && !argc) {
> +	if (addremove)
> +		option_with_implicit_dot = "--all";
> +	if (take_worktree_changes)
> +		option_with_implicit_dot = "--update";

I agree with Junio that these are most often spelled as "-A" and "-u".

> +	if (option_with_implicit_dot && !argc) {
>  		static const char *here[2] = { ".", NULL };
> +		if (prefix)
> +			warn_pathless_add(option_with_implicit_dot);

For what it's worth, with or without s/--all/-A/ and s/--update/-u/,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks.  If someone wants to preserve the spelling of the option name
passed by the user, that can happen as a patch on top.

Re: [PATCH v2] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@imag.fr> 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
>
> s/consistan/consisten/;

Thanks, will fix.

> I wonder if we want to say in the message
>
> 	The behaviour of 'git add --all (or -A)'...
>
> otherwise people who typed "git add -A" and got this message with
> just "--all" may go "Huh?" for a brief moment.  I however do not
> think replacing these strings to
>
> 	option_with_implicit_dot = "--all (-A)";
>
> is a solution, given they are goven to _("l10n template %s").

Plus, option_with_implicit_dot is used in cut-and-paste ready commands
below. I can easily add another variable short_option or so to display
both. Ideally, we should use whatever the user had typed, but that does
not seem easy to do with parse-option so I'd say it's overkill.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH v2] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
> below.

I do not think we should aim for easy cut-and-paste, especially when
the real purpose of the change is to train people's fingers; the
message should discouraging cut-and-paste in a case like this, if
anything.

But we could obviously do this, if you really want to cut-and-paste.

 builtin/add.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index 7552f7f..ba72a57 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -363,7 +363,7 @@ static int add_files(struct dir_struct *dir, int flags)
 	return exit_status;
 }
 
-static void warn_pathless_add(const char *option_name) {
+static void warn_pathless_add(const char *option_name, const char *short_name) {
 	/*
 	 * To be consistent with "git add -p" and most Git
 	 * commands, we should default to being tree-wide, but
@@ -374,20 +374,21 @@ static void warn_pathless_add(const char *option_name) {
 	 * turned into a die(...), and eventually we may
 	 * reallow the command with a new behavior.
 	 */
-	warning(_("The behavior of 'git add %s' with no path argument from a subdirectory of the\n"
-		  "tree will change in Git 2.0 and shouldn't be used anymore.\n"
+	warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
+		  "subdirectory of the tree will change in Git 2.0 and should not be\n"
+		  "used anymore.\n"
 		  "To add content for the whole tree, run:\n"
 		  "\n"
-		  "  git add %s :/\n"
+		  "  git add %s :/ ;# or git add %s :/\n"
 		  "\n"
 		  "To restrict the command to the current directory, run:\n"
 		  "\n"
-		  "  git add %s .\n"
+		  "  git add %s . ;# or git add %s .\n"
 		  "\n"
 		  "With the current Git version, the command is restricted to the current directory."),
-		option_name,
-		option_name,
-		option_name);
+		option_name, short_name,
+		option_name, short_name,
+		option_name, short_name);
 }
 
 int cmd_add(int argc, const char **argv, const char *prefix)
@@ -401,6 +402,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	int require_pathspec;
 	char *seen = NULL;
 	const char *option_with_implicit_dot = NULL;
+	const char *short_option_with_implicit_dot = NULL;
 
 	git_config(add_config, NULL);
 
@@ -420,14 +422,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 		die(_("-A and -u are mutually incompatible"));
 	if (!show_only && ignore_missing)
 		die(_("Option --ignore-missing can only be used together with --dry-run"));
-	if (addremove)
+	if (addremove) {
 		option_with_implicit_dot = "--all";
-	if (take_worktree_changes)
+		short_option_with_implicit_dot = "-A";
+	}
+	if (take_worktree_changes) {
 		option_with_implicit_dot = "--update";
+		short_option_with_implicit_dot = "-u";
+	}
 	if (option_with_implicit_dot && !argc) {
 		static const char *here[2] = { ".", NULL };
 		if (prefix)
-			warn_pathless_add(option_with_implicit_dot);
+			warn_pathless_add(option_with_implicit_dot,
+					  short_option_with_implicit_dot);
 		argc = 1;
 		argv = here;
 	}

Re: [PATCH v2] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
>> below.
>
> I do not think we should aim for easy cut-and-paste, especially when
> the real purpose of the change is to train people's fingers; the
> message should discouraging cut-and-paste in a case like this, if
> anything.

cut-and-paste readyness is also a way to avoid being ambiguous. If you
tell users to run "git add -u (--update)", you'll always find someone to
type the command as-is and complain about it not working (sadly, the
teacher living inside me is speaking of experience ;-) ).

> But we could obviously do this, if you really want to cut-and-paste.

I was going to do something like this, you've been too quick ;-).

Resend comming soon.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[PATCH v3] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

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

When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Changes since v2:

* Typo consistant -> consistent

* Mention both short and long option names (Thanks Junio). I went for
  a two-lines display which I find a bit nicer to read than Junio's
  version, but I'm fine with both.

 Documentation/git-add.txt |  7 ++++---
 builtin/add.c             | 44 +++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
 	from the index if the corresponding files in the working tree
 	have been removed.
 +
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
 
 -A::
 --all::
diff --git a/builtin/add.c b/builtin/add.c
index 7cb6cca..7738025 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
 	return exit_status;
 }
 
+static void warn_pathless_add(const char *option_name, const char *short_name) {
+	/*
+	 * To be consistent with "git add -p" and most Git
+	 * commands, we should default to being tree-wide, but
+	 * this is not the original behavior and can't be
+	 * changed until users trained themselves not to type
+	 * "git add -u" or "git add -A". For now, we warn and
+	 * keep the old behavior. Later, this warning can be
+	 * turned into a die(...), and eventually we may
+	 * reallow the command with a new behavior.
+	 */
+	warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
+		  "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
+		  "To add content for the whole tree, run:\n"
+		  "\n"
+		  "  git add %s :/\n"
+		  "  (or git add %s :/)\n"
+		  "\n"
+		  "To restrict the command to the current directory, run:\n"
+		  "\n"
+		  "  git add %s .\n"
+		  "  (or git add %s .)\n"
+		  "\n"
+		  "With the current Git version, the command is restricted to the current directory."),
+		option_name, short_name,
+		option_name, short_name,
+		option_name, short_name);
+}
+
 int cmd_add(int argc, const char **argv, const char *prefix)
 {
 	int exit_status = 0;
@@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	int add_new_files;
 	int require_pathspec;
 	char *seen = NULL;
+	const char *option_with_implicit_dot = NULL;
+	const char *short_option_with_implicit_dot = NULL;
 
 	git_config(add_config, NULL);
 
@@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 		die(_("-A and -u are mutually incompatible"));
 	if (!show_only && ignore_missing)
 		die(_("Option --ignore-missing can only be used together with --dry-run"));
-	if ((addremove || take_worktree_changes) && !argc) {
+	if (addremove) {
+		option_with_implicit_dot = "--all";
+		short_option_with_implicit_dot = "-A";
+	}
+	if (take_worktree_changes) {
+		option_with_implicit_dot = "--update";
+		short_option_with_implicit_dot = "-u";
+	}
+	if (option_with_implicit_dot && !argc) {
 		static const char *here[2] = { ".", NULL };
+		if (prefix)
+			warn_pathless_add(option_with_implicit_dot,
+					  short_option_with_implicit_dot);
 		argc = 1;
 		argv = here;
 	}
-- 
1.8.1.1.440.g1d329bd.dirty

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Jonathan Nieder]

Matthieu Moy wrote:

> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>

Looks good to me.

At some point we'll want to have tests for this case, but that's not
particularly urgent until it's time for the warning() to turn into a
die().

Thanks.
Jonathan

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
> 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'.

Since I didn't follow this thread, my first reaction was: "Huh? Aren't
they treewide?" (for the relative tree)

So, for someone reading just the commit message, it would be helpful to
say what the others do, i.e. default to the relative tree at pwd (rather
than defaulting to an empty tree, or all files whether tracked or not,
or...).

Otherwise, I'd rather switch sooner than later; it's so easy to take
"git add -u && git commit == git commit -a" for granted and to miss
staging some hunks. But 2.0 is around the corner anyway, isn't it ;)

> The inconsistency 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.
> 
> When the command is called from the root of the tree, there is no
> ambiguity and no need to change the behavior, hence no need to warn.
> 
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Changes since v2:
> 
> * Typo consistant -> consistent
> 
> * Mention both short and long option names (Thanks Junio). I went for
>   a two-lines display which I find a bit nicer to read than Junio's
>   version, but I'm fine with both.
> 
>  Documentation/git-add.txt |  7 ++++---
>  builtin/add.c             | 44 +++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index fd9e36b..5333559 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
>  	from the index if the corresponding files in the working tree
>  	have been removed.
>  +
> -If no <filepattern> is given, default to "."; in other words,
> -update all tracked files in the current directory and its
> -subdirectories.
> +If no <filepattern> is given, the current version of Git defaults to
> +"."; in other words, update all tracked files in the current directory
> +and its subdirectories. This default will change in a future version
> +of Git, hence the form without <filepattern> should not be used.
>  
>  -A::
>  --all::
> diff --git a/builtin/add.c b/builtin/add.c
> index 7cb6cca..7738025 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
>  	return exit_status;
>  }
>  
> +static void warn_pathless_add(const char *option_name, const char *short_name) {
> +	/*
> +	 * To be consistent with "git add -p" and most Git
> +	 * commands, we should default to being tree-wide, but
> +	 * this is not the original behavior and can't be
> +	 * changed until users trained themselves not to type
> +	 * "git add -u" or "git add -A". For now, we warn and
> +	 * keep the old behavior. Later, this warning can be
> +	 * turned into a die(...), and eventually we may
> +	 * reallow the command with a new behavior.
> +	 */
> +	warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
> +		  "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
> +		  "To add content for the whole tree, run:\n"
> +		  "\n"
> +		  "  git add %s :/\n"
> +		  "  (or git add %s :/)\n"
> +		  "\n"
> +		  "To restrict the command to the current directory, run:\n"
> +		  "\n"
> +		  "  git add %s .\n"
> +		  "  (or git add %s .)\n"
> +		  "\n"
> +		  "With the current Git version, the command is restricted to the current directory."),
> +		option_name, short_name,
> +		option_name, short_name,
> +		option_name, short_name);
> +}
> +
>  int cmd_add(int argc, const char **argv, const char *prefix)
>  {
>  	int exit_status = 0;
> @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  	int add_new_files;
>  	int require_pathspec;
>  	char *seen = NULL;
> +	const char *option_with_implicit_dot = NULL;
> +	const char *short_option_with_implicit_dot = NULL;
>  
>  	git_config(add_config, NULL);
>  
> @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  		die(_("-A and -u are mutually incompatible"));
>  	if (!show_only && ignore_missing)
>  		die(_("Option --ignore-missing can only be used together with --dry-run"));
> -	if ((addremove || take_worktree_changes) && !argc) {
> +	if (addremove) {
> +		option_with_implicit_dot = "--all";
> +		short_option_with_implicit_dot = "-A";
> +	}
> +	if (take_worktree_changes) {
> +		option_with_implicit_dot = "--update";
> +		short_option_with_implicit_dot = "-u";
> +	}
> +	if (option_with_implicit_dot && !argc) {
>  		static const char *here[2] = { ".", NULL };
> +		if (prefix)
> +			warn_pathless_add(option_with_implicit_dot,
> +					  short_option_with_implicit_dot);
>  		argc = 1;
>  		argv = here;
>  	}
> 

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
>> 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'.
>
> Since I didn't follow this thread, my first reaction was: "Huh? Aren't
> they treewide?" (for the relative tree)
>
> So, for someone reading just the commit message, it would be helpful to
> say what the others do, i.e. default to the relative tree at pwd (rather
> than defaulting to an empty tree, or all files whether tracked or not,
> or...).

I think "add -u && commit" vs "commit -a" you brought up is a good
thing to mention, so let's do this.  Another tweak is that I did
s/filepattern/pathspec/ here.  I know that both the documentation
and the help text for "git add" say filepattern, but we say pathspec
starting from glossary fairly consistently everywhere in the rest of
the system.

We should probably update the documentation/help for "git add", but
that is entirely a separate topic.

    add: warn when -u or -A is used without pathspec
    
    Most Git commands that can be used with or without pathspec operate
    tree-wide by default, the pathspec being used to restrict their
    scope.  A few exceptions are: 'git grep', 'git clean', 'git add -u'
    and 'git add -A'.  When run in a subdirectory without pathspec, they
    operate only on paths in the current directory.
    
    The inconsistency 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.  It also means that "git
    add -u && git commit" will record a state that is different from
    what is recorded with "git commit -a".
    
    Flipping the default now is unacceptable, so let's start training
    users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to
    prepare for the next steps:
    
    * forbid 'git add -u|-A' without pathspec (like 'git add' without
      option)
    
    * much later, maybe, re-allow 'git add -u|-A' without pathspec, that
      will add all tracked and modified files, or all files, tree-wide.
    
    A nice side effect of this patch is that it makes the :/ magic
    pathspec easier to discover for users.
    
    When the command is called from the root of the tree, there is no
    ambiguity and no need to change the behavior, hence no need to warn.
    
    Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> I think "add -u && commit" vs "commit -a" you brought up is a good
> thing to mention, so let's do this.

I'm OK with your proposal. Let me know if you want me to resend.

>     The inconsistency of 'git add -u' and 'git add -A' are particularly

Nitpick: this should be "inconsistencies" (or "is particularly").

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I think "add -u && commit" vs "commit -a" you brought up is a good
>> thing to mention, so let's do this.
>
> I'm OK with your proposal. Let me know if you want me to resend.

Thanks for a quick response.  As you may have guessed, I am sending
these after running "commit --amend", so ...

>>     The inconsistency of 'git add -u' and 'git add -A' are particularly
>
> Nitpick: this should be "inconsistencies" (or "is particularly").

... it is much easier for me to fix these locally instead of getting
a reroll.

Will amend with s/are particularly/is particularly/; thanks.

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> We should probably update the documentation/help for "git add", but
> that is entirely a separate topic.

The documentation update in 0fa2eb530fb7 (add: warn when -u or -A is
used without pathspec, 2013-01-28) says:

    If no <pathspec> is given, the current version of Git defaults to
    "."; in other words, update all tracked files in the current directory
    and its subdirectories. This default will change in a future version
    of Git, hence the form without <filepattern> should not be used.

(oops, I just spotted a stray <filepattern> here, which came from a
semantic mismerge---I'll fix it locally).

The above text says that we currently add what you have in your
current directory and below, before it says this default will
change.  That makes it easier to connect "the default will change"
and "form without pathspec should not be used" in readers' mind.  It
does not take that much imagination and intelligence to infer "it
will change and will not limit to my current directory, so in the
future I will have to be explicit when I want to do what I just told
git to do".

But the warning text does not sound quite right.  This is what I get:

    warning: The behavior of 'git add --update (or -u)' with no path argument from a
    subdirectory of the tree will change in Git 2.0 and should not be used anymore.

There is a logic gap between "will change" and "should not be used"
that is not filled like the text in the manual page does.

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>     warning: The behavior of 'git add --update (or -u)' with no path argument from a
>     subdirectory of the tree will change in Git 2.0 and should not be used anymore.
>
> There is a logic gap between "will change" and "should not be used"
> that is not filled like the text in the manual page does.

I guess it is not so bad after all, if you read the entire message,
not just the first two lines.

Re: [PATCH v3] add: warn when -u or -A is used without filepattern

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>     warning: The behavior of 'git add --update (or -u)' with no path argument from a
>>     subdirectory of the tree will change in Git 2.0 and should not be used anymore.
>>
>> There is a logic gap between "will change" and "should not be used"
>> that is not filled like the text in the manual page does.
>
> I guess it is not so bad after all, if you read the entire message,
> not just the first two lines.

Also, the warning is meant to be read by a user who just typed
"git add -u", so it is expected that the user knows what it does in
current (or past) versions of Git.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Junio C Hamano]

Eric James Michael Ritz <lobbyjones@gmail.com> writes:

> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
>> I think `git add -u` would be closer. It would stage removal of
>> files, but would not stage untracked files.  It would stage other
>> type of changes though.
>
> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
>> Does `git add -A` do what you want?
>
> Thank you Tomas and Antoine.  Both of these commands do what I want:
> stage deleted files on the index.  But does the idea of a `git rm -u`
> still sound useful since these commands also stage changes besides
> deleted files?

Even though I am not sure how often I would use it myself, "reflect
only the removals in the working tree to the index, but exclude any
other kind of changes" might turn out to be a useful addition to the
toolchest in certain cases.

I however am not yet convinced that "git rm -u" is a good way to
express the feature at the UI.  "git add -u" is "update the index
with modification and removal but ignore new files because we won't
know if they are garbage or assets".  What the same "-u" option
means in the context of "git rm" is not very clear, at least to me.

Re: [RFC] git rm -u

[Antoine Pelisse]

I must say that I'm not very interested in the feature. In my opinion,
there are already many different ways to stage changes.
Assuming that the feature would be needed, I would keep it under the
scope of git-add, as it's the reference for staging. I would suggest
something like:

    git add -r   "Stage removal of deleted files."

On Mon, Feb 25, 2013 at 7:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric James Michael Ritz <lobbyjones@gmail.com> writes:
>
>> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
>>> I think `git add -u` would be closer. It would stage removal of
>>> files, but would not stage untracked files.  It would stage other
>>> type of changes though.
>>
>> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
>>> Does `git add -A` do what you want?
>>
>> Thank you Tomas and Antoine.  Both of these commands do what I want:
>> stage deleted files on the index.  But does the idea of a `git rm -u`
>> still sound useful since these commands also stage changes besides
>> deleted files?
>
> Even though I am not sure how often I would use it myself, "reflect
> only the removals in the working tree to the index, but exclude any
> other kind of changes" might turn out to be a useful addition to the
> toolchest in certain cases.
>
> I however am not yet convinced that "git rm -u" is a good way to
> express the feature at the UI.  "git add -u" is "update the index
> with modification and removal but ignore new files because we won't
> know if they are garbage or assets".  What the same "-u" option
> means in the context of "git rm" is not very clear, at least to me.
>
>

Re: [RFC] git rm -u

[Matthieu Moy]

Antoine Pelisse <apelisse@gmail.com> writes:

> I must say that I'm not very interested in the feature. In my opinion,
> there are already many different ways to stage changes.
> Assuming that the feature would be needed, I would keep it under the
> scope of git-add, as it's the reference for staging. I would suggest
> something like:
>
>     git add -r   "Stage removal of deleted files."

Would "add -r" stand for "add --remove"? That would be weird ...

"git rm" really seems to be a better place for removing files from the
index.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Antoine Pelisse]

On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> I must say that I'm not very interested in the feature. In my opinion,
>> there are already many different ways to stage changes.
>> Assuming that the feature would be needed, I would keep it under the
>> scope of git-add, as it's the reference for staging. I would suggest
>> something like:
>>
>>     git add -r   "Stage removal of deleted files."
>
> Would "add -r" stand for "add --remove"? That would be weird ...

Yes (for --remove),
It would not be weird if you consider the opposite of add to be reset
(and not rm).

> "git rm" really seems to be a better place for removing files from the
> index.

Then, I don't exactly understand the meaning of git-rm but being a
_shortcut_ for "remove and stage". Here the files are already removed,
we only need to stage and the best command to stage changes is add.

Re: [RFC] git rm -u

[Matthieu Moy]

Antoine Pelisse <apelisse@gmail.com> writes:

>> "git rm" really seems to be a better place for removing files from the
>> index.
>
> Then, I don't exactly understand the meaning of git-rm but being a
> _shortcut_ for "remove and stage".

"git rm --cached" is exactly "remove from index".

And even without --cached, as you notice yourself, it does a "remove and
stage [removal]", so why would it be inappropriate to stage a removal?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] git rm -u

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Antoine Pelisse <apelisse@gmail.com> writes:
>
>>> "git rm" really seems to be a better place for removing files from the
>>> index.
>>
>> Then, I don't exactly understand the meaning of git-rm but being a
>> _shortcut_ for "remove and stage".
>
> "git rm --cached" is exactly "remove from index".
>
> And even without --cached, as you notice yourself, it does a "remove and
> stage [removal]", so why would it be inappropriate to stage a removal?

I do not think "git rm" is a bad place to add the feature; I was
questioning if "-u" is an appropriate option.  The option "-u" given
to "git add" is internally called "take worktree changes", and we
would need the option to "git rm" with that internal meaning.  The
superficial meaning "updated" that "-u" in "add -u" stands for does
not really match what "git rm --take-worktree-changes" wants to do,
as we obviously do not want to remove all updated/modified files.