{"thread":{"id":"11125","subject":"git-add--interactive works only in top level","startedAt":"2007-12-04T03:19:32Z","lastAt":"2007-12-04T17:45:13Z","messageCount":9,"participants":["Reid Barton","Junio C Hamano","Wincent Colaiuta","Johannes Schindelin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61863","messageId":"058EB5A2-1EFE-43B9-9886-7272A955CE51@mit.edu","threadId":"11125","inReplyTo":null,"subject":"git-add--interactive works only in top level","fromName":"Reid Barton","fromEmail":"rwbarton@mit.edu","sentAt":"2007-12-04T03:19:32Z","receivedAt":"2007-12-04T03:19:32Z","isPatch":false,"sender":{"key":"rwbarton@mit.edu","avatar":null},"body":"When the working directory is not the top of the working tree, git- \nadd--interactive fails silently and confusingly. In this example, \nthe working tree is rooted at ~/sandbox/foo and ~/sandbox/foo/bar/x \nis a file that's been edited.\n\nrwbarton@homothety:~/sandbox/foo/bar$ git-add--interactive\n staged unstaged path\n 1: unchanged +1/-0 bar/x\n\n*** Commands ***\n 1: status 2: update 3: revert 4: add untracked\n 5: patch 6: diff 7: quit 8: help\nWhat now> 5\n staged unstaged path\n 1: unchanged +1/-0 bar/x\nPatch update> 1\n\n*** Commands ***\n 1: status 2: update 3: revert 4: add untracked\n 5: patch 6: diff 7: quit 8: help\nWhat now>\n\nRather than returning to the main menu, git-add--interactive should \nhave showed me a list of chunks. It seems that the list of files is \nrelative to the working tree root (which is sensible) but when git- \nadd--interactive invokes git-diff-files it does not take this into \naccount. Perhaps git-diff-files should also complain when invoked as\n\ngit-diff-files -- non-existent-file-name\n\nso it wouldn't have taken me half an hour to track this down.\n\nRegards,\nReid Barton\n"},{"id":"61867","messageId":"7vwsrv9fos.fsf@gitster.siamese.dyndns.org","threadId":"11125","inReplyTo":"058EB5A2-1EFE-43B9-9886-7272A955CE51@mit.edu","subject":"Re: git-add--interactive works only in top level","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-04T05:44:51Z","receivedAt":"2007-12-04T05:44:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Reid Barton writes:\n\n> When the working directory is not the top of the working tree, git-\n> add--interactive fails silently and confusingly.\n\nSheesh, you got me worried.\n\nThis is a non issue; git-add--interactive is not for direct end user\nconsumption. It relies on being run from git-add wrapper, which does\ncdup to the top of the work tree before launching add--interactive\nhelper.\n"},{"id":"61869","messageId":"4BC1648E-3059-4373-B388-65AD739796D8@MIT.EDU","threadId":"11125","inReplyTo":"7vwsrv9fos.fsf@gitster.siamese.dyndns.org","subject":"Re: git-add--interactive works only in top level","fromName":"Reid Barton","fromEmail":"rwbarton@mit.edu","sentAt":"2007-12-04T06:07:12Z","receivedAt":"2007-12-04T06:07:12Z","isPatch":false,"sender":{"key":"rwbarton@mit.edu","avatar":null},"body":"On Dec 4, 2007, at 12:44 AM, Junio C Hamano wrote:\n> Sheesh, you got me worried.\n>\n> This is a non issue; git-add--interactive is not for direct end user\n> consumption. It relies on being run from git-add wrapper, which does\n> cdup to the top of the work tree before launching add--interactive\n> helper.\n\nAh, OK. Would it not be easy then to add a check to the beginning of \ngit-add--interactive to verify that it is indeed being run from the \ntop of the work tree? A user may well discover git-add--interactive \nbefore git-add --interactive (e.g. by shell completion) and if git- \nadd--interactive is going to fail, it should do so right away so as \nto not confuse the user.\n\nI understand that programs such as git-add--interactive will be moved \nout of the executable path not too long from now, which will also \nameliorate the situation.\n\nRegards,\nReid Barton\n"},{"id":"61870","messageId":"7vmysr9dxg.fsf@gitster.siamese.dyndns.org","threadId":"11125","inReplyTo":"4BC1648E-3059-4373-B388-65AD739796D8@MIT.EDU","subject":"Re: git-add--interactive works only in top level","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-04T06:22:51Z","receivedAt":"2007-12-04T06:22:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Reid Barton writes:\n\n> I understand that programs such as git-add--interactive will be moved\n> out of the executable path not too long from now, which will also\n> ameliorate the situation.\n\nHonestly, there is nothing to ameliorate. We do not even document\ngit-add--interactive on purpose.\n\nOnce I saw somebody who somehow got a root account on a shared UNIX box\nand tryed running everything he found under /sbin one after another\nwithout understanding what he was doing. Needless to say, the box did\nnot last too long. Somehow that \"tab completion\" comment reminds of\nhim.\n"},{"id":"61897","messageId":"9AADB5DF-15FA-4A5F-BF4B-509135E486B6@wincent.com","threadId":"11125","inReplyTo":"7vmysr9dxg.fsf@gitster.siamese.dyndns.org","subject":"Re: git-add--interactive works only in top level","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-12-04T10:37:28Z","receivedAt":"2007-12-04T10:37:28Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/12/2007, a las 7:22, Junio C Hamano escribió:\n\n> Reid Barton writes:\n>\n>> I understand that programs such as git-add--interactive will be moved\n>> out of the executable path not too long from now, which will also\n>> ameliorate the situation.\n>\n> Honestly, there is nothing to ameliorate. We do not even document\n> git-add--interactive on purpose.\n>\n> Once I saw somebody who somehow got a root account on a shared UNIX \n> box\n> and tryed running everything he found under /sbin one after another\n> without understanding what he was doing. Needless to say, the box did\n> not last too long. Somehow that \"tab completion\" comment reminds of\n> him.\n\nHere he have two options: blame the user for his/her stupidity, or \nlook at this a UI problem and try to make the UI \"idiot proof\".\n\nIn this particular case I see no impediment to favouring the second \noption, because we're not talking about making changes that would make \nGit less powerful or useful for \"non-idiots\", \"power users\" or \"real \nmen\" (whatever you want to call them). In other words, we are not \ntalking about \"dumbing down\" Git for the sake of the ignorant. This is \nan opportunity to polish the UI in the same way that we polish the \ninternal pack format.\n\nAnd while it's not a good idea to login as root and try everything \nunder \"/sbin\" without knowing what it does, stumbling across \"git-add-- \ninteractive\" via tab completion is easier to understand. It's an easy \nenough mistake to make and it would be nice if we shielded the user \nfrom making it.\n\nI think it is (and always was) an error to expose things like git-add-- \ninteractive which are fundamentally implementation details *internal* \nto Git. The user shouldn't even know that it exists. It's one thing to \nhave a bunch of high-level commands (porcelain) mixed together with \nlow-level ones (plumbing) in the user's PATH, but it's another \nentirely to also stick internal implementation stuff which should \n*never* be directly executed in there too. At least in the case of \nplumbing there are reasons why you might sometimes directly execute \nit, but that's not the case with stuff like git-add--interactive.\n\nSo I do think there is something to ameliorate, and moving this stuff \nout of the PATH will do exactly that.\n\nCheers,\nWincent\n"},{"id":"61899","messageId":"Pine.LNX.4.64.0712041148310.27959@racer.site","threadId":"11125","inReplyTo":"9AADB5DF-15FA-4A5F-BF4B-509135E486B6@wincent.com","subject":"Re: git-add--interactive works only in top level","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-04T11:48:57Z","receivedAt":"2007-12-04T11:48:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Dec 2007, Wincent Colaiuta wrote:\n\n> El 4/12/2007, a las 7:22, Junio C Hamano escribi?:\n> \n> > Reid Barton writes:\n> > \n> > > I understand that programs such as git-add--interactive will be \n> > > moved out of the executable path not too long from now, which will \n> > > also ameliorate the situation.\n> > \n> > Honestly, there is nothing to ameliorate. We do not even document \n> > git-add--interactive on purpose.\n> > \n> > Once I saw somebody who somehow got a root account on a shared UNIX \n> > box and tryed running everything he found under /sbin one after \n> > another without understanding what he was doing. Needless to say, the \n> > box did not last too long. Somehow that \"tab completion\" comment \n> > reminds of him.\n> \n> Here he have two options: blame the user for his/her stupidity, or look \n> at this a UI problem and try to make the UI \"idiot proof\".\n> \n> In this particular case I see no impediment to favouring the second \n> option, because we're not talking about making changes that would make \n> Git less powerful or useful for \"non-idiots\", \"power users\" or \"real \n> men\" (whatever you want to call them). In other words, we are not \n> talking about \"dumbing down\" Git for the sake of the ignorant. This is \n> an opportunity to polish the UI in the same way that we polish the \n> internal pack format.\n\nYou know, without patches you will not convince me ;-)\n\nCiao,\nDscho\n"},{"id":"61901","messageId":"404A9328-65CF-479E-A109-0C8B09CA43D5@wincent.com","threadId":"11125","inReplyTo":"Pine.LNX.4.64.0712041148310.27959@racer.site","subject":"Re: git-add--interactive works only in top level","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-12-04T11:56:17Z","receivedAt":"2007-12-04T11:56:17Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/12/2007, a las 12:48, Johannes Schindelin escribió:\n\n> You know, without patches you will not convince me ;-)\n\nA number of patches have already been submitted (by Nguyễn Thái \nNgọc Duy, I believe); you know, the \"Move all dashed form git \ncommands to libexecdir\" thread and its precursors. I was just arguing \nin support of the rationale behind them.\n\nCheers,\nWincent\n"},{"id":"61902","messageId":"m3d4tmveep.fsf@roke.D-201","threadId":"11125","inReplyTo":"404A9328-65CF-479E-A109-0C8B09CA43D5@wincent.com","subject":"Re: git-add--interactive works only in top level","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-04T12:21:35Z","receivedAt":"2007-12-04T12:21:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Wincent Colaiuta writes:\n\n> El 4/12/2007, a las 12:48, Johannes Schindelin escribió:\n> \n> > You know, without patches you will not convince me ;-)\n> \n> A number of patches have already been submitted (by Nguy…n Tha \n> Ngc Duy, I believe); you know, the \"Move all dashed form git \n> commands to libexecdir\" thread and its precursors. I was just arguing \n> in support of the rationale behind them.\n\nI think creating separate libexecdir, and moving there _helpers_ first\n(i.e. command which are neither plumbing, nor porcelain, but are\nmeant to be called _only_ by other commands) would be a good idea,\nperhaps even pre 1.5.4.\n\nBy the way, if (when) dashed form of commands would get moved to\nlibexecdir, the INSTALL fragment below talking about removin wrapper\nscript would have to be changed. But does anyone use GNU Interactive\nTools anymore (IIRC the package name was changed to gitfm or sth.)\n\n\n - git normally installs a helper script wrapper called \"git\", which\n conflicts with a similarly named \"GNU interactive tools\" program.\n\n Tough. Either don't use the wrapper script, or delete the old GNU\n interactive tools. None of the core git stuff needs the wrapper,\n it's just a convenient shorthand and while it is documented in some\n places, you can always replace \"git commit\" with \"git-commit\"\n instead.\n\n But let's face it, most of us don't have GNU interactive tools, and\n even if we had it, we wouldn't know what it does. I don't think it\n has been actively developed since 1997, and people have moved over to\n graphical file managers.\n\n\n-- \nJakub Narebski\n"},{"id":"61928","messageId":"7vd4tm5p7a.fsf@gitster.siamese.dyndns.org","threadId":"11125","inReplyTo":"Pine.LNX.4.64.0712041148310.27959@racer.site","subject":"Re: git-add--interactive works only in top level","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-04T17:45:13Z","receivedAt":"2007-12-04T17:45:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Here he have two options: blame the user for his/her stupidity, or look \n>> at this a UI problem and try to make the UI \"idiot proof\".\n>> \n>> In this particular case I see no impediment to favouring the second \n>> option, because we're not talking about making changes that would make \n>> Git less powerful or useful for \"non-idiots\", \"power users\" or \"real \n>> men\" (whatever you want to call them). In other words, we are not \n>> talking about \"dumbing down\" Git for the sake of the ignorant. This is \n>> an opportunity to polish the UI in the same way that we polish the \n>> internal pack format.\n>\n> You know, without patches you will not convince me ;-)\n\nHonestly, I do not want a patch for that to git-add--interactive.\n\nOnce WIncent's and Dan's UI enhancements to it becomes stable (not\nimplementation-wise but more interface- and user-experience-wise),\nrewriting it in C should not be too much of a hassle. When that\nhappens, it won't be a standalone program but will be a function\nbuiltin-add.c::interactive_add() will call into and we won't have this\nproblem at that point. If somebody does do a patch, the time is better\nspent there instead.\n"}]}