[PATCH/RFC 0/3] add/commit -u/-a/-A

[PATCH/RFC 0/3] add/commit -u/-a/-A

[Michael J Gruber]

This is the first part of the grand add/commit unification.
It makes the use of -u,-a,-A and the long names uniform across
add and commit, breaking only "commit --all" (by renaming it).

It comes before Jeff's series from p^3u which refactors add/commit and
implements "commit -A".

Michael J Gruber (3):
  git-add: make -A description clearer vs. -u
  git-commit: rename --all to --track
  git-add: rename -u to -a

 Documentation/git-add.txt         |    8 ++++----
 Documentation/git-commit.txt      |    2 +-
 Documentation/git-rm.txt          |    2 +-
 Documentation/gitattributes.txt   |    4 ++--
 builtin/add.c                     |    7 ++++---
 builtin/commit.c                  |   12 ++++++------
 t/t1511-rev-parse-caret.sh        |    2 +-
 t/t2200-add-update.sh             |   26 +++++++++++++-------------
 t/t2201-add-update-typechange.sh  |    6 +++---
 t/t2203-add-intent.sh             |    2 +-
 t/t3030-merge-recursive.sh        |    2 +-
 t/t3415-rebase-autosquash.sh      |   16 ++++++++--------
 t/t4037-diff-r-t-dirs.sh          |    2 +-
 t/t6022-merge-rename.sh           |    2 +-
 t/t6036-recursive-corner-cases.sh |    2 +-
 15 files changed, 48 insertions(+), 47 deletions(-)

-- 
1.7.4.1.224.gefc87

[PATCH/RFC 1/3] git-add: make -A description clearer vs. -u

[Michael J Gruber]

Currently, it sounds as if "notice removal of files" distinguishes "-A"
from "-u", and there is no mention of the worktree.

But both notice the removal, and only "-A" adds changes from untracked
files. Say so.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 builtin/add.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index f8e51f9..f7a17e4 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -322,7 +322,7 @@ static struct option builtin_add_options[] = {
 	OPT__FORCE(&ignored_too, "allow adding otherwise ignored files"),
 	OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
 	OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
-	OPT_BOOLEAN('A', "all", &addremove, "add all, noticing removal of tracked files"),
+	OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
 	OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
 	OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
 	OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "check if - even missing - files are ignored in dry run"),
-- 
1.7.4.1.224.gefc87

[PATCH/RFC 2/3] git-commit: rename --all to --track

[Michael J Gruber]

Currently, the long option "--all" does different things for "add" (it
is "-A") and "commit" (it is "-a").

Rename the "commit" long option to "--tracked" which conveys the fact
that it is about all tracked files only.

Also, rename the corresponding static int in code from "all" to
"alltracked" to help future coders.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-commit.txt |    2 +-
 builtin/commit.c             |   12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 411fa68..0163d6d 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -54,7 +54,7 @@ that, you can recover from it with 'git reset'.
 OPTIONS
 -------
 -a::
---all::
+--tracked::
 	Tell the command to automatically stage files that have
 	been modified and deleted, but new files you have not
 	told git about are not affected.
diff --git a/builtin/commit.c b/builtin/commit.c
index d279a84..002cf03 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -83,7 +83,7 @@ static const char *template_file;
 static const char *author_message, *author_message_buffer;
 static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
-static int all, edit_flag, also, interactive, only, amend, signoff;
+static int alltracked, edit_flag, also, interactive, only, amend, signoff;
 static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
