git rm -u

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

Does git add -A do what you want?

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

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

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.

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/

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

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.

"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/

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.

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

Thanks,
Jonathan

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

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/

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

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

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.

---

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

index fd9e36b..5333559 100644
@@ -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::

index e664100..e6eb829 100644
@@ -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

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

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

git diff
#looks good
git add -u

-- robin

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

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/

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

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

Hi,

Thanks for tackling this.

[...]

		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/

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.

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

index fd9e36b..5333559 100644
@@ -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::

index e664100..8252d19 100644
@@ -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

s/consistan/consisten/;

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

Thanks, will fix.

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/

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

index 7552f7f..ba72a57 100644
@@ -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;
 	}

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

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

Resend comming soon.

Matthieu Moy
http://www-verimag.imag.fr/~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.

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

index fd9e36b..5333559 100644
@@ -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::

1.8.1.1.440.g1d329bd.dirty

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

Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:

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

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.

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

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

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

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

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

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

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.

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/

Hi Matthieu,

[...]

Nicely explained.

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?

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

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/

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/

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

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

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

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.

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.

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.

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/

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.

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

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/

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.

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.

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/