threads / rfc / 32672

[RFC] git rm -u

Subject: [RFC] git rm -u

## tl;dr

53 messages between Jan 19, 2013 and Feb 25, 2013.

replies: 52people: 12as markdown or json

Eric James Michael Ritz· Jan 19, 2013, 21:35 UTC · lore
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 南無妙法蓮華經

Tomas Carnecky· Jan 19, 2013, 21:47 UTC · re: Eric James Michael Ritz · lore

Re: [RFC] git rm -u

On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz <lobbyjones@gmail.com> wrote:
Show 24 quoted lines
> 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?
Antoine Pelisse· Jan 19, 2013, 21:49 UTC · re: Tomas Carnecky · lore

Re: [RFC] git rm -u

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:

Show 31 quoted lines
> 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
Eric James Michael Ritz· Jan 19, 2013, 21:56 UTC · re: Antoine Pelisse · lore

Re: [RFC] git rm -u

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 南無妙法蓮華經

Junio C Hamano· Feb 25, 2013, 06:54 UTC · re: Eric James Michael Ritz · lore

Re: [RFC] git rm -u

Eric James Michael Ritz <lobbyjones@gmail.com> writes:
Show 12 quoted lines
> 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.

Antoine Pelisse· Feb 25, 2013, 18:54 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

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:
Show 27 quoted lines
> 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.
>
>
Matthieu Moy· Feb 25, 2013, 19:07 UTC · re: Antoine Pelisse · lore

Re: [RFC] git rm -u

Antoine Pelisse <apelisse@gmail.com> writes:
Show 7 quoted lines
> 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/
Antoine Pelisse· Feb 25, 2013, 19:21 UTC · re: Matthieu Moy · lore

Re: [RFC] git rm -u

On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 11 quoted lines
> 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.

Matthieu Moy· Feb 25, 2013, 19:39 UTC · re: Antoine Pelisse · lore

Re: [RFC] git rm -u

Antoine Pelisse <apelisse@gmail.com> writes:
Show 5 quoted lines
>> "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/
Junio C Hamano· Feb 25, 2013, 19:47 UTC · re: Matthieu Moy · lore

Re: [RFC] git rm -u

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 12 quoted lines
> 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.

Jonathan Nieder· Jan 19, 2013, 21:49 UTC · re: Eric James Michael Ritz · lore

Re: [RFC] git rm -u

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

Eric James Michael Ritz· Jan 19, 2013, 22:01 UTC · re: Jonathan Nieder · lore

Re: [RFC] git rm -u

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 南無妙法蓮華經

Matthieu Moy· Jan 20, 2013, 11:32 UTC · re: Jonathan Nieder · lore

Re: [RFC] git rm -u

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 9 quoted lines
> 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/
Junio C Hamano· Jan 20, 2013, 18:42 UTC · re: Matthieu Moy · lore

Re: [RFC] git rm -u

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?
Junio C Hamano· Jan 20, 2013, 21:27 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> 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.
Martin von Zweigbergk· Jan 20, 2013, 22:17 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> 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.

Matthieu Moy· Jan 21, 2013, 08:44 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> 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/
Junio C Hamano· Jan 20, 2013, 18:53 UTC · re: Matthieu Moy · lore

Re: [RFC] git rm -u

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 6 quoted lines
> 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".

Eric James Michael Ritz· Jan 20, 2013, 19:21 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

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 南無妙法蓮華經

Piotr Krukowiecki· Jan 21, 2013, 08:09 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> 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

Matthieu Moy· Jan 21, 2013, 08:37 UTC · re: Piotr Krukowiecki · lore

Re: [RFC] git rm -u

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/
Junio C Hamano· Jan 21, 2013, 09:23 UTC · re: Piotr Krukowiecki · lore

Re: [RFC] git rm -u

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.

Junio C Hamano· Jan 21, 2013, 19:01 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> 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.

Matthieu Moy· Jan 21, 2013, 20:03 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

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/
Junio C Hamano· Jan 21, 2013, 23:18 UTC · re: Matthieu Moy · lore

Re: [RFC] git rm -u

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 14 quoted lines
> 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.

