{"thread":{"id":"6341","subject":"Removing files","startedAt":"2007-01-11T20:10:20Z","lastAt":"2007-01-12T22:13:26Z","messageCount":15,"participants":["David Kågedal","Alex Riesen","Seth Falcon","Junio C Hamano","Eric Wong","Carl Worth","Jeff King","Jakub Narebski","Juergen Ruehle"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31487","messageId":"87bql5cok3.fsf@morpheus.local","threadId":"6341","inReplyTo":null,"subject":"Removing files","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-11T20:10:20Z","receivedAt":"2007-01-11T20:10:20Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"I'm wondering what the best way to commit the removal of a file is.\n\nLet's assume that I have a file \"foo\" in my tree, that I have removed\nfrom my working tree (e.g. by using patch -E).\n\ngit status shows:\n\n  $ git status\n  # On branch refs/heads/messages\n  # Changed but not added:\n  #   (use \"git add <file>...\" to incrementally add content to commit)\n  #\n  #       deleted:    foo\n\nOk, so I try to follow the instructions in the message:\n\n  $ git add foo\n  fatal: pathspec 'foo' did not match any files\n\nOk, so that didn't work.  Let's try rm instead:\n\n  $ git rm foo\n  fatal: pathspec 'foo' did not match any files\n\nHm, something is wrong here.  But hey, there's a -f option to rm that\nclaims to prevent the \"up-do-date check\"\n\n  $ git rm -f foo\n  fatal: pathspec 'foo' did not match any files\n\nFinally, I have to resort to using update-index.\n\n  $ git update-index --remove foo\n  fatal: pathspec 'foo' did not match any files\n\nSince I believe that the idea is to move to an interface where you use\ne.g. \"git add\" instead of explicitly mentioning the index, I think\nthis is bad.\n\nWhat could be the correct command for this situation.  Some suggestions:\n\n  $ git add foo\n  $ git add --remove foo\n  $ git rm foo\n  $ git rm -f foo\n\n-- \nDavid Kågedal\n"},{"id":"31495","messageId":"20070111213645.GA6058@steel.home","threadId":"6341","inReplyTo":"87bql5cok3.fsf@morpheus.local","subject":"Re: Removing files","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2007-01-11T21:36:45Z","receivedAt":"2007-01-11T21:36:45Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"David Kågedal, Thu, Jan 11, 2007 21:10:20 +0100:\n> I'm wondering what the best way to commit the removal of a file is.\n\ngit commit -a :)\n"},{"id":"31508","messageId":"m2k5ztciad.fsf@gmail.com","threadId":"6341","inReplyTo":"20070111213645.GA6058@steel.home","subject":"Re: Removing files","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-01-11T22:25:46Z","receivedAt":"2007-01-11T22:25:46Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"fork0@t-online.de (Alex Riesen) writes:\n\n> David Kågedal, Thu, Jan 11, 2007 21:10:20 +0100:\n>> I'm wondering what the best way to commit the removal of a file is.\n>\n> git commit -a :)\n\n:-(\n\nI just ran into this very same thing.  I would vote for 'git rm'\nand/or 'git add' doing the right thing here.  I'm probably missing the\nreason they don't already.\n\nPerhaps the doc should also highlight git's globbing, as opposed to\nshell globbing as it is particularly useful when you have already\nremoved files and want to do:\n\ngit update-index --remove 'the-old-place/*.txt' \n\n\n+ seth\n"},{"id":"31512","messageId":"7vejq12nlu.fsf@assigned-by-dhcp.cox.net","threadId":"6341","inReplyTo":"87bql5cok3.fsf@morpheus.local","subject":"Re: Removing files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-11T22:41:01Z","receivedAt":"2007-01-11T22:41:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal <davidk@lysator.liu.se> writes:\n\n> I'm wondering what the best way to commit the removal of a file is.\n\n $ rm -f foo\n $ git-commit -a\n\n> git status shows:\n>\n>   $ git status\n>   # On branch refs/heads/messages\n>   # Changed but not added:\n>   #   (use \"git add <file>...\" to incrementally add content to commit)\n>   #\n>   #       deleted:    foo\n\nSuggesting \"git add\" to record the deletion feels insane.  Is\nthis what we still do?  I think there have been much work \nin this area recently so the wordings might have already fixed.\n\n> Ok, so that didn't work.  Let's try rm instead:\n>\n>   $ git rm foo\n>   fatal: pathspec 'foo' did not match any files\n>\n\nThe above message is from an older version of git-rm, but the\none that will be in v1.5.0 is not any better.  It errs out with\n\"No such file or directory\".  A workaround using today's tool is\nto do \"git rm --cached fo\"\n\nI think the right fix is to suggest \"git add/rm\" in status\noutput and make \"git rm\" not barf if the user has already\nremoved the file from the working tree.\n\n        \n"},{"id":"31513","messageId":"20070111231955.GB13564@localdomain","threadId":"6341","inReplyTo":"7vejq12nlu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Removing files","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-11T23:19:55Z","receivedAt":"2007-01-11T23:19:55Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> David Kågedal <davidk@lysator.liu.se> writes:\n> \n> > I'm wondering what the best way to commit the removal of a file is.\n> \n>  $ rm -f foo\n>  $ git-commit -a\n> \n> > git status shows:\n> >\n> >   $ git status\n> >   # On branch refs/heads/messages\n> >   # Changed but not added:\n> >   #   (use \"git add <file>...\" to incrementally add content to commit)\n> >   #\n> >   #       deleted:    foo\n> \n> Suggesting \"git add\" to record the deletion feels insane.  Is\n> this what we still do?  I think there have been much work \n> in this area recently so the wordings might have already fixed.\n> \n> > Ok, so that didn't work.  Let's try rm instead:\n> >\n> >   $ git rm foo\n> >   fatal: pathspec 'foo' did not match any files\n> >\n> \n> The above message is from an older version of git-rm, but the\n> one that will be in v1.5.0 is not any better.  It errs out with\n> \"No such file or directory\".  A workaround using today's tool is\n> to do \"git rm --cached fo\"\n> \n> I think the right fix is to suggest \"git add/rm\" in status\n> output and make \"git rm\" not barf if the user has already\n> removed the file from the working tree.\n\nWould having a command like 'hg addremove' make things easier?  I've\nbeen using the below script since my early days of using git, but I\ndon't think I've ever published it.  If you want I can create a\npatch against git.git\n\n-----------------------------------------------------------------------\n#!/bin/sh\n# like the addremove command in mercurial\n\nif test \"x$1\" = \"x-h\"\nthen\n\techo \"Usage: git-addrm [<path>]\"\n\texit 0\nfi\nSUBDIRECTORY_OK=1\n. git-sh-setup || die \"Not a git archive\"\n\nEXCLUDE_ARGS=--exclude-per-directory=.gitignore\n\nif test -f \"$GIT_DIR/info/exclude\"\nthen\n\tEXCLUDE_ARGS=\"$EXCLUDE_ARGS --exclude-from=$GIT_DIR/info/exclude\"\nfi\n\nset -e\ngit-ls-files -z --deleted $EXCLUDE_ARGS \"$@\"| \\\n\tgit-update-index --remove -z --stdin\ngit-ls-files -z --others $EXCLUDE_ARGS \"$@\" | \\\n\tgit-update-index --add -z --stdin\n-----------------------------------------------------------------------\n\n-- \nEric Wong\n"},{"id":"31514","messageId":"7vzm8p16h9.fsf@assigned-by-dhcp.cox.net","threadId":"6341","inReplyTo":"7vejq12nlu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Removing files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-11T23:36:18Z","receivedAt":"2007-01-11T23:36:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> I think the right fix is to suggest \"git add/rm\" in status\n> output and make \"git rm\" not barf if the user has already\n> removed the file from the working tree.\n\nThis does the latter.  A separate patch will do the former.\n\n-- >8 --\n\n[PATCH] git-rm: do not fail on already removed file.\n\nOften the user would do \"/bin/rm foo\" before telling git, but\nthen want to tell git about it.  \"git rm foo\" however would fail\nbecause it cannot unlink(2) foo.\n\nTreat ENOENT error return from unlink(2) as if a successful\nremoval happened.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n builtin-rm.c |    6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-rm.c b/builtin-rm.c\nindex 5b078c4..d81f289 100644\n--- a/builtin-rm.c\n+++ b/builtin-rm.c\n@@ -32,6 +32,10 @@ static int remove_file(const char *name)\n \tchar *slash;\n \n \tret = unlink(name);\n+\tif (ret && errno == ENOENT)\n+\t\t/* The user has removed it from the filesystem by hand */\n+\t\tret = errno = 0;\n+\n \tif (!ret && (slash = strrchr(name, '/'))) {\n \t\tchar *n = xstrdup(name);\n \t\tdo {\n@@ -204,7 +208,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)\n \t\treturn 0;\n \n \t/*\n-\t * Then, unless we used \"--cache\", remove the filenames from\n+\t * Then, unless we used \"--cached\", remove the filenames from\n \t * the workspace. If we fail to remove the first one, we\n \t * abort the \"git rm\" (but once we've successfully removed\n \t * any file at all, we'll go ahead and commit to it all:\n-- \n1.4.4.4.gb8a1\n"},{"id":"31515","messageId":"7vsleh16ey.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6341","inReplyTo":"7vejq12nlu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-status: wording update to deal with deleted files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-11T23:37:41Z","receivedAt":"2007-01-11T23:37:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"If you do:\n\n\t$ /bin/rm foo\n\t$ git status\n\nwe used to say \"git add ... to add content to commit\".  But\nsuggsting \"git add\" to record the deletion of a file is simply\ninsane.\n\nSo this rewords various things:\n\n - The section header is the old \"Changed but not updated\",\n   instead of \"Changed but not added\";\n\n - Suggestion is \"git add ... to update what will be committed\",\n   instead of \"... to add content to commit\";\n\n - If there are removed paths, the above suggestion becomes \"git\n   add/rm ... to update what will be committed\";\n\n - For untracked files, the suggestion is \"git add ... to\n   include in what will be committed\".\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n * This needs the previous \"git rm\" update to make sense.\n   Currently \"/bin/rm foo ; git rm foo\" would fail because the\n   latter cannot remove foo (it gets \"No such file or\n   directory\").\n\n wt-status.c |   19 ++++++++++++++++---\n 1 files changed, 16 insertions(+), 3 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 1dc2fdc..a849951 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -15,7 +15,13 @@ static char wt_status_colors[][COLOR_MAXLEN] = {\n \t\"\\033[31m\", /* WT_STATUS_CHANGED: red */\n \t\"\\033[31m\", /* WT_STATUS_UNTRACKED: red */\n };\n-static const char* use_add_msg = \"use \\\"git add <file>...\\\" to incrementally add content to commit\";\n+\n+static const char use_add_msg[] =\n+\"use \\\"git add <file>...\\\" to update what will be committed\";\n+static const char use_add_rm_msg[] =\n+\"use \\\"git add/rm <file>...\\\" to update what will be committed\";\n+static const char use_add_to_include_msg[] =\n+\"use \\\"git add <file>...\\\" to include in what will be committed\";\n \n static int parse_status_slot(const char *var, int offset)\n {\n@@ -177,8 +183,14 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,\n \tstruct wt_status *s = data;\n \tint i;\n \tif (q->nr) {\n+\t\tconst char *msg = use_add_msg;\n \t\ts->workdir_dirty = 1;\n-\t\twt_status_print_header(\"Changed but not added\", use_add_msg);\n+\t\tfor (i = 0; i < q->nr; i++)\n+\t\t\tif (q->queue[i]->status == DIFF_STATUS_DELETED) {\n+\t\t\t\tmsg = use_add_rm_msg;\n+\t\t\t\tbreak;\n+\t\t\t}\n+\t\twt_status_print_header(\"Changed but not updated\", msg);\n \t}\n \tfor (i = 0; i < q->nr; i++)\n \t\twt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);\n@@ -265,7 +277,8 @@ static void wt_status_print_untracked(struct wt_status *s)\n \t\t}\n \t\tif (!shown_header) {\n \t\t\ts->workdir_untracked = 1;\n-\t\t\twt_status_print_header(\"Untracked files\", use_add_msg);\n+\t\t\twt_status_print_header(\"Untracked files\",\n+\t\t\t\t\t       use_add_to_include_msg);\n \t\t\tshown_header = 1;\n \t\t}\n \t\tcolor_printf(color(WT_STATUS_HEADER), \"#\\t\");\n-- \n1.4.4.4.gb8a1\n"},{"id":"31516","messageId":"87bql5xhbi.wl%cworth@cworth.org","threadId":"6341","inReplyTo":"87bql5cok3.fsf@morpheus.local","subject":"Re: Removing files","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-11T23:41:05Z","receivedAt":"2007-01-11T23:41:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 11 Jan 2007 21:10:20 +0100, David Kågedal wrote:\n> Let's assume that I have a file \"foo\" in my tree, that I have removed\n> from my working tree (e.g. by using patch -E).\n\nThanks for the example, David. I think this points out several\nproblems with the current state of git.\n\n>   # Changed but not added:\n>   #   (use \"git add <file>...\" to incrementally add content to commit)\n>   #\n>   #       deleted:    foo\n> \n> Ok, so I try to follow the instructions in the message:\n\nClearly \"git add\" is the wrong thing to recommend here, (in that it\ncurrently doesn't update the index for a removed file). I think this\nis a bug in git-status.\n\nI also believe it would be incorrect to \"fix\" git-add to make it\nremove files as well. Having a command named \"add\" whose\nfunctionality could be to do the opposite of the meaning of that\ncommand would be horribly confusing, (and not an improvement in the\nusability or learnability of git).\n\n>   $ git rm foo\n>   fatal: pathspec 'foo' did not match any files\n\nI think that's just a bug in git-rm and should be fixed.\n\n> What could be the correct command for this situation.  Some suggestions:\n> \n>   $ git add foo\n>   $ git add --remove foo\n\nAs I said above, I think making \"add\" perform removal, (which is the\nopposite of what \"add\" means) would be a very bad idea.\n\n>   $ git rm foo\n>   $ git rm -f foo\n\nI think either of the above should be fixed to work. The \"safety\ncheck\" here is an attempt to catch typos, right? Shouldn't that be\nchecking for the existence of the path in the index rather than in the\nworking tree?\n\nThere are also two other possible commands here:\n\n$ git commit file\n\nOn the list someone recently pointed out that this didn't work for\nthem (after removing a file). I had thought the conclusion was that\nJunio wasn't interested in doing the work to make \"index skipping\"\nwork for this case. But maybe someone else did the work already,\nbecause this did work for me when I tested now. Did I just get lucky?\nOr is this officially supported now? (I'm quite happy to see this\nworking as otherwise we'd be left with only \"commit -a\" as a\npure-porcelain way of removing files---see below.)\n\n$ git commit -a\n\nThis was already mentioned in a separate reply. This works, but there\nare a couple of problems if this were the only supported way to remove\na file:\n\n1. It doesn't allow for a \"staged\" file removal, (that is removing a\n   file while allowing other dirty changes to remain in the working\n   tree).\n\n2. The fact that \"commit -a\" commits file removal is not documented at\n   all. This was pointed out to me recently by a cairo contributor who\n   was quite tripped up by this aspect of \"commit -a\".\n\n   What the \"commit -a\" documentation says is:\n\n       4. by using the -a switch with the commit command to automatically \"add\" changes\n          from all known files i.e. files that have already been committed before, and\n          perform the actual commit.\n\n   And as already discussed above, \"add\" doesn't actually updating a\n   file removal into the index. And I think it would be a mistake to\n   extend \"add\" to do removal as well, (at that point \"add\" would\n   become little more than a synonym for update-index without the\n   --add and --rm safety checks).\n\nSo what's the fix for the \"commit -a\" documentation? One approach is\nto add more language about file removal to the description of \"commit\n-a\". The wording proposed by Jonathan Watt is:\n\n       4. by using the -a switch with the commit command to automatically \"add\" changes\n          from all known files (i.e. files that have already been committed before),\n          automatically remove all known files that have been removed from the working\n          tree, and perform the actual commit.\n\nThat's perhaps functional, but it's getting to be a lot of language to\nhave to grasp for new users. The goal of the new first-class-add was\nto be able to simplify the documentation of things like this. I think\nthat's a failed experiment.\n\nI'd much rather see the documentation for git-commit present a list\nsomething like the following:\n\n  Use git commit to record changes into the repository along with a\n  log message describing the changes. New files (or directories) must\n  be made known to git with \"git add\" before they can be committed.\n\n  The changes to be committed are identified with one of three\n  different forms of the git commit command:\n\n  1. git commit\n\n\tWithout any specific file names mentioned (and without the -a\n\toption), commit changes from content that has been \"staged\"\n\tfor this commit. Content can be staged with the \"git add\" or\n\t\"git rm\" commands.\n\n  2. git commit paths...\n\n\tWith a list of file (or directory) paths, commit changes from\n\tthe working-tree content of all named paths, (remember that\n\t\"git add\" must be used before committing any new files).\n\n  3. git commit -a\n\n\tCommit the working-tree content of all files known to git,\n\t(remember that \"git add\" must be used before committing any\n\tnew files)\n\n  Note that what git commits is \"working-tree content\" that means that\n  committing file a file deletion is as simple as removing the file\n  from the working tree and then using \"commit -a\" or \"commit file\" to\n  commit that removal.\n\nI've written that in a way that it should be usable as documentation\nwithout any changes to how git currently works, (I think---let me know\nif I got any of it wrong).\n\nBut I would still like to point out some things that could be\nimproved. First, the \"(remember that 'git add'...)\" phrases are quite\nredundant and should really be removed. I included them here only to\npoint out that the way that \"git add\" with \"commit paths...\" and\n\"commit -a\" is really fundamentally different than \"git add\" used for\nstaging with git-commit (form (1) without paths or -a).\n\nI think that difference should be fully recognized, and that git could\nbe made easier to learn if it were. Specifically, I think a \"git\nstage\" command, (a \"porcelain\" version of update-index) would fit into\nthe description of form (1) quite nicely.\n\nAlso, (and especially if the \"remember\" phrases are removed), note\nthat the three different commit commands are written in\nreverse-simplicity order. That is, \"commit -a\", the form with the\nshortest explanation (and the fewest necessary concepts), comes\nlast. That's also not so nice for learning. So, I think the order of\nthe descriptions should be reversed, (with this style of explanation\nfor \"commit -a\", there's no need to base it on an understanding of a\nstaged commit first).\n\nSo, what I'd like to see, (but would require the addition of \"git\nstage\" and a slight philosophical switch in the consensus for how git\nshould be taught), would be:\n\n    git commit -a\n\n\tCommit the working-tree content of all files known to git.\n\n    git commit paths...\n\n\tCommit changes from the working-tree content of the specified\n\tpaths.\n\n    git commit\n\n\tCommit changes from all content that has been staged with\n\t\"git stage\".\n\nThis approach, (separating \"stage\" for staging into the index from\n\"add\" for adding new paths), would also allow for \"add\" to be changed\nto not also stage the content into the index.\n\nI really like the simplicity of explanation that this model\nprovides. And I'd love to hear any feedback that anybody has about it.\n\n-Carl\n\nPS. And look! I even resisted the next step which would be to\nrecognize that the simplest-to-explain and most-common-to-use form\nshould have the simplest command-line syntax. That is, I didn't\nsuggest command-lines of:\n\n    git commit\n\t...\n    git commit paths...\n\t...\n    git commit -s|--staged\n\t...\n"},{"id":"31520","messageId":"87ac0pxgl2.wl%cworth@cworth.org","threadId":"6341","inReplyTo":"7vsleh16ey.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-11T23:56:57Z","receivedAt":"2007-01-11T23:56:57Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"All very good stuff Junio, thanks.\n\nIn light of the big long message I just wrote, let me comment on the\nchanges you just made here.\n\nOn Thu, 11 Jan 2007 15:37:41 -0800, Junio C Hamano wrote:\n> we used to say \"git add ... to add content to commit\".  But\n> suggsting \"git add\" to record the deletion of a file is simply\n> insane.\n\nI'm very happy to hear you agree that would be insane.\n\n>  - The section header is the old \"Changed but not updated\",\n>    instead of \"Changed but not added\";\n\nAgain, not only deletion, but another place where \"add\" doesn't work\nuniversally. As I mentioned in my other thread, the experiment in\nusing \"add\" as a first-class porcelain for all index updating just\ndoesn't work everywhere.\n\nThe caution I would point out here is that we are now introducing a\nterm (\"update\") into the output-side of git's user-interface, but that\nthere's no corresponding \"update\" on the input side, (at least as far\nas porcelain is concerned). So conceptually, the user can be left\nwith, \"hmm... it's not updated, but how the heck do I update it?\".\n\n>  - Suggestion is \"git add ... to update what will be committed\",\n>    instead of \"... to add content to commit\";\n>\n>  - If there are removed paths, the above suggestion becomes \"git\n>    add/rm ... to update what will be committed\";\n\nHere now we do start providing the user with some mechanisms for\n\"update\". Sometimes we suggest using \"add\" to update, and sometimes we\nsuggest using \"add\" or \"rm\" to update. But as you yourself have\npointed out, you consider \"rm\" a totally pointless command.\n\nWouldn't git be simpler if it only provided one porcelain command for\nupdating content into the index? I proposed \"stage\" in my preceding\nemail---but I don't care what the actual term used is. But it should\ndefinitely be a term that's consistent with the terms that git-status\nuses to describe the state of these files.\n\n>  - For untracked files, the suggestion is \"git add ... to\n>    include in what will be committed\".\n\nAnd here is where git-status points out that \"git add\" has another use\nthat's conceptually distinct from updating content. I think that\ndistinction should be made more clear by \"git add\" being a separate\ncommand from whatever the porcelain for \"update content into the\nindex\" becomes.\n\n-Carl\n"},{"id":"31521","messageId":"20070112000701.GC16042@coredump.intra.peff.net","threadId":"6341","inReplyTo":"7vsleh16ey.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-12T00:07:01Z","receivedAt":"2007-01-12T00:07:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 11, 2007 at 03:37:41PM -0800, Junio C Hamano wrote:\n\n>  - The section header is the old \"Changed but not updated\",\n>    instead of \"Changed but not added\";\n\nIsn't that the original wording that we recently got rid of? I think\nit's a bit confusing, given that \"changed\" and \"updated\" really mean the\nsame thing (we tend to use 'updated' only to refer to the index, but new\nusers don't know that). How about \"Changed but not marked for commit\"?\nOr even \"Files with changes that are not marked for commit\" (which is\nlonger, but more precise).\n\nMaybe it would be clearer to split the section (and only show those\nsections which are applicable):\n\n  Files with changes that have are not marked for commit:\n    (use \"git add <file>\" to mark changes)\n\n  Files that have been removed but not marked for commit:\n    (use \"git rm <file>\" to mark for commit)\n\n  Files that exist but have not been marked for commit:\n    (use \"git add <file>\" to mark for commit)\n\nThe latter being the current untracked files. And potentially even:\n\n  Files that have merge conflicts:\n    (use \"git add <file>\" to mark as resolved)\n\nAnd yet another option would be to individually mark each file:\n  #  deleted: foo  (use \"git rm\" to mark for deletion)\nbut I think that is probably too verbose.\n\nAnyway, please consider my first wording change, if not the more radical\nsplitting.\n\n-Peff\n"},{"id":"31522","messageId":"7v1wm114rx.fsf@assigned-by-dhcp.cox.net","threadId":"6341","inReplyTo":"87ac0pxgl2.wl%cworth@cworth.org","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T00:13:06Z","receivedAt":"2007-01-12T00:13:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> ... So conceptually, the user can be left\n> with, \"hmm... it's not updated, but how the heck do I update it?\".\n>\n>>  - Suggestion is \"git add ... to update what will be committed\",\n>>    instead of \"... to add content to commit\";\n>>\n>>  - If there are removed paths, the above suggestion becomes \"git\n>>    add/rm ... to update what will be committed\";\n>\n> Here now we do start providing the user with some mechanisms for\n> \"update\". Sometimes we suggest using \"add\" to update, and sometimes we\n> suggest using \"add\" or \"rm\" to update. But as you yourself have\n> pointed out, you consider \"rm\" a totally pointless command.\n\nYou are twisting my words ;-).\n\n\"rm\" is pointless for a workflow that always uses \"commit -a\".\nIn the same sense, the three categorization \"git-status\" gives\nis pointless -- \"changed but not updated\" class does not have\nany significance if you always do \"commit -a\".\n\nBut that is not the only workflow we encourage.\n\nI do encourage \"commit -a\" or \"commit after update-index\" and\nfrown upon but tolerate \"commit <paths>...\" --- all of the above\nis in line with this world view.   And the categorization and\nsuggestions are about the latter: \"commit after update-index\".\n\nThen the issue is how to expose update-index to the end users.\n\"add\" is about adding the content.  What's unfortunate is that\nadding a file as zero-length content is still different from\nremoving it.\n\nHonestly, removing is so different from the norm that I do not\nsee major inconsistency nor inconvenience, practically nor in\nphilosophy, to have two separate Porcelain-ish commands, add and\nrm, to perform content additions and removal.\n"},{"id":"31523","messageId":"20070112001754.GD16042@coredump.intra.peff.net","threadId":"6341","inReplyTo":"87bql5xhbi.wl%cworth@cworth.org","subject":"Re: Removing files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-12T00:17:55Z","receivedAt":"2007-01-12T00:17:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 11, 2007 at 03:41:05PM -0800, Carl Worth wrote:\n\n>     git commit -a\n> \n> \tCommit the working-tree content of all files known to git.\n> \n>     git commit paths...\n> \n> \tCommit changes from the working-tree content of the specified\n> \tpaths.\n> \n>     git commit\n> \n> \tCommit changes from all content that has been staged with\n> \t\"git stage\".\n> \n[...]\n> I really like the simplicity of explanation that this model\n> provides. And I'd love to hear any feedback that anybody has about it.\n\nI think this is a very easy way of explaining it in the documentation.\nBut what do you think 'git status' should say about changed files?\nCurrently we make recommendations about how to stage the various files.\nIt would certainly be simpler to recommend 'git commit -a' for changes,\nbut that feels wrong.\n\n-Peff\n"},{"id":"31533","messageId":"878xg9xcca.wl%cworth@cworth.org","threadId":"6341","inReplyTo":"7v1wm114rx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-12T01:28:37Z","receivedAt":"2007-01-12T01:28:37Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 11 Jan 2007 16:13:06 -0800, Junio C Hamano wrote:\n> You are twisting my words ;-).\n\nI apologize. I really didn't intend to twist any words. What I was\nremembering was a sentence like the following:\n\n\tFrom: Junio C Hamano <junkio@cox.net>\n\tMessage-ID: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net>\n\tSubject: Re: How to commit removed file?\n\tDate: Tue, 02 Jan 2007 13:40:41 -0800\n\t...\n\tPersonally I never saw the point of having \"git rm\".  Maybe we\n\tshould remove it to prevent this confusion from happening.\n\nWhat I'll describe below would actually allow us to drop git-rm if we\nreally wanted to, (but I don't think it's important to do that, nor\nthat we even should). That's just an almost accidental side effect of\nwhat I'm describing.\n\n> But that is not the only workflow we encourage.\n>\n> I do encourage \"commit -a\" or \"commit after update-index\" and\n> frown upon but tolerate \"commit <paths>...\" --- all of the above\n> is in line with this world view.\n\nOK, so let's use these two different workflows and look at what we're\nproviding. (Personally, I also like to think about only two different\nworkflows, but I see \"commit <paths>...\" as just doing a\nfile-boundary-based subset of \"commit -a\").\n\nCurrently, the necessary, porcelain, \"commit preparing\" commands for\neach workflow are:\n\ncommit after update-index\n-------------------------\ngit add: add content for new files, modified files\ngit rm: mark files to be removed\n\ncommit -a\n---------\ngit add: mark new files to be committed\n\n> Then the issue is how to expose update-index to the end users.\n> \"add\" is about adding the content.  What's unfortunate is that\n> adding a file as zero-length content is still different from\n> removing it.\n\nBut fortunately the distinction between a zero-length file that exists\nand a file that does not exist is quite evident in the working\ntree. So it would still be a very well-defined thing to have a command\nfor \"update content\" that could update whatever content a file has\ninto the index (even zero-length content) if the file exists in the\nworking tree, or remove the path from the index if the file does not\nexist.\n\nI agree that \"add\" would be an insane name for this command. The best\nproposal I've been able to make for this command is \"stage\". The only\nother thing I can think of that uses accepted terminology from git\nwould be \"update\", but I think that would be a very bad choice, (since\ncertain other version control systems use \"update\" to describe an\noperation much more like git's \"pull\").\n\nSo if we had this \"stage\" command, (and assuming it staged content for\nnew files), then look what happens to the list of preparatory commands\nneeded for each workflow:\n\ncommit after stage\n------------------\ngit stage: stage content for new, modified, or removed files\n\ncommit -a\n---------\ngit add: mark new files to be committed\n\nCompare that to the above description. Isn't it beautiful from a\nconceptual point-of-view? The \"git rm\" command isn't needed at all,\n(though we could certainly still provide it). And now the \"git add\"\ncommand only has one conceptual use, for (of all thing!) adding new\nfiles, not updating content for files that have been modified.\n\n> Honestly, removing is so different from the norm that I do not\n> see major inconsistency nor inconvenience, practically nor in\n> philosophy, to have two separate Porcelain-ish commands, add and\n> rm, to perform content additions and removal.\n\nI don't have a problem with it either. I'm not trying to make an\nargument based on why git-rm should be removed. It can live around all\nit wants, but I think there's conceptual simplification in this model,\n(which can only help to make git easier to learn).\n\n-Carl\n"},{"id":"31580","messageId":"eo8ols$ja$2@sea.gmane.org","threadId":"6341","inReplyTo":"878xg9xcca.wl%cworth@cworth.org","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-12T19:48:34Z","receivedAt":"2007-01-12T19:48:34Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> commit after stage\n> ------------------\n> git stage: stage content for new, modified, or removed files\n> \n> commit -a\n> ---------\n> git add: mark new files to be committed\n> \n> Compare that to the above description. Isn't it beautiful from a\n> conceptual point-of-view? The \"git rm\" command isn't needed at all,\n> (though we could certainly still provide it). And now the \"git add\"\n> command only has one conceptual use, for (of all thing!) adding new\n> files, not updating content for files that have been modified.\n\nWithout \"git rm\" (or \"git update-index --force-remove\") you cannot\nmake file to be untracked by git, i.e. remove it from the files\ntracked by git but not remove it from directory.\n\nWith current version of git-rm (modulo bugs), if you do \"git rm <file>\"\nthe file would be removed from index, and if recoverable from working\ndirectory. Without git-rm you would have to use plumbing to remove it from\nindex but preserve changes.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31601","messageId":"17832.2054.95000.756004@lapjr.intranet.kiel.bmiag.de","threadId":"6341","inReplyTo":"7vsleh16ey.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-status: wording update to deal with deleted files.","fromName":"Juergen Ruehle","fromEmail":"j.ruehle@bmiag.de","sentAt":"2007-01-12T22:13:26Z","receivedAt":"2007-01-12T22:13:26Z","isPatch":true,"sender":{"key":"j.ruehle@bmiag.de","avatar":null},"body":"Junio C Hamano writes:\n > If you do:\n > \n > \t$ /bin/rm foo\n > \t$ git status\n > \n > we used to say \"git add ... to add content to commit\".  But\n > suggsting \"git add\" to record the deletion of a file is simply\n > insane.\n > \n > So this rewords various things:\n > \n >  - The section header is the old \"Changed but not updated\",\n >    instead of \"Changed but not added\";\n > \n >  - Suggestion is \"git add ... to update what will be committed\",\n >    instead of \"... to add content to commit\";\n > \n >  - If there are removed paths, the above suggestion becomes \"git\n >    add/rm ... to update what will be committed\";\n > \n >  - For untracked files, the suggestion is \"git add ... to\n >    include in what will be committed\".\n > \n > Signed-off-by: Junio C Hamano <junkio@cox.net>\n\nI should have beaten you to it, since Michael had already noticed that\non wednesday, but I was too busy. Thanks.\n"}]}