{"thread":{"id":"41819","subject":"[RFD] minor frustration in 'git add' pathname completion","startedAt":"2016-03-24T21:44:07Z","lastAt":"2016-03-25T00:38:10Z","messageCount":8,"participants":["Junio C Hamano","Stefan Beller","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281728","messageId":"xmqqr3ez7dqw.fsf@gitster.mtv.corp.google.com","threadId":"41819","inReplyTo":null,"subject":"[RFD] minor frustration in 'git add' pathname completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-24T21:44:07Z","receivedAt":"2016-03-24T21:44:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It seems that \"git add foo\" completes to files\n\n (1) whose names match 'foo*',\n\n (2) that are not ignored (i.e. \"foobar~\" will not be offered for\n Emacs users), and\n\n (3) are different from the index.\n\nThe last one is somewhat frustrating at times. For example, I keep\na backup version of whats-cooking.txt in the working tree that I use\nto manage the 'todo' branch as whats-cooking.txt+, and this is not\nexplicitly \"ignored\". Most of the time, I have changes to the real\nfile, so\n\n $ git add whats\n\nwould complete to \"whats-cooking.txt\" (because there are two\ncandidates, \"whats-cooking.txt\" and \"whats-cooking.txt+\", and the\nfirst completion is done up to the common prefix) and everything is\ngood.\n\nImmediately after I did \"git add whats-cooking.txt\", however,\nbecause of (3), the completion for \n\n $ git add whats\n\noffers \"whats-cooking.txt+\", because that is the only candidate that\npasses all three criteria. This is quite annoying and even dangerous,\nbecause it does not happen most of the time.\n\nI am wondering if there is a downside to removing (3) from the\ncompletion logic.\n\nDiscuss.\n\nThanks.\n"},{"id":"281733","messageId":"CAGZ79kaUPf=kBCuH__8BahjM3WjSGaijiQr05pMKe+TNdg3W9w@mail.gmail.com","threadId":"41819","inReplyTo":"xmqqr3ez7dqw.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-24T21:56:14Z","receivedAt":"2016-03-24T21:56:14Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote:\n> Discuss.\n\n> For example, I keep\n> a backup version of whats-cooking.txt in the working tree that I use\n> to manage the 'todo' branch as whats-cooking.txt+, and this is not\n> explicitly \"ignored\".\n\nCompletely side tracking thought: Have you considered ignoring\nwhats-cooking.txt+ locally?\n\nWC+ is a local thing to your repo, so you'd want to prefer\n$GIT_DIR/info/exclude over .gitignore.\n\nYou wish to ignore WC+ by git, so make it be ignored,\ninstead of changing the git add rules. Your proposal\nfeels like fixing the symptoms instead of the root cause.\n\nI can see (3) being useful as it narrows down the list\nby a lot, I would imagine.\n\nAs I rarely use git add, but prefer git-gui, I have no experience though\nfor git-add completion, but if you had one conflict after a bad merge\nyou can just do git add to get that file(?), so I guess people use it.\n\nStefan\n\n\n>\n> Thanks.\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"},{"id":"281734","messageId":"xmqqbn637cpe.fsf@gitster.mtv.corp.google.com","threadId":"41819","inReplyTo":"CAGZ79kaUPf=kBCuH__8BahjM3WjSGaijiQr05pMKe+TNdg3W9w@mail.gmail.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-24T22:06:37Z","receivedAt":"2016-03-24T22:06:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote:\n>> Discuss.\n>\n>> For example, I keep\n>> a backup version of whats-cooking.txt in the working tree that I use\n>> to manage the 'todo' branch as whats-cooking.txt+, and this is not\n>> explicitly \"ignored\".\n>\n> Completely side tracking thought: Have you considered ignoring\n> whats-cooking.txt+ locally?\n\nThe point is that I shouldn't have to. I wasn't asking for a\nworkaround.\n"},{"id":"281738","messageId":"xmqq7fgr7brd.fsf@gitster.mtv.corp.google.com","threadId":"41819","inReplyTo":"xmqqbn637cpe.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-24T22:27:02Z","receivedAt":"2016-03-24T22:27:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Stefan Beller writes:\n>\n>> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote:\n>>> Discuss.\n>>\n>>> For example, I keep\n>>> a backup version of whats-cooking.txt in the working tree that I use\n>>> to manage the 'todo' branch as whats-cooking.txt+, and this is not\n>>> explicitly \"ignored\".\n>>\n>> Completely side tracking thought: Have you considered ignoring\n>> whats-cooking.txt+ locally?\n>\n> The point is that I shouldn't have to. I wasn't asking for a\n> workaround.\n\nMore importantly, I suspect that it would not work very well as a\nworkaround.\n\nIf I were to explicitly ignore that file, then even though I know\nwhats-cooking.txt is not ignored,\n\n $ git add whats-coo\n\nwould not offer anything. I'd be left scratching my head, wondering\nif I mistyped the early part of the filename (e.g. \"wahts-coo\"?).\n\nI think the source of the irritation comes from the fact that the\ncommand line completion can only say \"I do not see anything worth\nadding with the prefix you gave me\" by not completing the prefix\nstring to anything, and it cannot explain why it thinks so\n(e.g. \"because the path that matches the prefix is up-to-date and\nthere is no point adding it again\" vs \"because there is no path that\nmatches the prefix, perhaps you made a typo?\"). Loosening (3) might\nbe an effective way to address it.\n"},{"id":"281739","messageId":"xmqq37rf7bnl.fsf@gitster.mtv.corp.google.com","threadId":"41819","inReplyTo":"xmqqr3ez7dqw.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-24T22:29:18Z","receivedAt":"2016-03-24T22:29:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I am wondering if there is a downside to removing (3) from the\n> completion logic.\n>\n> Discuss.\n\nEh, please don't. Somehow this no longer reproduces for me.\n"},{"id":"281741","messageId":"CAGZ79kYDWJDDJ+doy3NcZH_dqbbFE8U2UHZjnYYTo5R9GTsghQ@mail.gmail.com","threadId":"41819","inReplyTo":"xmqqbn637cpe.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-24T22:40:19Z","receivedAt":"2016-03-24T22:40:19Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Mar 24, 2016 at 3:06 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote:\n>>> Discuss.\n>>\n>>> For example, I keep\n>>> a backup version of whats-cooking.txt in the working tree that I use\n>>> to manage the 'todo' branch as whats-cooking.txt+, and this is not\n>>> explicitly \"ignored\".\n>>\n>> Completely side tracking thought: Have you considered ignoring\n>> whats-cooking.txt+ locally?\n>\n> The point is that I shouldn't have to. I wasn't asking for a\n> workaround.\n\nIt is not a workaround. You want to have an untracked file in a repository,\nbut you want git add to ignore it, which sounds like the definition of the\nignoring mechanism.\n\n> If I were to explicitly ignore that file, then even though I know\n> whats-cooking.txt is not ignored,\n>\n> $ git add whats-coo\n>\n> would not offer anything. I'd be left scratching my head, wondering\n> if I mistyped the early part of the filename (e.g. \"wahts-coo\"?).\n\nWell, git add cannot do anything with either of the files, so why would\nit offer to complete to one of them?\n\nIn an ideal world it would tell you whats-cooking.txt doesn't need\nadding and whats-cooking.txt+ is ignored locally so excluded from\nbeing added.\n\n>> Discuss.\n>\n> Eh, please don't. Somehow this no longer reproduces for me.\n\nUh, is there a good way to test auto completion if at all in our\ntest suite? (Would we want such a thing to be tested?)\n"},{"id":"281742","messageId":"xmqqy4975vv7.fsf@gitster.mtv.corp.google.com","threadId":"41819","inReplyTo":"CAGZ79kYDWJDDJ+doy3NcZH_dqbbFE8U2UHZjnYYTo5R9GTsghQ@mail.gmail.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-24T22:55:40Z","receivedAt":"2016-03-24T22:55:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n>> If I were to explicitly ignore that file, then even though I know\n>> whats-cooking.txt is not ignored,\n>>\n>> $ git add whats-coo\n>>\n>> would not offer anything. I'd be left scratching my head, wondering\n>> if I mistyped the early part of the filename (e.g. \"wahts-coo\"?).\n>\n> Well, git add cannot do anything with either of the files, so why would\n> it offer to complete to one of them?\n>\n> In an ideal world it would tell you whats-cooking.txt doesn't need\n> adding and whats-cooking.txt+ is ignored locally so excluded from\n> being added.\n\nExactly my point that you omitted from your quoting ;-)\n\nBecause the completion cannot give such an explanation, the\nbehaviour gives an unnecessary confusion to the user. If it offered\nwhats-cooking.txt as a candidate, at least the behaviour would make\nsense to the user. \"Doesn't need adding\" is quite different from\n\"must not be added\". In other words, \"git add A && git add A\" does\nnot hurt, but \"git add A~\" would because the latter would only makes\nyou see unnecessary error message (\"You need -f if you really mean\nit\").\n"},{"id":"281761","messageId":"CA+P7+xo1vKNwLt9JazAGZR1=Wu4qe8OsuxTVUYV_TgbUkRBHVA@mail.gmail.com","threadId":"41819","inReplyTo":"xmqqy4975vv7.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFD] minor frustration in 'git add' pathname completion","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-03-25T00:38:10Z","receivedAt":"2016-03-25T00:38:10Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Mar 24, 2016 at 3:55 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>>> If I were to explicitly ignore that file, then even though I know\n>>> whats-cooking.txt is not ignored,\n>>>\n>>> $ git add whats-coo\n>>>\n>>> would not offer anything. I'd be left scratching my head, wondering\n>>> if I mistyped the early part of the filename (e.g. \"wahts-coo\"?).\n>>\n>> Well, git add cannot do anything with either of the files, so why would\n>> it offer to complete to one of them?\n>>\n>> In an ideal world it would tell you whats-cooking.txt doesn't need\n>> adding and whats-cooking.txt+ is ignored locally so excluded from\n>> being added.\n>\n> Exactly my point that you omitted from your quoting ;-)\n>\n> Because the completion cannot give such an explanation, the\n> behaviour gives an unnecessary confusion to the user. If it offered\n> whats-cooking.txt as a candidate, at least the behaviour would make\n> sense to the user. \"Doesn't need adding\" is quite different from\n> \"must not be added\". In other words, \"git add A && git add A\" does\n> not hurt, but \"git add A~\" would because the latter would only makes\n> you see unnecessary error message (\"You need -f if you really mean\n> it\").\n>\n>\n\nI use this feature every day such that I can just do:\n\ngit add \n\nand it cycles through all the available files which differ (thus could\nbe added). If it didn't do (3) then this would tab complete to every\nfile, every time, which is not what I expect it to do. It is\ndefinitely something one has to get used to, but I know I prefer it\nthe way that it is.\n\nFor your case, I think local ignore is the right solution. Narrowing\nthe list is really a useful feature of add's tab completion.\n\nThanks,\nJake\n"}]}