Piotr Krukowiecki· Jan 21, 2013, 19:10 UTC · re: Junio C Hamano · lore

Re: [RFC] git rm -u

On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> 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

Matthieu Moy· Jan 21, 2013, 12:00 UTC · re: Junio C Hamano · lore

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

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
Robin Rosenberg· Jan 21, 2013, 15:00 UTC · re: Matthieu Moy · lore

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

----- Ursprungligt meddelande -----
Show 19 quoted lines
> 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
Matthieu Moy· Jan 21, 2013, 15:16 UTC · re: Robin Rosenberg · lore

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

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/
Robin Rosenberg· Jan 21, 2013, 20:29 UTC · re: Matthieu Moy · lore

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

----- Ursprungligt meddelande -----
Show 8 quoted lines
> > 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
Junio C Hamano· Jan 21, 2013, 19:12 UTC · re: Matthieu Moy · lore

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

Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Show 20 quoted lines
> 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.
Show 5 quoted lines
> 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?

Piotr Krukowiecki· Jan 21, 2013, 19:34 UTC · re: Junio C Hamano · lore

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

On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 28 quoted lines
> 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

Matthieu Moy· Jan 21, 2013, 20:06 UTC · re: Piotr Krukowiecki · lore

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

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/
Matthieu Moy· Jan 21, 2013, 20:10 UTC · re: Junio C Hamano · lore

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

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/
Jonathan Nieder· Jan 21, 2013, 22:22 UTC · re: Matthieu Moy · lore

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

Hi,
Matthieu Moy wrote:
Show 7 quoted lines
> 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
[...]
Show 12 quoted lines
> +	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

Matthieu Moy· Jan 22, 2013, 07:39 UTC · re: Jonathan Nieder · lore

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

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 7 quoted lines
> 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/
Matthieu Moy· Jan 25, 2013, 10:49 UTC · re: Matthieu Moy · lore

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

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
Junio C Hamano· Jan 25, 2013, 19:27 UTC · re: Matthieu Moy · lore

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

Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Show 5 quoted lines
> 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/;
Show 11 quoted lines
> 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.
Show 19 quoted lines
> +	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.
Matthieu Moy· Jan 27, 2013, 16:10 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> 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.
Show 11 quoted lines
> 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/
Junio C Hamano· Jan 27, 2013, 20:33 UTC · re: Matthieu Moy · lore

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

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;
 	}
Matthieu Moy· Jan 28, 2013, 08:48 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> 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/
Matthieu Moy· Jan 28, 2013, 09:16 UTC · re: Matthieu Moy · lore

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

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
Jonathan Nieder· Jan 28, 2013, 09:20 UTC · re: Matthieu Moy · lore

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

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

Michael J Gruber· Jan 28, 2013, 12:47 UTC · re: Matthieu Moy · lore

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

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

Show 123 quoted lines
> 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;
>  	}
> 
Junio C Hamano· Jan 28, 2013, 18:07 UTC · re: Michael J Gruber · lore

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

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 12 quoted lines
> 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>
Matthieu Moy· Jan 28, 2013, 18:25 UTC · re: Junio C Hamano · lore

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

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/
Junio C Hamano· Jan 28, 2013, 18:31 UTC · re: Matthieu Moy · lore

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

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 6 quoted lines
> 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.
Junio C Hamano· Feb 14, 2013, 23:36 UTC · re: Junio C Hamano · lore

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

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.

Junio C Hamano· Feb 14, 2013, 23:55 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 5 quoted lines
>     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.

Matthieu Moy· Feb 15, 2013, 10:00 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> 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/
Jonathan Nieder· Jan 27, 2013, 12:22 UTC · re: Matthieu Moy · lore

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

Hi Matthieu,
Matthieu Moy wrote:
> --- a/builtin/add.c
> +++ b/builtin/add.c
[...]
Show 9 quoted lines
> @@ -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.

Duy Nguyen· Jan 22, 2013, 01:10 UTC · re: Matthieu Moy · lore

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

On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
Show 17 quoted lines
> 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
Junio C Hamano· Jan 22, 2013, 01:51 UTC · re: Duy Nguyen · lore

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

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

← back to recent threads