{"thread":{"id":"27136","subject":"[RFC/PATCH] git add: notice removal of tracked paths by default","startedAt":"2011-04-19T19:18:20Z","lastAt":"2011-04-20T08:18:15Z","messageCount":6,"participants":["Junio C Hamano","Sverre Rabbelier","Jeff King","Michael J Gruber"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"166098","messageId":"7v1v0y59tv.fsf@alter.siamese.dyndns.org","threadId":"27136","inReplyTo":null,"subject":"[RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-19T19:18:20Z","receivedAt":"2011-04-19T19:18:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"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\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 (which is removed from the working tree),\nand test checks \"git add path4\" to resolve it must fail, and makes sure\nthat the user must use \"git rm path4\" for that.\n\nSigned-off-by: Junio C Hamano \n---\n\n This might not be such a good idea, and I do not have a strong opinion\n for this change, but merely a weatherbaloon.\n\n Having \"git add .\" notice removals might lead to mistakes (\"oh, I only\n meant to record additions, and didn't want to record the removals\"), but\n at the same time, leaving it not notice removals would lead to mistakes\n by the other people (\"I added, removed and edited different paths, but\n why only removals are ignored?\").\n\n---\n builtin/add.c | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex d39a6ab..0f534e3 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -386,6 +386,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) {\n-- \n1.7.5.rc3\n"},{"id":"166100","messageId":"BANLkTin4iVLzga6gFAh+x8nRTKuVTTFPqA@mail.gmail.com","threadId":"27136","inReplyTo":"7v1v0y59tv.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-04-19T19:46:29Z","receivedAt":"2011-04-19T19:46:29Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Apr 19, 2011 at 21:18, Junio C Hamano wrote:\n>  Having \"git add .\" notice removals might lead to mistakes (\"oh, I only\n>  meant to record additions, and didn't want to record the removals\"), but\n>  at the same time, leaving it not notice removals would lead to mistakes\n>  by the other people (\"I added, removed and edited different paths, but\n>  why only removals are ignored?\").\n\nIs there a way to add disable this somehow? I don't think we have a\n'--no-update', do we?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"166105","messageId":"7voc41537g.fsf@alter.siamese.dyndns.org","threadId":"27136","inReplyTo":"BANLkTin4iVLzga6gFAh+x8nRTKuVTTFPqA@mail.gmail.com","subject":"Re: [RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-19T21:41:23Z","receivedAt":"2011-04-19T21:41:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> Is there a way to add disable this somehow? I don't think we have a\n> '--no-update', do we?\n\nIf we need to be able to disable this, then we are probably better off not\ndoing this change. After all, adding -A on the command line is easy.\n\nThe change makes sense only if nobody wants to do \"only addition and\nmodification\".\n\nI have a strong feeling that the current \"git add $path\" semantics came\nprimarily from historical implementation and pure inertia, and not from a\nwell thought out design. After all, when you are saying \"git add .\" (or\n\"git add dir/\"), you are saying that you want to take what you have in\nthat directory as a whole, except for whatever is excluded with your\nwell-maintained .gitignore file. It felt very unnatural that the command\nexcluded removal without the \"-A\" option when I tried to be in that\nmindset.\n\nBut as I said, I do not have a strong opinion for this change, other than\n\"if we need this optional, then it is not worth doing this\".\n"},{"id":"166106","messageId":"BANLkTimKL2bbmOdh35FDZwf2uAzO=nJkFQ@mail.gmail.com","threadId":"27136","inReplyTo":"7voc41537g.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-04-19T21:47:06Z","receivedAt":"2011-04-19T21:47:06Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Apr 19, 2011 at 23:41, Junio C Hamano wrote:\n> But as I said, I do not have a strong opinion for this change, other than\n> \"if we need this optional, then it is not worth doing this\".\n\nYour argument makes sense, and I personally haven't run into a case\nwhere I _wouldn't_ want the suggested behavior, and I have run into\ncases several times where I _would've_ wanted the suggested behavior.\nSo consider this a +1 for me on the idea.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"166127","messageId":"20110420055758.GC28597@sigill.intra.peff.net","threadId":"27136","inReplyTo":"7v1v0y59tv.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-20T05:57:58Z","receivedAt":"2011-04-20T05:57:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 19, 2011 at 12:18:20PM -0700, Junio C Hamano wrote:\n\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\nI like your proposed semantics much better. I remember many times early\non with git cursing the current behavior, until I finally trained myself\nto do \"git add -A\".\n\n> This might not be such a good idea, and I do not have a strong opinion\n> for this change, but merely a weatherbaloon.\n> \n> Having \"git add .\" notice removals might lead to mistakes (\"oh, I only\n> meant to record additions, and didn't want to record the removals\"), but\n> at the same time, leaving it not notice removals would lead to mistakes\n> by the other people (\"I added, removed and edited different paths, but\n> why only removals are ignored?\").\n\nI suspect most people will want the new semantics, because no matter\nwhat your overall workflow, it is generally going to be some variant of:\n\n 1. hack hack hack\n 2. tell git about changes\n\nAnd you don't really care about deletions versus modifications, you just\nwant them all added. But you probably _do_ care about additions versus\nmodififications, since step 1 often involves creating cruft that should\nremain untracked (whereas it very rarely involves _deleting_ precious\nfiles). And that's why we have \"add -u\", which should not go away.\n\nMy biggest worry would be people saying \"eh? Add removes my files? That\nmakes no sense!\" But we more or less already have that with \"add -u\",\nand I think people have learned to accept that it is about \"add the\ncurrent state to the index\" and not \"add files to git\".\n\n-Peff\n"},{"id":"166138","messageId":"4DAE96C7.9070904@drmicha.warpmail.net","threadId":"27136","inReplyTo":"20110420055758.GC28597@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] git add: notice removal of tracked paths by default","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-20T08:18:15Z","receivedAt":"2011-04-20T08:18:15Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 20.04.2011 07:57:\n> On Tue, Apr 19, 2011 at 12:18:20PM -0700, Junio C Hamano wrote:\n> \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> I like your proposed semantics much better. I remember many times early\n> on with git cursing the current behavior, until I finally trained myself\n> to do \"git add -A\".\n> \n>> This might not be such a good idea, and I do not have a strong opinion\n>> for this change, but merely a weatherbaloon.\n>>\n>> Having \"git add .\" notice removals might lead to mistakes (\"oh, I only\n>> meant to record additions, and didn't want to record the removals\"), but\n>> at the same time, leaving it not notice removals would lead to mistakes\n>> by the other people (\"I added, removed and edited different paths, but\n>> why only removals are ignored?\").\n> \n> I suspect most people will want the new semantics, because no matter\n> what your overall workflow, it is generally going to be some variant of:\n> \n> 1. hack hack hack\n> 2. tell git about changes\n> \n> And you don't really care about deletions versus modifications, you just\n> want them all added. But you probably _do_ care about additions versus\n> modififications, since step 1 often involves creating cruft that should\n> remain untracked (whereas it very rarely involves _deleting_ precious\n> files). And that's why we have \"add -u\", which should not go away.\n> \n> My biggest worry would be people saying \"eh? Add removes my files? That\n> makes no sense!\" But we more or less already have that with \"add -u\",\n> and I think people have learned to accept that it is about \"add the\n> current state to the index\" and not \"add files to git\".\n> \n> -Peff\n\nYes, that behaviour makes much more sense.\n\nThat means that \"git add -A\" is \"git add .\" and \"-A\" is not needed\notherwise any more, right? makes sense, too, and we could probably\ndeprecate (i.e. stop advertising) it.\n\nMichael\n"}]}