* [RFC] git rm -u @ 2013-01-19 21:35 Eric James Michael Ritz 2013-01-19 21:47 ` Tomas Carnecky 2013-01-19 21:49 ` Jonathan Nieder 0 siblings, 2 replies; 53+ messages in thread From: Eric James Michael Ritz @ 2013-01-19 21:35 UTC (permalink / raw) To: git 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 南無妙法蓮華經 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:35 [RFC] git rm -u Eric James Michael Ritz @ 2013-01-19 21:47 ` Tomas Carnecky 2013-01-19 21:49 ` Antoine Pelisse 2013-01-19 21:49 ` Jonathan Nieder 1 sibling, 1 reply; 53+ messages in thread From: Tomas Carnecky @ 2013-01-19 21:47 UTC (permalink / raw) To: Eric James Michael Ritz, git 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? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:47 ` Tomas Carnecky @ 2013-01-19 21:49 ` Antoine Pelisse 2013-01-19 21:56 ` Eric James Michael Ritz 0 siblings, 1 reply; 53+ messages in thread From: Antoine Pelisse @ 2013-01-19 21:49 UTC (permalink / raw) To: Tomas Carnecky; +Cc: Eric James Michael Ritz, git 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:49 ` Antoine Pelisse @ 2013-01-19 21:56 ` Eric James Michael Ritz 2013-02-25 6:54 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Eric James Michael Ritz @ 2013-01-19 21:56 UTC (permalink / raw) To: Antoine Pelisse; +Cc: Tomas Carnecky, git 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 南無妙法蓮華經 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:56 ` Eric James Michael Ritz @ 2013-02-25 6:54 ` Junio C Hamano 2013-02-25 18:54 ` Antoine Pelisse 0 siblings, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-02-25 6:54 UTC (permalink / raw) To: Eric James Michael Ritz; +Cc: Antoine Pelisse, Tomas Carnecky, git 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-02-25 6:54 ` Junio C Hamano @ 2013-02-25 18:54 ` Antoine Pelisse 2013-02-25 19:07 ` Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Antoine Pelisse @ 2013-02-25 18:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eric James Michael Ritz, Tomas Carnecky, git 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. > > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-02-25 18:54 ` Antoine Pelisse @ 2013-02-25 19:07 ` Matthieu Moy 2013-02-25 19:21 ` Antoine Pelisse 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-02-25 19:07 UTC (permalink / raw) To: Antoine Pelisse Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-02-25 19:07 ` Matthieu Moy @ 2013-02-25 19:21 ` Antoine Pelisse 2013-02-25 19:39 ` Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Antoine Pelisse @ 2013-02-25 19:21 UTC (permalink / raw) To: Matthieu Moy; +Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-02-25 19:21 ` Antoine Pelisse @ 2013-02-25 19:39 ` Matthieu Moy 2013-02-25 19:47 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-02-25 19:39 UTC (permalink / raw) To: Antoine Pelisse Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-02-25 19:39 ` Matthieu Moy @ 2013-02-25 19:47 ` Junio C Hamano 0 siblings, 0 replies; 53+ messages in thread From: Junio C Hamano @ 2013-02-25 19:47 UTC (permalink / raw) To: Matthieu Moy Cc: Antoine Pelisse, Eric James Michael Ritz, Tomas Carnecky, git 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:35 [RFC] git rm -u Eric James Michael Ritz 2013-01-19 21:47 ` Tomas Carnecky @ 2013-01-19 21:49 ` Jonathan Nieder 2013-01-19 22:01 ` Eric James Michael Ritz 2013-01-20 11:32 ` Matthieu Moy 1 sibling, 2 replies; 53+ messages in thread From: Jonathan Nieder @ 2013-01-19 21:49 UTC (permalink / raw) To: Eric James Michael Ritz; +Cc: git, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:49 ` Jonathan Nieder @ 2013-01-19 22:01 ` Eric James Michael Ritz 2013-01-20 11:32 ` Matthieu Moy 1 sibling, 0 replies; 53+ messages in thread From: Eric James Michael Ritz @ 2013-01-19 22:01 UTC (permalink / raw) To: Jonathan Nieder; +Cc: git, Tomas Carnecky 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 南無妙法蓮華經 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-19 21:49 ` Jonathan Nieder 2013-01-19 22:01 ` Eric James Michael Ritz @ 2013-01-20 11:32 ` Matthieu Moy 2013-01-20 18:42 ` Junio C Hamano 2013-01-20 18:53 ` Junio C Hamano 1 sibling, 2 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-20 11:32 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Eric James Michael Ritz, git, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 11:32 ` Matthieu Moy @ 2013-01-20 18:42 ` Junio C Hamano 2013-01-20 21:27 ` Junio C Hamano 2013-01-21 8:44 ` Matthieu Moy 2013-01-20 18:53 ` Junio C Hamano 1 sibling, 2 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-20 18:42 UTC (permalink / raw) To: Matthieu Moy Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky 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? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 18:42 ` Junio C Hamano @ 2013-01-20 21:27 ` Junio C Hamano 2013-01-20 22:17 ` Martin von Zweigbergk 2013-01-21 8:44 ` Matthieu Moy 1 sibling, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-01-20 21:27 UTC (permalink / raw) To: Matthieu Moy Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 21:27 ` Junio C Hamano @ 2013-01-20 22:17 ` Martin von Zweigbergk 0 siblings, 0 replies; 53+ messages in thread From: Martin von Zweigbergk @ 2013-01-20 22:17 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 18:42 ` Junio C Hamano 2013-01-20 21:27 ` Junio C Hamano @ 2013-01-21 8:44 ` Matthieu Moy 1 sibling, 0 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 8:44 UTC (permalink / raw) To: Junio C Hamano Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 11:32 ` Matthieu Moy 2013-01-20 18:42 ` Junio C Hamano @ 2013-01-20 18:53 ` Junio C Hamano 2013-01-20 19:21 ` Eric James Michael Ritz ` (2 more replies) 1 sibling, 3 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-20 18:53 UTC (permalink / raw) To: Matthieu Moy Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky 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". ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 18:53 ` Junio C Hamano @ 2013-01-20 19:21 ` Eric James Michael Ritz 2013-01-21 8:09 ` Piotr Krukowiecki 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy 2 siblings, 0 replies; 53+ messages in thread From: Eric James Michael Ritz @ 2013-01-20 19:21 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matthieu Moy, Jonathan Nieder, git, Tomas Carnecky 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 南無妙法蓮華經 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-20 18:53 ` Junio C Hamano 2013-01-20 19:21 ` Eric James Michael Ritz @ 2013-01-21 8:09 ` Piotr Krukowiecki 2013-01-21 8:37 ` Matthieu Moy 2013-01-21 9:23 ` Junio C Hamano 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy 2 siblings, 2 replies; 53+ messages in thread From: Piotr Krukowiecki @ 2013-01-21 8:09 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 8:09 ` Piotr Krukowiecki @ 2013-01-21 8:37 ` Matthieu Moy 2013-01-21 9:23 ` Junio C Hamano 1 sibling, 0 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 8:37 UTC (permalink / raw) To: Piotr Krukowiecki Cc: Junio C Hamano, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 8:09 ` Piotr Krukowiecki 2013-01-21 8:37 ` Matthieu Moy @ 2013-01-21 9:23 ` Junio C Hamano 2013-01-21 19:01 ` Junio C Hamano 2013-01-21 19:10 ` Piotr Krukowiecki 1 sibling, 2 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-21 9:23 UTC (permalink / raw) To: Piotr Krukowiecki Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 9:23 ` Junio C Hamano @ 2013-01-21 19:01 ` Junio C Hamano 2013-01-21 20:03 ` Matthieu Moy 2013-01-21 19:10 ` Piotr Krukowiecki 1 sibling, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-01-21 19:01 UTC (permalink / raw) To: Piotr Krukowiecki Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 19:01 ` Junio C Hamano @ 2013-01-21 20:03 ` Matthieu Moy 2013-01-21 23:18 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 20:03 UTC (permalink / raw) To: Junio C Hamano Cc: Piotr Krukowiecki, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 20:03 ` Matthieu Moy @ 2013-01-21 23:18 ` Junio C Hamano 0 siblings, 0 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-21 23:18 UTC (permalink / raw) To: Matthieu Moy Cc: Piotr Krukowiecki, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC] git rm -u 2013-01-21 9:23 ` Junio C Hamano 2013-01-21 19:01 ` Junio C Hamano @ 2013-01-21 19:10 ` Piotr Krukowiecki 1 sibling, 0 replies; 53+ messages in thread From: Piotr Krukowiecki @ 2013-01-21 19:10 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, Git Mailing List, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-20 18:53 ` Junio C Hamano 2013-01-20 19:21 ` Eric James Michael Ritz 2013-01-21 8:09 ` Piotr Krukowiecki @ 2013-01-21 12:00 ` Matthieu Moy 2013-01-21 15:00 ` Robin Rosenberg ` (3 more replies) 2 siblings, 4 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 12:00 UTC (permalink / raw) To: git, gitster Cc: Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky, 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 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy @ 2013-01-21 15:00 ` Robin Rosenberg 2013-01-21 15:16 ` Matthieu Moy 2013-01-21 19:12 ` Junio C Hamano ` (2 subsequent siblings) 3 siblings, 1 reply; 53+ messages in thread From: Robin Rosenberg @ 2013-01-21 15:00 UTC (permalink / raw) To: Matthieu Moy Cc: Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky, git, gitster ----- 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 15:00 ` Robin Rosenberg @ 2013-01-21 15:16 ` Matthieu Moy 2013-01-21 20:29 ` Robin Rosenberg 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 15:16 UTC (permalink / raw) To: Robin Rosenberg Cc: Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky, git, gitster 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 15:16 ` Matthieu Moy @ 2013-01-21 20:29 ` Robin Rosenberg 0 siblings, 0 replies; 53+ messages in thread From: Robin Rosenberg @ 2013-01-21 20:29 UTC (permalink / raw) To: Matthieu Moy Cc: Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky, git, gitster ----- 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy 2013-01-21 15:00 ` Robin Rosenberg @ 2013-01-21 19:12 ` Junio C Hamano 2013-01-21 19:34 ` Piotr Krukowiecki 2013-01-21 20:10 ` Matthieu Moy 2013-01-21 22:22 ` Jonathan Nieder 2013-01-22 1:10 ` [RFC/PATCH] " Duy Nguyen 3 siblings, 2 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-21 19:12 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 19:12 ` Junio C Hamano @ 2013-01-21 19:34 ` Piotr Krukowiecki 2013-01-21 20:06 ` Matthieu Moy 2013-01-21 20:10 ` Matthieu Moy 1 sibling, 1 reply; 53+ messages in thread From: Piotr Krukowiecki @ 2013-01-21 19:34 UTC (permalink / raw) To: Junio C Hamano Cc: Matthieu Moy, Git Mailing List, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 19:34 ` Piotr Krukowiecki @ 2013-01-21 20:06 ` Matthieu Moy 0 siblings, 0 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 20:06 UTC (permalink / raw) To: Piotr Krukowiecki Cc: Junio C Hamano, Git Mailing List, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 19:12 ` Junio C Hamano 2013-01-21 19:34 ` Piotr Krukowiecki @ 2013-01-21 20:10 ` Matthieu Moy 1 sibling, 0 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-21 20:10 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy 2013-01-21 15:00 ` Robin Rosenberg 2013-01-21 19:12 ` Junio C Hamano @ 2013-01-21 22:22 ` Jonathan Nieder 2013-01-22 7:39 ` Matthieu Moy 2013-01-22 1:10 ` [RFC/PATCH] " Duy Nguyen 3 siblings, 1 reply; 53+ messages in thread From: Jonathan Nieder @ 2013-01-21 22:22 UTC (permalink / raw) To: Matthieu Moy; +Cc: git, gitster, Eric James Michael Ritz, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 22:22 ` Jonathan Nieder @ 2013-01-22 7:39 ` Matthieu Moy 2013-01-25 10:49 ` [PATCH v2] " Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-22 7:39 UTC (permalink / raw) To: Jonathan Nieder; +Cc: git, gitster, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-22 7:39 ` Matthieu Moy @ 2013-01-25 10:49 ` Matthieu Moy 2013-01-25 19:27 ` Junio C Hamano 2013-01-27 12:22 ` [PATCH v2] " Jonathan Nieder 0 siblings, 2 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-25 10:49 UTC (permalink / raw) To: git, gitster Cc: Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky, 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 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-25 10:49 ` [PATCH v2] " Matthieu Moy @ 2013-01-25 19:27 ` Junio C Hamano 2013-01-27 16:10 ` Matthieu Moy 2013-01-27 12:22 ` [PATCH v2] " Jonathan Nieder 1 sibling, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-01-25 19:27 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-25 19:27 ` Junio C Hamano @ 2013-01-27 16:10 ` Matthieu Moy 2013-01-27 20:33 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-27 16:10 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-27 16:10 ` Matthieu Moy @ 2013-01-27 20:33 ` Junio C Hamano 2013-01-28 8:48 ` Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-01-27 20:33 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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; } ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-27 20:33 ` Junio C Hamano @ 2013-01-28 8:48 ` Matthieu Moy 2013-01-28 9:16 ` [PATCH v3] " Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-28 8:48 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 8:48 ` Matthieu Moy @ 2013-01-28 9:16 ` Matthieu Moy 2013-01-28 9:20 ` Jonathan Nieder 2013-01-28 12:47 ` Michael J Gruber 0 siblings, 2 replies; 53+ messages in thread From: Matthieu Moy @ 2013-01-28 9:16 UTC (permalink / raw) To: git, gitster Cc: Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky, 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 ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 9:16 ` [PATCH v3] " Matthieu Moy @ 2013-01-28 9:20 ` Jonathan Nieder 2013-01-28 12:47 ` Michael J Gruber 1 sibling, 0 replies; 53+ messages in thread From: Jonathan Nieder @ 2013-01-28 9:20 UTC (permalink / raw) To: Matthieu Moy Cc: git, gitster, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 9:16 ` [PATCH v3] " Matthieu Moy 2013-01-28 9:20 ` Jonathan Nieder @ 2013-01-28 12:47 ` Michael J Gruber 2013-01-28 18:07 ` Junio C Hamano 1 sibling, 1 reply; 53+ messages in thread From: Michael J Gruber @ 2013-01-28 12:47 UTC (permalink / raw) To: Matthieu Moy Cc: git, gitster, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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; > } > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 12:47 ` Michael J Gruber @ 2013-01-28 18:07 ` Junio C Hamano 2013-01-28 18:25 ` Matthieu Moy 2013-02-14 23:36 ` Junio C Hamano 0 siblings, 2 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-28 18:07 UTC (permalink / raw) To: Michael J Gruber Cc: Matthieu Moy, git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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> ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 18:07 ` Junio C Hamano @ 2013-01-28 18:25 ` Matthieu Moy 2013-01-28 18:31 ` Junio C Hamano 2013-02-14 23:36 ` Junio C Hamano 1 sibling, 1 reply; 53+ messages in thread From: Matthieu Moy @ 2013-01-28 18:25 UTC (permalink / raw) To: Junio C Hamano Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 18:25 ` Matthieu Moy @ 2013-01-28 18:31 ` Junio C Hamano 0 siblings, 0 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-28 18:31 UTC (permalink / raw) To: Matthieu Moy Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-01-28 18:07 ` Junio C Hamano 2013-01-28 18:25 ` Matthieu Moy @ 2013-02-14 23:36 ` Junio C Hamano 2013-02-14 23:55 ` Junio C Hamano 1 sibling, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-02-14 23:36 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky, Michael J Gruber 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-02-14 23:36 ` Junio C Hamano @ 2013-02-14 23:55 ` Junio C Hamano 2013-02-15 10:00 ` Matthieu Moy 0 siblings, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2013-02-14 23:55 UTC (permalink / raw) To: Matthieu Moy Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky, Michael J Gruber 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern 2013-02-14 23:55 ` Junio C Hamano @ 2013-02-15 10:00 ` Matthieu Moy 0 siblings, 0 replies; 53+ messages in thread From: Matthieu Moy @ 2013-02-15 10:00 UTC (permalink / raw) To: Junio C Hamano Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky, Michael J Gruber 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/ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern 2013-01-25 10:49 ` [PATCH v2] " Matthieu Moy 2013-01-25 19:27 ` Junio C Hamano @ 2013-01-27 12:22 ` Jonathan Nieder 1 sibling, 0 replies; 53+ messages in thread From: Jonathan Nieder @ 2013-01-27 12:22 UTC (permalink / raw) To: Matthieu Moy Cc: git, gitster, Robin Rosenberg, Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy ` (2 preceding siblings ...) 2013-01-21 22:22 ` Jonathan Nieder @ 2013-01-22 1:10 ` Duy Nguyen 2013-01-22 1:51 ` Junio C Hamano 3 siblings, 1 reply; 53+ messages in thread From: Duy Nguyen @ 2013-01-22 1:10 UTC (permalink / raw) To: Matthieu Moy Cc: git, gitster, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern 2013-01-22 1:10 ` [RFC/PATCH] " Duy Nguyen @ 2013-01-22 1:51 ` Junio C Hamano 0 siblings, 0 replies; 53+ messages in thread From: Junio C Hamano @ 2013-01-22 1:51 UTC (permalink / raw) To: Duy Nguyen Cc: Matthieu Moy, git, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky 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)? ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2013-02-25 19:47 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-19 21:35 [RFC] git rm -u Eric James Michael Ritz 2013-01-19 21:47 ` Tomas Carnecky 2013-01-19 21:49 ` Antoine Pelisse 2013-01-19 21:56 ` Eric James Michael Ritz 2013-02-25 6:54 ` Junio C Hamano 2013-02-25 18:54 ` Antoine Pelisse 2013-02-25 19:07 ` Matthieu Moy 2013-02-25 19:21 ` Antoine Pelisse 2013-02-25 19:39 ` Matthieu Moy 2013-02-25 19:47 ` Junio C Hamano 2013-01-19 21:49 ` Jonathan Nieder 2013-01-19 22:01 ` Eric James Michael Ritz 2013-01-20 11:32 ` Matthieu Moy 2013-01-20 18:42 ` Junio C Hamano 2013-01-20 21:27 ` Junio C Hamano 2013-01-20 22:17 ` Martin von Zweigbergk 2013-01-21 8:44 ` Matthieu Moy 2013-01-20 18:53 ` Junio C Hamano 2013-01-20 19:21 ` Eric James Michael Ritz 2013-01-21 8:09 ` Piotr Krukowiecki 2013-01-21 8:37 ` Matthieu Moy 2013-01-21 9:23 ` Junio C Hamano 2013-01-21 19:01 ` Junio C Hamano 2013-01-21 20:03 ` Matthieu Moy 2013-01-21 23:18 ` Junio C Hamano 2013-01-21 19:10 ` Piotr Krukowiecki 2013-01-21 12:00 ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy 2013-01-21 15:00 ` Robin Rosenberg 2013-01-21 15:16 ` Matthieu Moy 2013-01-21 20:29 ` Robin Rosenberg 2013-01-21 19:12 ` Junio C Hamano 2013-01-21 19:34 ` Piotr Krukowiecki 2013-01-21 20:06 ` Matthieu Moy 2013-01-21 20:10 ` Matthieu Moy 2013-01-21 22:22 ` Jonathan Nieder 2013-01-22 7:39 ` Matthieu Moy 2013-01-25 10:49 ` [PATCH v2] " Matthieu Moy 2013-01-25 19:27 ` Junio C Hamano 2013-01-27 16:10 ` Matthieu Moy 2013-01-27 20:33 ` Junio C Hamano 2013-01-28 8:48 ` Matthieu Moy 2013-01-28 9:16 ` [PATCH v3] " Matthieu Moy 2013-01-28 9:20 ` Jonathan Nieder 2013-01-28 12:47 ` Michael J Gruber 2013-01-28 18:07 ` Junio C Hamano 2013-01-28 18:25 ` Matthieu Moy 2013-01-28 18:31 ` Junio C Hamano 2013-02-14 23:36 ` Junio C Hamano 2013-02-14 23:55 ` Junio C Hamano 2013-02-15 10:00 ` Matthieu Moy 2013-01-27 12:22 ` [PATCH v2] " Jonathan Nieder 2013-01-22 1:10 ` [RFC/PATCH] " Duy Nguyen 2013-01-22 1:51 ` Junio C Hamano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.