@@ -149,7 +149,7 @@ static struct option builtin_commit_options[] = {
 	/* end commit message options */
 
 	OPT_GROUP("Commit contents options"),
-	OPT_BOOLEAN('a', "all", &all, "commit all changed files"),
+	OPT_BOOLEAN('a', "tracked", &alltracked, "commit all changed tracked files"),
 	OPT_BOOLEAN('i', "include", &also, "add specified files to index for commit"),
 	OPT_BOOLEAN(0, "interactive", &interactive, "interactively add files"),
 	OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
@@ -367,7 +367,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 	 * (A) if all goes well, commit the real index;
 	 * (B) on failure, rollback the real index.
 	 */
-	if (all || (also && pathspec && *pathspec)) {
+	if (alltracked || (also && pathspec && *pathspec)) {
 		fd = hold_locked_index(&index_lock, 1);
 		add_files_to_cache(also ? prefix : NULL, pathspec, 0);
 		refresh_cache_or_die(refresh_flags);
@@ -1040,8 +1040,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
 		author_message_buffer = read_commit_message(author_message);
 	}
 
-	if (!!also + !!only + !!all + !!interactive > 1)
-		die("Only one of --include/--only/--all/--interactive can be used.");
+	if (!!also + !!only + !!alltracked + !!interactive > 1)
+		die("Only one of --include/--only/--tracked/--interactive can be used.");
 	if (argc == 0 && (also || (only && !amend)))
 		die("No paths with --include/--only does not make sense.");
 	if (argc == 0 && only && amend)
@@ -1061,7 +1061,7 @@ static int parse_and_validate_options(int argc, const char *argv[],
 
 	handle_untracked_files_arg(s);
 
-	if (all && argc > 0)
+	if (alltracked && argc > 0)
 		die("Paths with -a does not make sense.");
 	else if (interactive && argc > 0)
 		die("Paths with --interactive does not make sense.");
-- 
1.7.4.1.224.gefc87

[PATCH/RFC 3/3] git-add: rename -u to -a

[Michael J Gruber]

since it does what "commit -a" does (minus the committing). The long
form "--tracked" is also more descriptive because "add" always updates the
index (independent of "-u"), but not always for all tracked files.

Keep "-u,--update" as a hidden option because scripts may use it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-add.txt         |    8 ++++----
 Documentation/git-rm.txt          |    2 +-
 Documentation/gitattributes.txt   |    4 ++--
 builtin/add.c                     |    5 +++--
 t/t1511-rev-parse-caret.sh        |    2 +-
 t/t2200-add-update.sh             |   26 +++++++++++++-------------
 t/t2201-add-update-typechange.sh  |    6 +++---
 t/t2203-add-intent.sh             |    2 +-
 t/t3030-merge-recursive.sh        |    2 +-
 t/t3415-rebase-autosquash.sh      |   16 ++++++++--------
 t/t4037-diff-r-t-dirs.sh          |    2 +-
 t/t6022-merge-rename.sh           |    2 +-
 t/t6036-recursive-corner-cases.sh |    2 +-
 13 files changed, 40 insertions(+), 39 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index a03448f..8b54e77 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
-	  [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
+	  [--edit | -e] [[--all | -A ] | [--tracked | -a]] [--intent-to-add | -N]
 	  [--refresh] [--ignore-errors] [--ignore-missing] [--]
 	  [<filepattern>...]
 
@@ -98,8 +98,8 @@ quicker and more flexible than using the interactive hunk selector.
 However, it is easy to confuse oneself and create a patch that does not
 apply to the index. See EDITING PATCHES below.
 
--u::
---update::
+-a::
+--tracked::
 	Only match <filepattern> against already tracked files in
 	the index rather than the working tree. That means that it
 	will never stage new files, but that it will stage modified
@@ -113,7 +113,7 @@ subdirectories.
 
 -A::
 --all::
-	Like `-u`, but match <filepattern> against files in the
+	Like `-a`, but match <filepattern> against files in the
 	working tree in addition to the index. That means that it
 	will find new files as well as staging modified content and
 	removing files that are no longer in the working tree.
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 0adbe8b..1bb1b82 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -96,7 +96,7 @@ of tracked files in the working tree and record all removals of
 files that have been removed from the working tree with `rm`
 (as opposed to `git rm`), use `git commit -a`, as it will
 automatically notice and record all removals.  You can also have a
-similar effect without committing by using `git add -u`.
+similar effect without committing by using `git add -a`.
 
 Using ``git add -A''
 ~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 7e7e121..de89763 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -229,13 +229,13 @@ $ echo "* text=auto" >>.gitattributes
 $ rm .git/index     # Remove the index to force git to
 $ git reset         # re-scan the working directory
 $ git status        # Show files that will be normalized
-$ git add -u
+$ git add -a
 $ git add .gitattributes
 $ git commit -m "Introduce end-of-line normalization"
 -------------------------------------------------
 
 If any files that should not be normalized show up in 'git status',
-unset their `text` attribute before running 'git add -u'.
+unset their `text` attribute before running 'git add -a'.
 
 ------------------------
 manual.pdf	-text
diff --git a/builtin/add.c b/builtin/add.c
index f7a17e4..71ee4bb 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -42,7 +42,7 @@ static void update_callback(struct diff_queue_struct *q,
 		case DIFF_STATUS_UNMERGED:
 			/*
 			 * ADD_CACHE_IGNORE_REMOVAL is unset if "git
-			 * add -u" is calling us, In such a case, a
+			 * add -a" is calling us, In such a case, a
 			 * missing work tree file needs to be removed
 			 * if there is an unmerged entry at stage #2,
 			 * but such a diff record is followed by
@@ -320,8 +320,9 @@ static struct option builtin_add_options[] = {
 	OPT_BOOLEAN('p', "patch", &patch_interactive, "select hunks interactively"),
 	OPT_BOOLEAN('e', "edit", &edit_interactive, "edit current diff and apply"),
 	OPT__FORCE(&ignored_too, "allow adding otherwise ignored files"),
-	OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
+	{ OPTION_BOOLEAN, 'u', "update", &take_worktree_changes, NULL, "update tracked files", PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
 	OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
+	OPT_BOOLEAN('a', "tracked", &take_worktree_changes, "add changes from all tracked files"),
 	OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
 	OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
 	OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index e043cb7..414f4f8 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -17,7 +17,7 @@ test_expect_success 'setup' '
 	git branch ref &&
 	git checkout master &&
 	echo modified >>a-blob &&
-	git add -u &&
+	git add -a &&
 	git commit -m Modified
 '
 
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 0692427..aabe8f5 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-test_description='git add -u
+test_description='git add -a
 
 This test creates a working tree state with three files:
 
@@ -8,10 +8,10 @@ This test creates a working tree state with three files:
   dir/sub (previously committed, modified)
   dir/other (untracked)
 
-and issues a git add -u with path limiting on "dir" to add
+and issues a git add -a with path limiting on "dir" to add
 only the updates to dir/sub.
 
-Also tested are "git add -u" without limiting, and "git add -u"
+Also tested are "git add -a" without limiting, and "git add -a"
 without contents changes, and other conditions'
 
 . ./test-lib.sh
@@ -36,7 +36,7 @@ test_expect_success setup '
 '
 
 test_expect_success update '
-	git add -u dir1 dir2
+	git add -a dir1 dir2
 '
 
 test_expect_success 'update noticed a removal' '
@@ -70,7 +70,7 @@ test_expect_success 'update from a subdirectory' '
 	(
 		cd dir1 &&
 		echo more >sub2 &&
-		git add -u sub2
+		git add -a sub2
 	)
 '
 
@@ -84,21 +84,21 @@ test_expect_success SYMLINKS 'replace a file with a symlink' '
 
 	rm foo &&
 	ln -s top foo &&
-	git add -u -- foo
+	git add -a -- foo
 
 '
 
 test_expect_success 'add everything changed' '
 
-	git add -u &&
+	git add -a &&
 	test -z "$(git diff-files)"
 
 '
 
-test_expect_success 'touch and then add -u' '
+test_expect_success 'touch and then add -a' '
 
 	touch check &&
-	git add -u &&
+	git add -a &&
 	test -z "$(git diff-files)"
 
 '
@@ -128,7 +128,7 @@ test_expect_success 'add -n -u should not add but just report' '
 
 '
 
-test_expect_success 'add -u resolves unmerged paths' '
+test_expect_success 'add -a resolves unmerged paths' '
 	git reset --hard &&
 	one=$(echo 1 | git hash-object -w --stdin) &&
 	two=$(echo 2 | git hash-object -w --stdin) &&
@@ -149,7 +149,7 @@ test_expect_success 'add -u resolves unmerged paths' '
 	echo 3 >path1 &&
 	echo 2 >path3 &&
 	echo 2 >path5 &&
-	git add -u &&
+	git add -a &&
 	git ls-files -s path1 path2 path3 path4 path5 path6 >actual &&
 	{
 		echo "100644 $three 0	path1"
@@ -176,8 +176,8 @@ test_expect_success 'add -u resolves unmerged paths' '
 
 '
 
-test_expect_success '"add -u non-existent" should fail' '
-	test_must_fail git add -u non-existent &&
+test_expect_success '"add -a non-existent" should fail' '
+	test_must_fail git add -a non-existent &&
 	! (git ls-files | grep "non-existent")
 '
 
diff --git a/t/t2201-add-update-typechange.sh b/t/t2201-add-update-typechange.sh
index 2e8f702..8981ccb 100755
--- a/t/t2201-add-update-typechange.sh
+++ b/t/t2201-add-update-typechange.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-test_description='more git add -u'
+test_description='more git add -a'
 
 . ./test-lib.sh
 
@@ -124,10 +124,10 @@ test_expect_success diff-index '
 	test_cmp expect-index actual
 '
 
-test_expect_success 'add -u' '
+test_expect_success 'add -a' '
 	rm -f ".git/saved-index" &&
 	cp -p ".git/index" ".git/saved-index" &&
-	git add -u &&
+	git add -a &&
 	git ls-files -s >actual &&
 	test_cmp expect-final actual
 '
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 58a3299..880bcb6 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -19,7 +19,7 @@ test_expect_success 'check result of "add -N"' '
 '
 
 test_expect_success 'intent to add is just an ordinary empty blob' '
-	git add -u &&
+	git add -a &&
 	git ls-files -s file >actual &&
 	git ls-files -s elif | sed -e "s/elif/file/" >expect &&
 	test_cmp expect actual
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 34794f8..9255360 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -320,7 +320,7 @@ test_expect_success 'fail if the index has unresolved entries' '
 	test_must_fail git merge "$c5" &&
 	test_must_fail git merge "$c5" 2> out &&
 	grep "not possible because you have unmerged files" out &&
-	git add -u &&
+	git add -a &&
 	test_must_fail git merge "$c5" 2> out &&
 	grep "You have not concluded your merge" out &&
 	rm -f .git/MERGE_HEAD &&
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index b38be8e..c41c9e3 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-rebase-autosquash.sh
@@ -25,7 +25,7 @@ test_expect_success setup '
 test_auto_fixup () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "fixup! first" &&
 
@@ -54,7 +54,7 @@ test_expect_success 'auto fixup (config)' '
 test_auto_squash () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! first" &&
 
@@ -83,7 +83,7 @@ test_expect_success 'auto squash (config)' '
 test_expect_success 'misspelled auto squash' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! forst" &&
 	git tag final-missquash &&
@@ -102,7 +102,7 @@ test_expect_success 'auto squash that matches 2 commits' '
 	test_tick &&
 	git commit -m "first new commit" &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! first" &&
 	git tag final-multisquash &&
@@ -119,7 +119,7 @@ test_expect_success 'auto squash that matches 2 commits' '
 test_expect_success 'auto squash that matches a commit after the squash' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! third" &&
 	echo 4 >file4 &&
@@ -140,7 +140,7 @@ test_expect_success 'auto squash that matches a commit after the squash' '
 test_expect_success 'auto squash that matches a sha1' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! $(git rev-parse --short HEAD^)" &&
 	git tag final-shasquash &&
@@ -156,7 +156,7 @@ test_expect_success 'auto squash that matches a sha1' '
 test_expect_success 'auto squash that matches longer sha1' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! $(git rev-parse --short=11 HEAD^)" &&
 	git tag final-longshasquash &&
@@ -172,7 +172,7 @@ test_expect_success 'auto squash that matches longer sha1' '
 test_auto_commit_flags () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit --$1 first-commit &&
 	git tag final-commit-$1 &&
diff --git a/t/t4037-diff-r-t-dirs.sh b/t/t4037-diff-r-t-dirs.sh
index f5ce3b2..77534aa 100755
--- a/t/t4037-diff-r-t-dirs.sh
+++ b/t/t4037-diff-r-t-dirs.sh
@@ -22,7 +22,7 @@ test_expect_success setup '
 	do
 		echo hello >$p || exit
 	done &&
-	git add -u &&
+	git add -a &&
 	git add . &&
 	test_tick &&
 	git commit -m second
diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 1ed259d..f021939 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -262,7 +262,7 @@ test_expect_success 'setup for rename + d/f conflicts' '
 
 	echo 11 >>sub/file &&
 	echo more >>dir/file-in-the-way &&
-	git add -u &&
+	git add -a &&
 	git commit -m "Commit to merge, with dir in the way" &&
 
 	git checkout -b dir-not-in-way &&
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 871577d..8359ccc 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -197,7 +197,7 @@ test_expect_success 'setup differently handled merges of rename/add conflict' '
 	test_must_fail git merge B &&
 	rm new_a~HEAD new_a &&
 	printf "Incorrectly merged content" >>new_a &&
-	git add -u &&
+	git add -a &&
 	test_tick && git commit -m E &&
 	git tag E
 '
-- 
1.7.4.1.224.gefc87

Re: [PATCH/RFC 1/3] git-add: make -A description clearer vs. -u

[Junio C Hamano]

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

> Currently, it sounds as if "notice removal of files" distinguishes "-A"
> from "-u", and there is no mention of the worktree.
>
> But both notice the removal, and only "-A" adds changes from untracked
> files. Say so.

I think talking about "add new files" is a good change.

The "noticing of removal" was the reason that "-u" says "update" not
"add".  Your new wording for "-A" does not even hint that removal is
noticed; wouldn't it cause confusion to the end user?

Re: [PATCH/RFC 2/3] git-commit: rename --all to --track

[Junio C Hamano]

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

> Rename the "commit" long option to "--tracked" which conveys the fact
> that it is about all tracked files only.

Please don't.  The fact that "-a" derived from "all" will never change,
and your patch will only confuse future newbies wondering why "tracked"
abbreviates to "a".

Renaming it to "--all-tracked" might be worth considering, but renaming it
to just "--tracked" is not, IMHO.

Re: [PATCH/RFC 3/3] git-add: rename -u to -a

[Junio C Hamano]

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

> since it does what "commit -a" does (minus the committing). The long

I somehow find this quite the other way around.

The original "add -u" makes perfect sense as it is a request to say: "to
the index, add _updated_ contents".  Perhaps "commit -a" is the one that
should gain a synonym "commit -u" to ask "please commit updated contents"
(implying "not new ones").

Re: [PATCH/RFC 0/3] add/commit -u/-a/-A

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 25.02.2011 20:16:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> It comes before Jeff's series from p^3u which refactors add/commit and
>> implements "commit -A".
> 
> What's that topic, and what's p^3u?

p^3u = ppp = proposed potential pu (or something)

Sorry for the TeX notation.

In "Re: Why doesn't git commit -a track new files" (which I failed to
reference from this series), Jeff and I have been discussing how to make
the add-related options of add and commit homogeneous and less
surprising (see the OP). Nobody objected there, so I assumed everyone to
agree... The two problems addressed here are:

- "add -u" and "commit -a" are "the same" (as far as additions go, and
when used without pathspec) but are named differently

- "add --all" and "commit --all" are named the same but do different
things (-A resp. -a).

I care about consistency, not so much about actual names.

I don't think we use upper case long options, or I would have suggested
"--All" as long form of "-A".

You see, "commit --all" seems to promise more than it does - one really
has to know what "all" is qualified by.

And, similarly, "add" always updates the index, it always is about the
updates in the files which are selected, so "-u/--update" doesn't make
much sense to distinguish it from other uses of "add". That's the
reasoning that lead us to having "-a = -u" for add, and that lead me to
renaming "-a = --all" to "-a = --tracked". I wouldn't mind
"--all-tracked" here. and I would have left it and renamed "-A = --all"
to "-A = --foo" if I had had a good "--foo".

Michael

[PATCHv2 0/3] add/commit -u/-a/-A

[Michael J Gruber]

v2 takes "all-tracked" as the long form of "-a" for add and commit.

I would think that "changes from all tracked files" would include the special
change "deletion", but I'm open to making the description more verbous.
But as a general rule, "git cmd -h" output should serve as a reminder,
distinguishing the options from each other, not as complete description.

Michael J Gruber (3):
  git-add: make -A description clearer vs. -u
  git-commit: rename --all to --all-tracked
  git-add: rename -u to -a

 Documentation/git-add.txt         |    8 ++++----
 Documentation/git-commit.txt      |    2 +-
 Documentation/git-rm.txt          |    2 +-
 Documentation/gitattributes.txt   |    4 ++--
 builtin/add.c                     |    7 ++++---
 builtin/commit.c                  |   12 ++++++------
 t/t1511-rev-parse-caret.sh        |    2 +-
 t/t2200-add-update.sh             |   26 +++++++++++++-------------
 t/t2201-add-update-typechange.sh  |    6 +++---
 t/t2203-add-intent.sh             |    2 +-
 t/t3030-merge-recursive.sh        |    2 +-
 t/t3415-rebase-autosquash.sh      |   16 ++++++++--------
 t/t4037-diff-r-t-dirs.sh          |    2 +-
 t/t6022-merge-rename.sh           |    2 +-
 t/t6036-recursive-corner-cases.sh |    2 +-
 15 files changed, 48 insertions(+), 47 deletions(-)

-- 
1.7.4.1.224.gefc87

[PATCHv2 1/3] git-add: make -A description clearer vs. -u

[Michael J Gruber]

Currently, it sounds as if "notice removal of files" distinguishes "-A"
from "-u", and there is no mention of the worktree.

But both notice the removal, and only "-A" adds changes from untracked
files. Say so.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 builtin/add.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index f8e51f9..f7a17e4 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -322,7 +322,7 @@ static struct option builtin_add_options[] = {
 	OPT__FORCE(&ignored_too, "allow adding otherwise ignored files"),
 	OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
 	OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
-	OPT_BOOLEAN('A', "all", &addremove, "add all, noticing removal of tracked files"),
+	OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
 	OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
 	OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
 	OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "check if - even missing - files are ignored in dry run"),
-- 
1.7.4.1.224.gefc87

[PATCHv2 2/3] git-commit: rename --all to --all-tracked

[Michael J Gruber]

Currently, the long option "--all" does different things for "add" (it
is "-A") and "commit" (it is "-a").

Rename the "commit" long option to "--all-tracked" which conveys the fact
that it is about all tracked files only.

Also, rename the corresponding static int in code from "all" to
"alltracked" to help future coders.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-commit.txt |    2 +-
 builtin/commit.c             |   12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 411fa68..70ddb81 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -54,7 +54,7 @@ that, you can recover from it with 'git reset'.
 OPTIONS
 -------
 -a::
---all::
+--all-tracked::
 	Tell the command to automatically stage files that have
 	been modified and deleted, but new files you have not
 	told git about are not affected.
diff --git a/builtin/commit.c b/builtin/commit.c
index d279a84..be0f075 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -83,7 +83,7 @@ static const char *template_file;
 static const char *author_message, *author_message_buffer;
 static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
-static int all, edit_flag, also, interactive, only, amend, signoff;
+static int alltracked, edit_flag, also, interactive, only, amend, signoff;
 static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
@@ -149,7 +149,7 @@ static struct option builtin_commit_options[] = {
 	/* end commit message options */
 
 	OPT_GROUP("Commit contents options"),
-	OPT_BOOLEAN('a', "all", &all, "commit all changed files"),
+	OPT_BOOLEAN('a', "all-tracked", &alltracked, "commit all changed tracked files"),
 	OPT_BOOLEAN('i', "include", &also, "add specified files to index for commit"),
 	OPT_BOOLEAN(0, "interactive", &interactive, "interactively add files"),
 	OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
@@ -367,7 +367,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 	 * (A) if all goes well, commit the real index;
 	 * (B) on failure, rollback the real index.
 	 */
-	if (all || (also && pathspec && *pathspec)) {
+	if (alltracked || (also && pathspec && *pathspec)) {
 		fd = hold_locked_index(&index_lock, 1);
 		add_files_to_cache(also ? prefix : NULL, pathspec, 0);
 		refresh_cache_or_die(refresh_flags);
@@ -1040,8 +1040,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
 		author_message_buffer = read_commit_message(author_message);
 	}
 
-	if (!!also + !!only + !!all + !!interactive > 1)
-		die("Only one of --include/--only/--all/--interactive can be used.");
+	if (!!also + !!only + !!alltracked + !!interactive > 1)
+		die("Only one of --include/--only/--all-tracked/--interactive can be used.");
 	if (argc == 0 && (also || (only && !amend)))
 		die("No paths with --include/--only does not make sense.");
 	if (argc == 0 && only && amend)
@@ -1061,7 +1061,7 @@ static int parse_and_validate_options(int argc, const char *argv[],
 
 	handle_untracked_files_arg(s);
 
-	if (all && argc > 0)
+	if (alltracked && argc > 0)
 		die("Paths with -a does not make sense.");
 	else if (interactive && argc > 0)
 		die("Paths with --interactive does not make sense.");
-- 
1.7.4.1.224.gefc87

[PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

since it does what "commit -a" does (minus the committing). The long
form "--all-tracked" is also more descriptive because "add" always updates the
index (independent of "-u"), but not always for all tracked files.

Keep "-u,--update" as a hidden option because scripts may use it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-add.txt         |    8 ++++----
 Documentation/git-rm.txt          |    2 +-
 Documentation/gitattributes.txt   |    4 ++--
 builtin/add.c                     |    5 +++--
 t/t1511-rev-parse-caret.sh        |    2 +-
 t/t2200-add-update.sh             |   26 +++++++++++++-------------
 t/t2201-add-update-typechange.sh  |    6 +++---
 t/t2203-add-intent.sh             |    2 +-
 t/t3030-merge-recursive.sh        |    2 +-
 t/t3415-rebase-autosquash.sh      |   16 ++++++++--------
 t/t4037-diff-r-t-dirs.sh          |    2 +-
 t/t6022-merge-rename.sh           |    2 +-
 t/t6036-recursive-corner-cases.sh |    2 +-
 13 files changed, 40 insertions(+), 39 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index a03448f..e75ab39 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
-	  [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
+	  [--edit | -e] [[--all | -A ] | [--all-tracked | -a]] [--intent-to-add | -N]
 	  [--refresh] [--ignore-errors] [--ignore-missing] [--]
 	  [<filepattern>...]
 
@@ -98,8 +98,8 @@ quicker and more flexible than using the interactive hunk selector.
 However, it is easy to confuse oneself and create a patch that does not
 apply to the index. See EDITING PATCHES below.
 
--u::
---update::
+-a::
+--all-tracked::
 	Only match <filepattern> against already tracked files in
 	the index rather than the working tree. That means that it
 	will never stage new files, but that it will stage modified
@@ -113,7 +113,7 @@ subdirectories.
 
 -A::
 --all::
-	Like `-u`, but match <filepattern> against files in the
+	Like `-a`, but match <filepattern> against files in the
 	working tree in addition to the index. That means that it
 	will find new files as well as staging modified content and
 	removing files that are no longer in the working tree.
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 0adbe8b..1bb1b82 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -96,7 +96,7 @@ of tracked files in the working tree and record all removals of
 files that have been removed from the working tree with `rm`
 (as opposed to `git rm`), use `git commit -a`, as it will
 automatically notice and record all removals.  You can also have a
-similar effect without committing by using `git add -u`.
+similar effect without committing by using `git add -a`.
 
 Using ``git add -A''
 ~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 7e7e121..de89763 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -229,13 +229,13 @@ $ echo "* text=auto" >>.gitattributes
 $ rm .git/index     # Remove the index to force git to
 $ git reset         # re-scan the working directory
 $ git status        # Show files that will be normalized
-$ git add -u
+$ git add -a
 $ git add .gitattributes
 $ git commit -m "Introduce end-of-line normalization"
 -------------------------------------------------
 
 If any files that should not be normalized show up in 'git status',
-unset their `text` attribute before running 'git add -u'.
+unset their `text` attribute before running 'git add -a'.
 
 ------------------------
 manual.pdf	-text
diff --git a/builtin/add.c b/builtin/add.c
index f7a17e4..504061d 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -42,7 +42,7 @@ static void update_callback(struct diff_queue_struct *q,
 		case DIFF_STATUS_UNMERGED:
 			/*
 			 * ADD_CACHE_IGNORE_REMOVAL is unset if "git
-			 * add -u" is calling us, In such a case, a
+			 * add -a" is calling us, In such a case, a
 			 * missing work tree file needs to be removed
 			 * if there is an unmerged entry at stage #2,
 			 * but such a diff record is followed by
@@ -320,8 +320,9 @@ static struct option builtin_add_options[] = {
 	OPT_BOOLEAN('p', "patch", &patch_interactive, "select hunks interactively"),
 	OPT_BOOLEAN('e', "edit", &edit_interactive, "edit current diff and apply"),
 	OPT__FORCE(&ignored_too, "allow adding otherwise ignored files"),
-	OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
+	{ OPTION_BOOLEAN, 'u', "update", &take_worktree_changes, NULL, "update tracked files", PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
 	OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
+	OPT_BOOLEAN('a', "all-tracked", &take_worktree_changes, "add changes from all tracked files"),
 	OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
 	OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
 	OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index e043cb7..414f4f8 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -17,7 +17,7 @@ test_expect_success 'setup' '
 	git branch ref &&
 	git checkout master &&
 	echo modified >>a-blob &&
-	git add -u &&
+	git add -a &&
 	git commit -m Modified
 '
 
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 0692427..aabe8f5 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-test_description='git add -u
+test_description='git add -a
 
 This test creates a working tree state with three files:
 
@@ -8,10 +8,10 @@ This test creates a working tree state with three files:
   dir/sub (previously committed, modified)
   dir/other (untracked)
 
-and issues a git add -u with path limiting on "dir" to add
+and issues a git add -a with path limiting on "dir" to add
 only the updates to dir/sub.
 
-Also tested are "git add -u" without limiting, and "git add -u"
+Also tested are "git add -a" without limiting, and "git add -a"
 without contents changes, and other conditions'
 
 . ./test-lib.sh
@@ -36,7 +36,7 @@ test_expect_success setup '
 '
 
 test_expect_success update '
-	git add -u dir1 dir2
+	git add -a dir1 dir2
 '
 
 test_expect_success 'update noticed a removal' '
@@ -70,7 +70,7 @@ test_expect_success 'update from a subdirectory' '
 	(
 		cd dir1 &&
 		echo more >sub2 &&
-		git add -u sub2
+		git add -a sub2
 	)
 '
 
@@ -84,21 +84,21 @@ test_expect_success SYMLINKS 'replace a file with a symlink' '
 
 	rm foo &&
 	ln -s top foo &&
-	git add -u -- foo
+	git add -a -- foo
 
 '
 
 test_expect_success 'add everything changed' '
 
-	git add -u &&
+	git add -a &&
 	test -z "$(git diff-files)"
 
 '
 
-test_expect_success 'touch and then add -u' '
+test_expect_success 'touch and then add -a' '
 
 	touch check &&
-	git add -u &&
+	git add -a &&
 	test -z "$(git diff-files)"
 
 '
@@ -128,7 +128,7 @@ test_expect_success 'add -n -u should not add but just report' '
 
 '
 
-test_expect_success 'add -u resolves unmerged paths' '
+test_expect_success 'add -a resolves unmerged paths' '
 	git reset --hard &&
 	one=$(echo 1 | git hash-object -w --stdin) &&
 	two=$(echo 2 | git hash-object -w --stdin) &&
@@ -149,7 +149,7 @@ test_expect_success 'add -u resolves unmerged paths' '
 	echo 3 >path1 &&
 	echo 2 >path3 &&
 	echo 2 >path5 &&
-	git add -u &&
+	git add -a &&
 	git ls-files -s path1 path2 path3 path4 path5 path6 >actual &&
 	{
 		echo "100644 $three 0	path1"
@@ -176,8 +176,8 @@ test_expect_success 'add -u resolves unmerged paths' '
 
 '
 
-test_expect_success '"add -u non-existent" should fail' '
-	test_must_fail git add -u non-existent &&
+test_expect_success '"add -a non-existent" should fail' '
+	test_must_fail git add -a non-existent &&
 	! (git ls-files | grep "non-existent")
 '
 
diff --git a/t/t2201-add-update-typechange.sh b/t/t2201-add-update-typechange.sh
index 2e8f702..8981ccb 100755
--- a/t/t2201-add-update-typechange.sh
+++ b/t/t2201-add-update-typechange.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-test_description='more git add -u'
+test_description='more git add -a'
 
 . ./test-lib.sh
 
@@ -124,10 +124,10 @@ test_expect_success diff-index '
 	test_cmp expect-index actual
 '
 
-test_expect_success 'add -u' '
+test_expect_success 'add -a' '
 	rm -f ".git/saved-index" &&
 	cp -p ".git/index" ".git/saved-index" &&
-	git add -u &&
+	git add -a &&
 	git ls-files -s >actual &&
 	test_cmp expect-final actual
 '
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 58a3299..880bcb6 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -19,7 +19,7 @@ test_expect_success 'check result of "add -N"' '
 '
 
 test_expect_success 'intent to add is just an ordinary empty blob' '
-	git add -u &&
+	git add -a &&
 	git ls-files -s file >actual &&
 	git ls-files -s elif | sed -e "s/elif/file/" >expect &&
 	test_cmp expect actual
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 34794f8..9255360 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -320,7 +320,7 @@ test_expect_success 'fail if the index has unresolved entries' '
 	test_must_fail git merge "$c5" &&
 	test_must_fail git merge "$c5" 2> out &&
 	grep "not possible because you have unmerged files" out &&
-	git add -u &&
+	git add -a &&
 	test_must_fail git merge "$c5" 2> out &&
 	grep "You have not concluded your merge" out &&
 	rm -f .git/MERGE_HEAD &&
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index b38be8e..c41c9e3 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-rebase-autosquash.sh
@@ -25,7 +25,7 @@ test_expect_success setup '
 test_auto_fixup () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "fixup! first" &&
 
@@ -54,7 +54,7 @@ test_expect_success 'auto fixup (config)' '
 test_auto_squash () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! first" &&
 
@@ -83,7 +83,7 @@ test_expect_success 'auto squash (config)' '
 test_expect_success 'misspelled auto squash' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! forst" &&
 	git tag final-missquash &&
@@ -102,7 +102,7 @@ test_expect_success 'auto squash that matches 2 commits' '
 	test_tick &&
 	git commit -m "first new commit" &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! first" &&
 	git tag final-multisquash &&
@@ -119,7 +119,7 @@ test_expect_success 'auto squash that matches 2 commits' '
 test_expect_success 'auto squash that matches a commit after the squash' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! third" &&
 	echo 4 >file4 &&
@@ -140,7 +140,7 @@ test_expect_success 'auto squash that matches a commit after the squash' '
 test_expect_success 'auto squash that matches a sha1' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! $(git rev-parse --short HEAD^)" &&
 	git tag final-shasquash &&
@@ -156,7 +156,7 @@ test_expect_success 'auto squash that matches a sha1' '
 test_expect_success 'auto squash that matches longer sha1' '
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit -m "squash! $(git rev-parse --short=11 HEAD^)" &&
 	git tag final-longshasquash &&
@@ -172,7 +172,7 @@ test_expect_success 'auto squash that matches longer sha1' '
 test_auto_commit_flags () {
 	git reset --hard base &&
 	echo 1 >file1 &&
-	git add -u &&
+	git add -a &&
 	test_tick &&
 	git commit --$1 first-commit &&
 	git tag final-commit-$1 &&
diff --git a/t/t4037-diff-r-t-dirs.sh b/t/t4037-diff-r-t-dirs.sh
index f5ce3b2..77534aa 100755
--- a/t/t4037-diff-r-t-dirs.sh
+++ b/t/t4037-diff-r-t-dirs.sh
@@ -22,7 +22,7 @@ test_expect_success setup '
 	do
 		echo hello >$p || exit
 	done &&
-	git add -u &&
+	git add -a &&
 	git add . &&
 	test_tick &&
 	git commit -m second
diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 1ed259d..f021939 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -262,7 +262,7 @@ test_expect_success 'setup for rename + d/f conflicts' '
 
 	echo 11 >>sub/file &&
 	echo more >>dir/file-in-the-way &&
-	git add -u &&
+	git add -a &&
 	git commit -m "Commit to merge, with dir in the way" &&
 
 	git checkout -b dir-not-in-way &&
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 871577d..8359ccc 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -197,7 +197,7 @@ test_expect_success 'setup differently handled merges of rename/add conflict' '
 	test_must_fail git merge B &&
 	rm new_a~HEAD new_a &&
 	printf "Incorrectly merged content" >>new_a &&
-	git add -u &&
+	git add -a &&
 	test_tick && git commit -m E &&
 	git tag E
 '
-- 
1.7.4.1.224.gefc87

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Nguyen Thai Ngoc Duy]

On Sun, Feb 27, 2011 at 10:50 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> @@ -320,8 +320,9 @@ static struct option builtin_add_options[] = {
>        OPT_BOOLEAN('p', "patch", &patch_interactive, "select hunks interactively"),
>        OPT_BOOLEAN('e', "edit", &edit_interactive, "edit current diff and apply"),
>        OPT__FORCE(&ignored_too, "allow adding otherwise ignored files"),
> -       OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
> +       { OPTION_BOOLEAN, 'u', "update", &take_worktree_changes, NULL, "update tracked files", PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
>        OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
> +       OPT_BOOLEAN('a', "all-tracked", &take_worktree_changes, "add changes from all tracked files"),

Should -u now print warnings to help script writers migrate to -a? Or
do we plan to keep hidden -u forever?
-- 
Duy

Re: [PATCHv2 1/3] git-add: make -A description clearer vs. -u

[Junio C Hamano]

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

> Currently, it sounds as if "notice removal of files" distinguishes "-A"
> from "-u", and there is no mention of the worktree.
>
> But both notice the removal, and only "-A" adds changes from untracked
> files. Say so.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>

Thanks; I think the new wording is an improvement over the existing
message.  Applied.

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> Should -u now print warnings to help script writers migrate to -a? Or
> do we plan to keep hidden -u forever?

I'd rather not to apply 2 and 3 from this series for now, until we have a
more reasonable solution.  Yes, I said "add --add-tracked" _might_ be
worth considering, but that is in contrast to "add --tracked" which was
out of the question.

Like it or not, "add -u" has already been quite established, and the 'u'
stands for "update(d)" (i.e. "run update-index to the files updated in the
work tree"), which I think makes perfect sense.

I would suggest just keeping "add -u" as is.  As I said in the review in
the previous round, if Michael really wants to, it probably is Ok to give
"commit -a" a synonym "commit --update".

I further find that the verb form "--update" doesn't rhyme well as the
option name to select what classes of paths are operated on; it might make
sense to change the fully spelled version of the option for both commands
from "--update" to "--updated" while we are at it.  This would not bother
end users at all, as parse-options will complete "--update" typed by the
user or in scripts uniquely to "--updated" just fine.

Michael seems to be resisting against introducing "commit --update", and I
understand one reason is because "status -u" means something totally
different from "updated paths"; I am somewhat sympathetic to that fear.

But we started making "status" independent from being "commit --dry-run"
in 1.7.0 for a reason---it would be Ok if "status -u" means something
completely different from "commit -u", _as long as_ existing "commit -u"
does not make much sense.  I think that is the case here.

I don't think the distinction between "commit -a" vs "commit -A" is all
that bad.  When people talk about "all" files in the context of SCM, we
almost always think about already tracked paths, and other files do not
get into the picture unless you first "add" them (this is not limited to
git; even "svn commit" or "cvs commit" wouldn't touch untracked paths).
For this reason, it is not unexpected that the normal version of "all"
excludes untracked files, and you would need to ask for the unusual
version of "all" to include them (i.e. "commit -A" or "add -A") when
dealing with usual SCM commands.

The same argument however does _NOT_ hold for "add", as "add" (especially
in other SCM's context) is about making paths that haven't been tracked so
far into tracked ones; iow, it is natural to expect that "all" would mean
more than normal "all" (i.e. "all what are tracked") in the context of the
"add" command (and "add" command only).

IOW, renaming "add -u" to "add -a" and having "add -a" vs "add -A" is more
confusing than necessary, because of the nature of the word "add" that has
a connotation of affecting paths that have been untracked so far, and
keeping "add -u" and "add -A" distinct to avoid confusion is probably a
reasonable solution to avoid "which variant of 'all' are we talking about"
confusion.  This compromise unfortunately does not give us the uniformity
between '-a' vs '-A' applied to 'add' vs 'commit'.  That is why I would
suggest '-u' vs '-A' if we _really_ want to have such a uniformity between
two commands, i.e. not adding "add -a" but adding "commit -u".

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 28.02.2011 07:40:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 
>> Should -u now print warnings to help script writers migrate to -a? Or
>> do we plan to keep hidden -u forever?
> 
> I'd rather not to apply 2 and 3 from this series for now, until we have a
> more reasonable solution.  Yes, I said "add --add-tracked" _might_ be

"add --all-tracked", I think.

> worth considering, but that is in contrast to "add --tracked" which was
> out of the question.

Come to think of it: How about "-A,--everything" and "-a,--all" if
"-A,--All" is a no-no?

> Like it or not, "add -u" has already been quite established, and the 'u'
> stands for "update(d)" (i.e. "run update-index to the files updated in the
> work tree"), which I think makes perfect sense.

I think here and below you are reasoning from the perspective of a
well-trained user - which already must be quite an effort (trying to
think way below your level of experience), of course ;)

We know that add runs update-index, but we are irrelevant, so to say. If
"update" or "updated content" describes the option (!, not the command)
well for an ordinary user, differentiating it from other add options,
I'm all for it. My problem is that in

git add pathspec
git add -u pathspec

both commands update the index with the updated contents of pathspec if
pathspec is tracked already. They are only different when pathspec (or
some of the files under pathspec) is not tracked yet. So, really:

-u == --tracked-files-only

That is, without "-u" we add (potentially) more than we would with "-u".

It's just that the defaults without pathspec are very different: ""
resp. "."

But that default makes "-u" appear very all-ish.

> I would suggest just keeping "add -u" as is.  As I said in the review in
> the previous round, if Michael really wants to, it probably is Ok to give
> "commit -a" a synonym "commit --update".
> 
> I further find that the verb form "--update" doesn't rhyme well as the
> option name to select what classes of paths are operated on; it might make
> sense to change the fully spelled version of the option for both commands
> from "--update" to "--updated" while we are at it.  This would not bother
> end users at all, as parse-options will complete "--update" typed by the
> user or in scripts uniquely to "--updated" just fine.

In fact, I'd be much happier with "--updated" than with "--update" -
"updated" makes sense for tracked files only, so "updated" is really
another way of saying "tracked" in the context of the add option in
question!

> Michael seems to be resisting against introducing "commit --update", and I
> understand one reason is because "status -u" means something totally
> different from "updated paths"; I am somewhat sympathetic to that fear.
> 
> But we started making "status" independent from being "commit --dry-run"
> in 1.7.0 for a reason---it would be Ok if "status -u" means something
> completely different from "commit -u", _as long as_ existing "commit -u"
> does not make much sense.  I think that is the case here.

While technically possible, as you explained, having "-u" inconsistent
between "commit" and "status" is a bitter pill to swallow while I'm
driving for consistency between "add" and "commit". I could try to
convince me that "add -u" is quite a bit like "status -uno", though...

> I don't think the distinction between "commit -a" vs "commit -A" is all
> that bad.  When people talk about "all" files in the context of SCM, we
> almost always think about already tracked paths, and other files do not
> get into the picture unless you first "add" them (this is not limited to
> git; even "svn commit" or "cvs commit" wouldn't touch untracked paths).

That's exactly how I was reasoning that "commit -a" does The Right Thing :)

> For this reason, it is not unexpected that the normal version of "all"
> excludes untracked files, and you would need to ask for the unusual
> version of "all" to include them (i.e. "commit -A" or "add -A") when
> dealing with usual SCM commands.

Yes, I'd much rather have a better long name for "commit -A", such as
"commit --everything", even though there's no "A" in "everything". It is
"more than all", "all-and-more", and maybe that's good enough.

> The same argument however does _NOT_ hold for "add", as "add" (especially
> in other SCM's context) is about making paths that haven't been tracked so
> far into tracked ones; iow, it is natural to expect that "all" would mean
> more than normal "all" (i.e. "all what are tracked") in the context of the
> "add" command (and "add" command only).

Well, I thought we're trying to teach users that our "add" is primarily
about adding changes from updated files, and *also* about adding files
to the "list of tracked stuff".

Also, "all tracked" is not normal for "add", otherwise plain

git add

would have to default to "git add -u", wouldn't it?

> IOW, renaming "add -u" to "add -a" and having "add -a" vs "add -A" is more
> confusing than necessary, because of the nature of the word "add" that has
> a connotation of affecting paths that have been untracked so far, and
> keeping "add -u" and "add -A" distinct to avoid confusion is probably a
> reasonable solution to avoid "which variant of 'all' are we talking about"
> confusion.  This compromise unfortunately does not give us the uniformity
> between '-a' vs '-A' applied to 'add' vs 'commit'.  That is why I would
> suggest '-u' vs '-A' if we _really_ want to have such a uniformity between
> two commands, i.e. not adding "add -a" but adding "commit -u".

I think it all boils down to the fact that because "add" and "commit"
have different defaults (because we want useful defaults), the meaning
of the same long option "--all" could be different. I mean, "commit
--all[-tracked]" is pointless.

But just how useful is our default that "git add" is a no-op? I know I'm
getting a bit radical here, but the more I think about it, I feel that

- "add" should be about tracked paths by default (default pathspec "."),

- "commit -a,--add <addopts>" be "add <addopts> && commit", and

- "-A,--all pathspec" (default pathspec ".") be about tracked and
untracked paths (whether add or commit).

Yes, that makes our "add" even more different from "svn add", but our
"commit" is very different already. That would need a proper migration
plan etc., and some thinking about -i/-o. Just brain-storming.

Cheers,
Michael

P.S.: Maybe we could even use "git stage" as the construction site for
the "new git add", but that would loose the "-a,--add" niceness.

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
> - "commit -a,--add <addopts>" be "add <addopts> && commit", and

Can you give an example?  It look like you're proposing that the user
would have to type "commit -a -u", which is pretty gross for a fairly
common operation that already has a good shorthand...

-Miles

-- 
Omochiroi!

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Miles Bader venit, vidit, dixit 28.02.2011 09:42:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
> 
> Can you give an example?  It look like you're proposing that the user
> would have to type "commit -a -u", which is pretty gross for a fairly
> common operation that already has a good shorthand...

Not again, please. I don't even know what to give an example for, given
how much you cut down my post. In the last part of my post (the
"radical" part), I explained why we don't need "-u" any more, because
it's the new default. So, obviously (obvious from the parts you cut),
"commit -a" would do what it always did.

And would you please try and follow our netiquete here? I had promised
myself not to respond any more, but see how I'm still forgiving. Try and
deserve it :)

Michael

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
> And would you please try and follow our netiquete here? I had promised
> myself not to respond any more, but see how I'm still forgiving. Try and
> deserve it :)

I'm confused; how am I "not following netiquete"?  It was an honest
question...

-miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
> Miles Bader venit, vidit, dixit 28.02.2011 09:42:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
>> 
>> Can you give an example?  It look like you're proposing that the user
>> would have to type "commit -a -u", which is pretty gross for a fairly
>> common operation that already has a good shorthand...
>
> we don't need "-u" any more, because it's the new default. So,
> obviously, "commit -a" would do what it always did.

Ok, so for "-u" that works out.

But for -A, the user would have to type "commit -a -A".

That sort of indirection is clever, but it seems confusing and
inconvenient for the user, and I think a very common question would be
"why do I need to use -a when it's obvious that -A should imply that?"

-miles

-- 
Vote, v. The instrument and symbol of a freeman's power to make a fool of
himself and a wreck of his country.

Snipping on this list (Was: Re: [PATCHv2 3/3] git-add: rename -u to -a)

[Michael J Gruber]

Miles Bader venit, vidit, dixit 28.02.2011 09:53:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> And would you please try and follow our netiquete here? I had promised
>> myself not to respond any more, but see how I'm still forgiving. Try and
>> deserve it :)
> 
> I'm confused; how am I "not following netiquete"?  It was an honest
> question...

Well, we're trying to cut as little as possible here. In particular,
don't just include one single line, taking it completely out of context.
Even more particularly, don't cut away the paragraph leading to a
conclusion when you're responding that conclusion - in this case that
paragraph would have ansered your question already. (And I don't think
I'm saying this the first time, but I'm used to it - I have little kids...).

We do cut patches when we respond to a commit message only (and the
response is not about the implementation), or hunks of a patch when
they're not related to the response.

As a general guideline, a reader should be able to understand the
response without looking up the post you are responding to (but may have
to read up on a longer thread). When in doubt, err on the lenient side
(less cutting), and make your MUA display quotes nicely (conversation
view, quotecollapse, ...).

And don't cull cc, don't break the thread. (You haven don't that here, I
do appreciate that, thanks!).

Cheers,
Michael

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Miles Bader venit, vidit, dixit 28.02.2011 10:03:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> Miles Bader venit, vidit, dixit 28.02.2011 09:42:
>>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>>> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
>>>
>>> Can you give an example?  It look like you're proposing that the user
>>> would have to type "commit -a -u", which is pretty gross for a fairly
>>> common operation that already has a good shorthand...
>>
>> we don't need "-u" any more, because it's the new default. So,
>> obviously, "commit -a" would do what it always did.
> 
> Ok, so for "-u" that works out.
> 
> But for -A, the user would have to type "commit -a -A".
> 
> That sort of indirection is clever, but it seems confusing and
> inconvenient for the user, and I think a very common question would be
> "why do I need to use -a when it's obvious that -A should imply that?"

If it's obviously an add option, then it will imply add, of course. I'm
trying to make things better ;)

That whole last paragraph was labelled "radical brain-storming", not
incorporating other add-related commit options like -i and -o, not
completely thought through.

Michael

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Matthieu Moy]

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

> But just how useful is our default that "git add" is a no-op?

I dont care very much myself, but if you consider "git add ." as a
potentially destructive operation (discards changes that may be precious
in the index), then it's good that "git add" is a no-op.

Many beginners will try commands expecting to get a help message or a
hint on how to use it when ran without argument (principle of least
surprise)

Like:

$ ls
file1 file2
=> oh, so "ls" lists files.
$ rm
rm: missing operand
Try `rm --help' for more information.
=> ok, so rm needs more operands

A user typing "git add" just "to see what happens" may be disapointed to
have all its files added. In particular since "git add" is silent by
default, hence

# let's see what happens ...
$ git add
$ 
# ok, nothing happened ...
# continue hacking without noticing that a bunch of files have been added.

Mercurial has taken the other way, making "hg add" add everything by
default, and some users do complain:

http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html

If you change this for Git, you'll have people complaining about
backward compatibility plus people complaining about least surprise :-(

> - "add" should be about tracked paths by default (default pathspec "."),
>
> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
>
> - "-A,--all pathspec" (default pathspec ".") be about tracked and
> untracked paths (whether add or commit).

Today, "git add ." adds new content in tracked files, and new files, but
doesn't notice files deletions. Did I miss something, or is there no way
to do that with your proposal?

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

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> But just how useful is our default that "git add" is a no-op?
> 
> I dont care very much myself, but if you consider "git add ." as a
> potentially destructive operation (discards changes that may be precious
> in the index), then it's good that "git add" is a no-op.
> 
> Many beginners will try commands expecting to get a help message or a
> hint on how to use it when ran without argument (principle of least
> surprise)
> 
> Like:
> 
> $ ls
> file1 file2
> => oh, so "ls" lists files.
> $ rm
> rm: missing operand
> Try `rm --help' for more information.
> => ok, so rm needs more operands
> 
> A user typing "git add" just "to see what happens" may be disapointed to
> have all its files added. In particular since "git add" is silent by
> default, hence
> 
> # let's see what happens ...
> $ git add
> $ 
> # ok, nothing happened ...
> # continue hacking without noticing that a bunch of files have been added.

No no, I said "add" would default to what "-u" does now (see below).

A user "starting to experiment with add" while have nothing in the index.

> Mercurial has taken the other way, making "hg add" add everything by
> default, and some users do complain:
> 
> http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html

Since when do we care about them (as in "hg", not in "users", mind you...).

> If you change this for Git, you'll have people complaining about
> backward compatibility plus people complaining about least surprise :-(
> 
>> - "add" should be about tracked paths by default (default pathspec "."),

See, here!

>>
>> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
>>
>> - "-A,--all pathspec" (default pathspec ".") be about tracked and
>> untracked paths (whether add or commit).
> 
> Today, "git add ." adds new content in tracked files, and new files, but
> doesn't notice files deletions. Did I miss something, or is there no way
> to do that with your proposal?

What in

> That would need a proper migration
> plan etc., and some thinking about -i/-o. Just brain-storming.

reads "proposal" to you?

Besides, current "git add ." is a really strange thing, doing more and
less than "git add -u", mixing "update" with "track", but not
completely. What is it even good for? ;)

(We could have an option for that, of course. Have I mentioned "radical"?)

Michael

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Tor Arntsen]

On Mon, Feb 28, 2011 at 10:49, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> No no, I said "add" would default to what "-u" does now (see below).

add -u adds untracked files. An explicit operation by the user. I hope
you really don't mean that just 'git add' would add all untracked
files? That would cause a terrible mess if someone just enters 'git
add' (which they could very well do in other situations than just
after 'git init', there are many casual git users out there.)

-Tor

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Tor Arntsen venit, vidit, dixit 28.02.2011 11:01:
> On Mon, Feb 28, 2011 at 10:49, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> 
>> No no, I said "add" would default to what "-u" does now (see below).
> 
> add -u adds untracked files. An explicit operation by the user. I hope
> you really don't mean that just 'git add' would add all untracked
> files? That would cause a terrible mess if someone just enters 'git
> add' (which they could very well do in other situations than just
> after 'git init', there are many casual git users out there.)

Please, go read what (thread) you're replying to, then reply. I'm not
responsible for other people cutting my posts and turning around the
rest. (Also, you are wrong about "add -u".)

Michael

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Matthieu Moy]

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

> Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
>
>> # let's see what happens ...
>> $ git add
>> $ 
>> # ok, nothing happened ...
>> # continue hacking without noticing that a bunch of files have been added.
>
> No no, I said "add" would default to what "-u" does now (see below).

Right, that less disturbing than I wrote (but still potentially
disturbing)

>> Mercurial has taken the other way, making "hg add" add everything by
>> default, and some users do complain:
>> 
>> http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html
>
> Since when do we care about them (as in "hg", not in "users", mind
> you...).

If you don't care about experiences of others, I can do nothing for you.
I don't have a crystal ball, so I can't say what Git users will say
about a given feature, but I can look around me (I'm sure you can too)
and see how it went for other people.

>> If you change this for Git, you'll have people complaining about
>> backward compatibility plus people complaining about least surprise :-(
>> 
>>> - "add" should be about tracked paths by default (default pathspec "."),
>
> See, here!
>
>>>
>>> - "commit -a,--add <addopts>" be "add <addopts> && commit", and
>>>
>>> - "-A,--all pathspec" (default pathspec ".") be about tracked and
>>> untracked paths (whether add or commit).
>> 
>> Today, "git add ." adds new content in tracked files, and new files, but
>> doesn't notice files deletions. Did I miss something, or is there no way
>> to do that with your proposal?
>
> What in
>
>> That would need a proper migration
>> plan etc., and some thinking about -i/-o. Just brain-storming.
>
> reads "proposal" to you?

What's wrong with you today? Miles asks a honnest question and gets a
dissertation about the netiquette, I ask another question, mention the
experience of other people and get this.

I did read "brainstorming" in your email, tried to brainstorm with you,
but you're not making it easy to us. I'm stopping here, sorry for
disturbing.

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

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 28.02.2011 11:05:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
>> 
>>> # let's see what happens ... $ git add $ # ok, nothing happened
>>> ... # continue hacking without noticing that a bunch of files
>>> have been added.
>> 
>> No no, I said "add" would default to what "-u" does now (see
>> below).
> 
> Right, that less disturbing than I wrote (but still potentially 
> disturbing)
> 
>>> Mercurial has taken the other way, making "hg add" add everything
>>> by default, and some users do complain:
>>> 
>>> http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html
>>
>>
>>> Since when do we care about them (as in "hg", not in "users", mind
>> you...).
> 
> If you don't care about experiences of others, I can do nothing for
> you. I don't have a crystal ball, so I can't say what Git users will
> say about a given feature, but I can look around me (I'm sure you can
> too) and see how it went for other people.
> 

Between hg and git, add and commit are very different. Haven't we all
seen these super smart comparisons saying

hg add is much faster than git add, but git commit is much faster than
hg commit?

They do completely different things. When used after each other, they do
"A+B+C", but "hg add" does "A", "hg commit" "B+C", whereas "git add"
does "A+B", "git commit" does "C" (with pathspecs for add, no options).

Because of that, and also because I haven't thought
about/suggested/proposed what "hg add" seems to do by default now, I
dismiss that experience as unrelated. "hg add" is partially related to
"git add" only, and their default is completely different from what I've
mentioned.

(I think you know hg and git well enough to know this difference, and
also know from the list that I do care [even in your quote], or I would
have explained that in the first place).

>>> If you change this for Git, you'll have people complaining about 
>>> backward compatibility plus people complaining about least
>>> surprise :-(
>>> 
>>>> - "add" should be about tracked paths by default (default
>>>> pathspec "."),
>> 
>> See, here!
>> 
>>>> 
>>>> - "commit -a,--add <addopts>" be "add <addopts> && commit",
>>>> and
>>>> 
>>>> - "-A,--all pathspec" (default pathspec ".") be about tracked
>>>> and untracked paths (whether add or commit).
>>> 
>>> Today, "git add ." adds new content in tracked files, and new
>>> files, but doesn't notice files deletions. Did I miss something,
>>> or is there no way to do that with your proposal?
>> 
>> What in
>> 
>>> That would need a proper migration plan etc., and some thinking
>>> about -i/-o. Just brain-storming.
>> 
>> reads "proposal" to you?
> 
> What's wrong with you today? Miles asks a honnest question and gets
> a dissertation about the netiquette,

A question answered in the post he replied to (but failed to quote).
Given my previous encounters the other day, an explanation of our
netiquette seemed in order (other lists trim much more then we do), and
non the less I did so politely, and I even appreciated his leaving cc in
place (which other lists do differently, and proves his openness to adapt).

> I ask another question, mention
> the experience of other people and get this.

Jeff, then Junio and I have been discussing ways forward to improve the
user experience with respect to related options of "add" and "commit"
(which are similar and named differently, or dissimilar and named the
same), and everyone is welcome to join (of course; just to be clear),
there is no consensus yet. Every voice counts.

> I did read "brainstorming" in your email, tried to brainstorm with
> you, but you're not making it easy to us. I'm stopping here, sorry
> for disturbing.

What is not OK is trimming down my posts to the amount that they make no
sense any more, or a completely different sense, and then commenting on
that skewed quote, forcing me to reexplain what I had explained already.
This makes us go in circles, rather than forward. It's a waste of resources.

You may have been unlucky in being number "n+1" to do so to me on-list
today, and maybe in "proposal" being more formal in English than in
French, alleviated by the fact that you cut out my sentence

"I know I'm getting a bit radical here, but the more I think about it, I
feel that"

introducing the list of items which you did quote (no to mention the
whole reasoning building up to that). So, not just poor luck, you see;)

Writing that long post (with a large unradical part, and a short radical
brain-storming) I was afraid already it would make people read partially
only. I hope we'll turn that into a more constructive direction again.

Michael

Re: Snipping on this list

[Junio C Hamano]

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

> As a general guideline, a reader should be able to understand the
> response without looking up the post you are responding to (but may have

A reader should be able to remember which original the response is about,
so that s/he can look it up if s/he doesn't.  If in doubt, I'd rather see
people discard irrelevent bits more not less.

> And don't cull cc, don't break the thread. (You haven don't that here, I
> do appreciate that, thanks!).

That is true.

Re: [PATCHv2 3/3] git-add: rename -u to -a

[Junio C Hamano]

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

> Today, "git add ." adds new content in tracked files, and new files, but
> doesn't notice files deletions. Did I miss something, or is there no way
> to do that with your proposal?

That _may_ be something we would want to discuss, even to introduce a
backward incompatible change, aimed at 1.10.0 or 2.0 timeframe (if we are
starting to discuss something new today, it is too late for 1.8.0).