{"thread":{"id":"31244","subject":"Git add on deleted file","startedAt":"2012-08-13T17:34:46Z","lastAt":"2012-08-13T18:18:13Z","messageCount":3,"participants":["Angus Hammond","Junio C Hamano","Ralf Thielow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196921","messageId":"CAOBOgRZRSk7+jxMg+v=GWcn3F9ZfDTGC89YhJ1s7o9=HaOx4Bg@mail.gmail.com","threadId":"31244","inReplyTo":null,"subject":"Git add on deleted file","fromName":"Angus Hammond","fromEmail":"angusgh@gmail.com","sentAt":"2012-08-13T17:34:46Z","receivedAt":"2012-08-13T17:34:46Z","isPatch":false,"sender":{"key":"angusgh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1839397?v=4"},"body":"I was messing around with git add and how it interacts with deleted\nfiles earlier today and came across this odd behavior.\n\n$git init\nInitialized empty Git repository in /tmp/test/.git/\n$touch foo\n$git add foo\n$git commit -m\"initial commit\"\n[master (root-commit) 0b5a193] initial commit\n 0 files changed\n create mode 100644 foo\n$rm foo\n$git status\n# On branch master\n# Changes not staged for commit:\n#   (use \"git add/rm <file>...\" to update what will be committed)\n#   (use \"git checkout -- <file>...\" to discard changes in working directory)\n#\n#       deleted:    foo\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$git add foo\n$git status\n# On branch master\n# Changes not staged for commit:\n#   (use \"git add/rm <file>...\" to update what will be committed)\n#   (use \"git checkout -- <file>...\" to discard changes in working directory)\n#\n#       deleted:    foo\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nNotice that the two outputs from git status are identical, so git add\ndoesn't appear to have changed anything. Personally I'd like to see\n\"git add foo\" here be equivalent \"git rm --cached foo\", but I can\nunderstand how others might prefer git add not to be destructive like\nthat. Either way, I don't think it's right that the command exits\nwithout any output (which would normally indicate success) yet has\nfailed to do anything. Perhaps it should act more like git add does\nwhen the file doesn't exist in the working directory or the index:\n\n$git add bar\nfatal: pathspec 'bar' did not match any files\n\nThanks\nAngus\n"},{"id":"196923","messageId":"7vipcmekzh.fsf@alter.siamese.dyndns.org","threadId":"31244","inReplyTo":"CAOBOgRZRSk7+jxMg+v=GWcn3F9ZfDTGC89YhJ1s7o9=HaOx4Bg@mail.gmail.com","subject":"Re: Git add on deleted file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-13T17:54:10Z","receivedAt":"2012-08-13T17:54:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angus Hammond <angusgh@gmail.com> writes:\n\n> ... Personally I'd like to see\n> \"git add foo\" here be equivalent \"git rm --cached foo\", but I can\n> understand how others might prefer git add not to be destructive like\n> that.\n\nFunny that you bring it up this week.  As I wrote in\n\n  http://git-blame.blogspot.com/2012/08/leftover-bits.html\n\nI think the following topic should be revisited:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171841\n\n-- >8 --\nFrom: Junio C Hamano <gitster@pobox.com>\nDate: Tue, 19 Apr 2011 12:18:20 -0700\nSubject: [PATCH] git add: notice removal of tracked paths by default\n\nWhen run without \"-u\" or \"-A\" option,\n\n    $ edit subdir/x\n    $ create subdir/y\n    $ rm subdir/z\n    $ git add subdir/\n\ndoes not notice removal of paths (e.g. subdir/z) from the working tree.\nMake \"git add\" to pretend as if \"-A\" is given when there is a pathspec on\nthe command line.  \"git add\" without any argument continues to be a no-op.\n\nWhen resolving a conflict to remove a path, the current code tells you to\n\"git rm $path\", but now with this patch you can say \"git add $path\".  Of\ncourse you can do \"git add -A $path\" without this patch.\n\nIn either case, the operation \"git add\" is about \"adding the state of the\npath in the working tree to the index\".  The state may happen to be \"path\nremoved\", not \"path has an updated content\".\n\nThe semantic change can be seen by a breakage in t2200, test #15.  There,\na merge has conflicts in path4 and path6 (which are removed from the\nworking tree), and test checks \"git add path4\" to resolve it must fail,\nand makes sure \"add -u\" needs to be used.  We do not have to do this\nanymore.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/add.c         | 3 +++\n t/t2200-add-update.sh | 4 ----\n 2 files changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 89dce56..4eae028 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -389,6 +389,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tif (addremove && take_worktree_changes)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n+\t/* default \"git add pathspec...\" to \"git add -A pathspec...\" */\n+\tif (!take_worktree_changes && argc)\n+\t\taddremove = 1;\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n \tif ((addremove || take_worktree_changes) && !argc) {\ndiff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh\nindex 4cdebda..b2fcd01 100755\n--- a/t/t2200-add-update.sh\n+++ b/t/t2200-add-update.sh\n@@ -150,10 +150,6 @@ test_expect_success 'add -u resolves unmerged paths' '\n \techo 2 >path3 &&\n \techo 2 >path5 &&\n \n-\t# Explicit resolving by adding removed paths should fail\n-\ttest_must_fail git add path4 &&\n-\ttest_must_fail git add path6 &&\n-\n \t# \"add -u\" should notice removals no matter what stages\n \t# the index entries are in.\n \tgit add -u &&\n-- \n1.7.12.rc2.85.g1de7134\n"},{"id":"196924","messageId":"CAN0XMO+42uZ-D3Fz47G+gYr37wgZOqADB3Yvf5DyRB+ptaXkSQ@mail.gmail.com","threadId":"31244","inReplyTo":"7vipcmekzh.fsf@alter.siamese.dyndns.org","subject":"Re: Git add on deleted file","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2012-08-13T18:18:13Z","receivedAt":"2012-08-13T18:18:13Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"I think the message\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nis not clear enough since it lacks on the \"git rm\" command which\nis shown above.\n#   (use \"git add/rm <file>...\" to update what will be committed)\n\nOf course, applying this topic would solve this problem.\nAlternatively we could adjust the message.\n\nOn Mon, Aug 13, 2012 at 7:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Angus Hammond <angusgh@gmail.com> writes:\n>\n>> ... Personally I'd like to see\n>> \"git add foo\" here be equivalent \"git rm --cached foo\", but I can\n>> understand how others might prefer git add not to be destructive like\n>> that.\n>\n> Funny that you bring it up this week.  As I wrote in\n>\n>   http://git-blame.blogspot.com/2012/08/leftover-bits.html\n>\n> I think the following topic should be revisited:\n>\n>   http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171841\n>\n> -- >8 --\n> From: Junio C Hamano <gitster@pobox.com>\n> Date: Tue, 19 Apr 2011 12:18:20 -0700\n> Subject: [PATCH] git add: notice removal of tracked paths by default\n>\n> When run without \"-u\" or \"-A\" option,\n>\n>     $ edit subdir/x\n>     $ create subdir/y\n>     $ rm subdir/z\n>     $ git add subdir/\n>\n> does not notice removal of paths (e.g. subdir/z) from the working tree.\n> Make \"git add\" to pretend as if \"-A\" is given when there is a pathspec on\n> the command line.  \"git add\" without any argument continues to be a no-op.\n>\n> When resolving a conflict to remove a path, the current code tells you to\n> \"git rm $path\", but now with this patch you can say \"git add $path\".  Of\n> course you can do \"git add -A $path\" without this patch.\n>\n> In either case, the operation \"git add\" is about \"adding the state of the\n> path in the working tree to the index\".  The state may happen to be \"path\n> removed\", not \"path has an updated content\".\n>\n> The semantic change can be seen by a breakage in t2200, test #15.  There,\n> a merge has conflicts in path4 and path6 (which are removed from the\n> working tree), and test checks \"git add path4\" to resolve it must fail,\n> and makes sure \"add -u\" needs to be used.  We do not have to do this\n> anymore.\n>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  builtin/add.c         | 3 +++\n>  t/t2200-add-update.sh | 4 ----\n>  2 files changed, 3 insertions(+), 4 deletions(-)\n>\n> diff --git a/builtin/add.c b/builtin/add.c\n> index 89dce56..4eae028 100644\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n> @@ -389,6 +389,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n>\n>         if (addremove && take_worktree_changes)\n>                 die(_(\"-A and -u are mutually incompatible\"));\n> +       /* default \"git add pathspec...\" to \"git add -A pathspec...\" */\n> +       if (!take_worktree_changes && argc)\n> +               addremove = 1;\n>         if (!show_only && ignore_missing)\n>                 die(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n>         if ((addremove || take_worktree_changes) && !argc) {\n> diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh\n> index 4cdebda..b2fcd01 100755\n> --- a/t/t2200-add-update.sh\n> +++ b/t/t2200-add-update.sh\n> @@ -150,10 +150,6 @@ test_expect_success 'add -u resolves unmerged paths' '\n>         echo 2 >path3 &&\n>         echo 2 >path5 &&\n>\n> -       # Explicit resolving by adding removed paths should fail\n> -       test_must_fail git add path4 &&\n> -       test_must_fail git add path6 &&\n> -\n>         # \"add -u\" should notice removals no matter what stages\n>         # the index entries are in.\n>         git add -u &&\n> --\n> 1.7.12.rc2.85.g1de7134\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}