{"thread":{"id":"26424","subject":"\"git add -u\" broken in git 1.7.4?","startedAt":"2011-02-06T00:39:32Z","lastAt":"2011-02-16T09:32:27Z","messageCount":34,"participants":["Sebastian Pipping","Jeff King","Matthieu Moy","SZEDER Gábor","Junio C Hamano","Nguyen Thai Ngoc Duy","Michael J Gruber","Eric Raible","Johannes Sixt","Joshua Juran"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160483","messageId":"4D4DEDC4.4080708@hartwork.org","threadId":"26424","inReplyTo":null,"subject":"\"git add -u\" broken in git 1.7.4?","fromName":"Sebastian Pipping","fromEmail":"webmaster@hartwork.org","sentAt":"2011-02-06T00:39:32Z","receivedAt":"2011-02-06T00:39:32Z","isPatch":false,"sender":{"key":"webmaster@hartwork.org","avatar":null},"body":"Hello!\n\n\nI just ran into case where\n\n git add -u\n\nrepetedly did not update the index. In contrast, picking stuff using\n\n git add -p\n\nworks just fine.\n\nCould it be \"git add -u\" is broken in git 1.7.4?\n\nBest,\n\n\n\nSebastian\n"},{"id":"160488","messageId":"20110206051333.GA3458@sigill.intra.peff.net","threadId":"26424","inReplyTo":"4D4DEDC4.4080708@hartwork.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-06T05:13:33Z","receivedAt":"2011-02-06T05:13:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:\n\n> I just ran into case where\n> \n> git add -u\n> \n> repetedly did not update the index. In contrast, picking stuff using\n> \n> git add -p\n> \n> works just fine.\n> \n> Could it be \"git add -u\" is broken in git 1.7.4?\n\nIt could be. However, I can think of one such case where you might see\nthat behavior. \"git add -u\" operates from the current subdirectory,\nwhereas \"git add -p\" operates from the top of the project tree (yes,\nthis inconsistency confusing, but it's not as serious as \"git add -u\ndoesn't work\").\n\nYou can demonstrate it with:\n\n mkdir repo && cd repo && git init\n mkdir subdir && echo content >file\n git add . && git commit -m base\n echo more >>file\n\n mkdir subdir && cd subdir\n git add -u\n git status ;# still not staged for commit\n\n git add -p ;# finds it\n\nMight you have been in a subdirectory of the project when you saw this\nbehavior?\n\n-Peff\n"},{"id":"160542","messageId":"4D4EF7E4.7050303@hartwork.org","threadId":"26424","inReplyTo":"20110206051333.GA3458@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Sebastian Pipping","fromEmail":"webmaster@hartwork.org","sentAt":"2011-02-06T19:35:00Z","receivedAt":"2011-02-06T19:35:00Z","isPatch":false,"sender":{"key":"webmaster@hartwork.org","avatar":null},"body":"On 02/06/11 06:13, Jeff King wrote:\n> On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:\n> \n>> I just ran into case where\n>>\n>> git add -u\n>>\n>> repetedly did not update the index. In contrast, picking stuff using\n>>\n>> git add -p\n>>\n>> works just fine.\n>>\n>> Could it be \"git add -u\" is broken in git 1.7.4?\n> \n> It could be. However, I can think of one such case where you might see\n> that behavior. \"git add -u\" operates from the current subdirectory,\n> whereas \"git add -p\" operates from the top of the project tree (yes,\n> this inconsistency confusing, but it's not as serious as \"git add -u\n> doesn't work\").\n> \n> You can demonstrate it with:\n> \n> mkdir repo && cd repo && git init\n> mkdir subdir && echo content >file\n> git add . && git commit -m base\n> echo more >>file\n> \n> mkdir subdir && cd subdir\n> git add -u\n> git status ;# still not staged for commit\n> \n> git add -p ;# finds it\n> \n> Might you have been in a subdirectory of the project when you saw this\n> behavior?\n\nI was and I can confirm the different behaviour with 1.7.4 over here: it\ndoes work on the root directory of the repo as you supposed.\n\nIs that behavior needed to be as is or could you change it to work from\neverywhere? Could it be it has been working from anywhere before?\n\nBest,\n\n\n\nSebastian\n"},{"id":"160550","messageId":"vpq1v3kopn3.fsf@bauges.imag.fr","threadId":"26424","inReplyTo":"4D4EF7E4.7050303@hartwork.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-06T20:48:48Z","receivedAt":"2011-02-06T20:48:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sebastian Pipping writes:\n\n> I was and I can confirm the different behaviour with 1.7.4 over here: it\n> does work on the root directory of the repo as you supposed.\n\nWhat do you mean by \"it does not work\"?\n\n\"git add -u\" adds files under the current directory, and it always\ndid.\n\n> Is that behavior needed to be as is or could you change it to work from\n> everywhere?\n\nI consider it as a design bug that \"add -u\" is not tree-wide, but it's\nnot easy to change the existing behavior without breaking expectations\nof people used to the current behavior.\n\n> Could it be it has been working from anywhere before?\n\nCan you post an example where Git 1.7.4 and a previous version behave\ndifferently? Up to now, I see difference between your expectations and\nwhat Git does, but not between new and old versions.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160559","messageId":"20110206231914.GA8147@neumann","threadId":"26424","inReplyTo":"vpq1v3kopn3.fsf@bauges.imag.fr","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-02-06T23:19:14Z","receivedAt":"2011-02-06T23:19:14Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Feb 06, 2011 at 09:48:48PM +0100, Matthieu Moy wrote:\n> Sebastian Pipping writes:\n> > Is that behavior needed to be as is or could you change it to work from\n> > everywhere?\n> \n> I consider it as a design bug that \"add -u\" is not tree-wide, but it's\n> not easy to change the existing behavior without breaking expectations\n> of people used to the current behavior.\n\nAnd others are bitten by it every once in a while. Yes, myself\nincluded ;) Maybe this is also one of those things that might be\nreconsidered for 1.8.0?\n\n> > Could it be it has been working from anywhere before?\n> \n> Can you post an example where Git 1.7.4 and a previous version behave\n> differently? Up to now, I see difference between your expectations and\n> what Git does, but not between new and old versions.\n\ngit add -u was tree-wide when it was introduced in dfdac5d (git-add\n-u: match the index with working tree., 2007-04-20), but 2ed2c22\n(git-add -u paths... now works from subdirectory, 2007-08-16) broke it\nwhile fixing something related.\n\n\nBest,\nGábor\n"},{"id":"160561","messageId":"4D4F33A3.7060002@hartwork.org","threadId":"26424","inReplyTo":"20110206231914.GA8147@neumann","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Sebastian Pipping","fromEmail":"webmaster@hartwork.org","sentAt":"2011-02-06T23:49:55Z","receivedAt":"2011-02-06T23:49:55Z","isPatch":false,"sender":{"key":"webmaster@hartwork.org","avatar":null},"body":"On 02/07/11 00:19, SZEDER Gábor wrote:\n> And others are bitten by it every once in a while. Yes, myself\n> included ;) Maybe this is also one of those things that might be\n> reconsidered for 1.8.0?\n> \n>>> Could it be it has been working from anywhere before?\n>>\n>> Can you post an example where Git 1.7.4 and a previous version behave\n>> differently? Up to now, I see difference between your expectations and\n>> what Git does, but not between new and old versions.\n> \n> git add -u was tree-wide when it was introduced in dfdac5d (git-add\n> -u: match the index with working tree., 2007-04-20), but 2ed2c22\n> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it\n> while fixing something related.\n\nSo my memory didn't fool me. Thanks for digging this out.\n\nCan we have tree-wide \"git add -u\" back, please?\n\nThanks,\n\n\n\nSebastian\n"},{"id":"160578","messageId":"7vwrlcv1ea.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"vpq1v3kopn3.fsf@bauges.imag.fr","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T05:50:37Z","receivedAt":"2011-02-07T05:50:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Sebastian Pipping writes:\n>\n>> I was and I can confirm the different behaviour with 1.7.4 over here: it\n>> does work on the root directory of the repo as you supposed.\n>\n> What do you mean by \"it does not work\"?\n>\n> \"git add -u\" adds files under the current directory, and it always\n> did.\n\nAs it takes pathspecs (think \"git add -u this-file\"), it fundamentally\nshouldn't be tree-wide. I think the original implementation didn't take\npathspecs and was mistakenly done as tree-wide operation, but I think it\nwas fixed rather quickly.\n"},{"id":"160579","messageId":"20110207055314.GA5511@sigill.intra.peff.net","threadId":"26424","inReplyTo":"7vwrlcv1ea.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T05:53:14Z","receivedAt":"2011-02-07T05:53:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:\n\n> Matthieu Moy writes:\n> \n> > Sebastian Pipping writes:\n> >\n> >> I was and I can confirm the different behaviour with 1.7.4 over here: it\n> >> does work on the root directory of the repo as you supposed.\n> >\n> > What do you mean by \"it does not work\"?\n> >\n> > \"git add -u\" adds files under the current directory, and it always\n> > did.\n> \n> As it takes pathspecs (think \"git add -u this-file\"), it fundamentally\n> shouldn't be tree-wide. I think the original implementation didn't take\n> pathspecs and was mistakenly done as tree-wide operation, but I think it\n> was fixed rather quickly.\n\nIs \"git add -p\" broken, then? It takes pathspecs relative to the current\ndirectory, but \"git add -p\" without arguments operates from the root,\nnot from the current subdirectory.\n\n-Peff\n"},{"id":"160583","messageId":"7vhbcguytf.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110207055314.GA5511@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T06:46:20Z","receivedAt":"2011-02-07T06:46:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Is \"git add -p\" broken, then? It takes pathspecs relative to the current\n> directory, but \"git add -p\" without arguments operates from the root,\n> not from the current subdirectory.\n\nI would say so; \"add -p\" was an ill-executed afterthought. The codepath\nwas originally meant to be used from \"-i\" as the top-level interface that\nwas a fully interactive way to prepare for the next commit, which is an\noperation that is inherently full-tree.\n\nThere are two schools of thought in previous threads discussing full-tree\nvs current-directory-relative. I think each side has merits.\n\nIf we defaulted to the current directory (i.e. \"git grep\"), that would\nfeel more natural as it is more consistent with how tools that are not git\naware (e.g. \"GNU grep\" run in the same directory) behave. A downside is\nwhen you are somewhere deep in a working tree, you have to know how deep\nyou are and repeat \"../\" that many times, i.e. \"git grep pattern ../../\"\n\nIf we defaulted to the root-level (i.e. \"git diff\"), you do not have that\ndownside (iow, \"git diff\" run from a deep directory is a full tree\noperation), and you can limit the scope to the current directory by a\nsingle dot, i.e. \"git diff .\". A huge downside is that this may feel\nawkward for new people who do not yet breath git [*1*], as no other git\naware tool would behave like this, limiting its scope to some directory\nthat is higher above.\n\nIn the past, I have took the third position, saying that tools that\nsemantically needs to be full-tree should be full-tree (i.e. ones that\nmake or format commits), and others should be relative to the current\ndirectory (i.e. ones that are used to inspect your progress, such as\ngrep), but that is not a very understandable guideline that people can\neasily follow. If we have to choose between the two and make things\nconsistent, my personal preference is to make everything relative to the\ncurrent working directory.\n\nI actually do not mind too much myself if all commands that can take\npathspecs consistently defaulted to \"full-tree\" pathspec given no\npathspec. But if we were to go that route, everybody should join their\nvoice to defend that decision when outside people say \"in 1.8.0 'git grep'\nrun from a subdirectory shows matches from all the irrelevant parts of the\ntree; with all the cruft its output is unreadable\". I won't be the sole\nchampion of such a behaviour when I do not fully believe in it.\n\n\n[Footnote]\n\n*1* In the case of \"git diff\", this is largely mitigated as its output is\nalways relative to the root of the working tree, but other tools may not\nhave that luxury.\n"},{"id":"160584","messageId":"vpqbp2ojq5x.fsf@bauges.imag.fr","threadId":"26424","inReplyTo":"20110207055314.GA5511@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-07T06:48:42Z","receivedAt":"2011-02-07T06:48:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:\n>\n>> As it takes pathspecs (think \"git add -u this-file\"), it fundamentally\n>> shouldn't be tree-wide. I think the original implementation didn't take\n>> pathspecs and was mistakenly done as tree-wide operation, but I think it\n>> was fixed rather quickly.\n>\n> Is \"git add -p\" broken, then? It takes pathspecs relative to the current\n> directory, but \"git add -p\" without arguments operates from the root,\n> not from the current subdirectory.\n\nIt's not just \"git add -p\". Take \"git log\", \"git status\", \"git\ncommit\", \"git diff\" ... well, most Git commands taking pathspecs\noptionally:\n\ngit foo => tree-wide\ngit foo . => the . acts as a path limiter\n\nand this is the right thing to do. Making \"git foo\" equivalent to \"git\nfoo .\" makes it hard to recover the tree-wide behavior from a\nsubdirectory (git foo ../../../).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160586","messageId":"AANLkTiksXERJ1h2du7Qu27rpKh2=q0GTWix8kSoeC24Y@mail.gmail.com","threadId":"26424","inReplyTo":"7vhbcguytf.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-07T07:29:23Z","receivedAt":"2011-02-07T07:29:23Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 7, 2011 at 1:46 PM, Junio C Hamano wrote:\n> I actually do not mind too much myself if all commands that can take\n> pathspecs consistently defaulted to \"full-tree\" pathspec given no\n> pathspec.  But if we were to go that route, everybody should join their\n> voice to defend that decision when outside people say \"in 1.8.0 'git grep'\n> run from a subdirectory shows matches from all the irrelevant parts of the\n> tree; with all the cruft its output is unreadable\". I won't be the sole\n> champion of such a behaviour when I do not fully believe in it.\n\nThat could be one more item for the next git survey (i.e. how do you\nwant the defaults to be?). Most of people in this list more or less\nbreath git already and therefore are bias (I think).\n\nPersonally \"git add -u --full-tree\" is good enough to me. It does have\nthe same problem that git --full-tree has: what *.h in \"git grep\n--full-tree -- '*.h'\" means. But I'm OK with not supporting that case\nuntil we agree on something.\n-- \nDuy\n"},{"id":"160588","messageId":"4D4FACE2.4060206@drmicha.warpmail.net","threadId":"26424","inReplyTo":"vpqbp2ojq5x.fsf@bauges.imag.fr","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-07T08:27:14Z","receivedAt":"2011-02-07T08:27:14Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Matthieu Moy venit, vidit, dixit 07.02.2011 07:48:\n> Jeff King writes:\n> \n>> On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:\n>>\n>>> As it takes pathspecs (think \"git add -u this-file\"), it fundamentally\n>>> shouldn't be tree-wide. I think the original implementation didn't take\n>>> pathspecs and was mistakenly done as tree-wide operation, but I think it\n>>> was fixed rather quickly.\n>>\n>> Is \"git add -p\" broken, then? It takes pathspecs relative to the current\n>> directory, but \"git add -p\" without arguments operates from the root,\n>> not from the current subdirectory.\n> \n> It's not just \"git add -p\". Take \"git log\", \"git status\", \"git\n> commit\", \"git diff\" ... well, most Git commands taking pathspecs\n> optionally:\n> \n> git foo => tree-wide\n> git foo . => the . acts as a path limiter\n> \n> and this is the right thing to do. Making \"git foo\" equivalent to \"git\n> foo .\" makes it hard to recover the tree-wide behavior from a\n> subdirectory (git foo ../../../).\n> \n\nFirst of all, I'd vote for having this work the same way across all\ncommands - as Junio explained, the destinction we currently have is not\neasy to grasp, and is violated by add -p.\n\nSecond, we have an established, natural syntax for \"base on cwd\", namely\n\".\", but we do not have any for \"base on worktree root\". (I think we\ndiscussed and discarded \"/\" at some point.)\n\nSo, if we go for \"relative to cwd by default\" we would need a simple way\nto specify the root - and by simple I mean taking at most 2 chars in the\npathspec, not a long option!\n\nIn summary, I think going for \"relative to worktree root by default\" is\nmore in line with git's overall philosophy (so it teaches the right\nconcept), something the user is exposed to already in most places (but\nnot all), and limiting to \".\" already works in most (all?) places, even\nwith \"status\" and \"status -s\". We would only need to change the few\nplaces where we still default to cwd, and make sure they accept \".\" when\nwe change their default to repo root.\n\nCheers,\nMichael\n"},{"id":"160599","messageId":"20110207111505.GA10281@neumann","threadId":"26424","inReplyTo":"7vwrlcv1ea.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-02-07T11:15:06Z","receivedAt":"2011-02-07T11:15:06Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n> > Sebastian Pipping writes:\n> >\n> >> I was and I can confirm the different behaviour with 1.7.4 over here: it\n> >> does work on the root directory of the repo as you supposed.\n> >\n> > What do you mean by \"it does not work\"?\n> >\n> > \"git add -u\" adds files under the current directory, and it always\n> > did.\n> \n> As it takes pathspecs (think \"git add -u this-file\"), it fundamentally\n> shouldn't be tree-wide. I think the original implementation didn't take\n> pathspecs and was mistakenly done as tree-wide operation, but I think it\n> was fixed rather quickly.\n\nInteresting, when I brought up this issue about one and a half years\nago, you of all people proposed that this change might be worth\naddressing in 1.8.0.\n\n Message-ID: <7veiql1etz.fsf@alter.siamese.dyndns.org>\n http://thread.gmane.org/gmane.comp.version-control.git/127593/focus=127594\n\nThere was a longish discussion back then with arguments both for and\nagainst tree-wide operation.\n\n\nBest,\nGábor\n"},{"id":"160613","messageId":"20110207183412.GB1900@neumann","threadId":"26424","inReplyTo":"7vhbcguytf.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-02-07T18:34:12Z","receivedAt":"2011-02-07T18:34:12Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > Is \"git add -p\" broken, then? It takes pathspecs relative to the current\n> > directory, but \"git add -p\" without arguments operates from the root,\n> > not from the current subdirectory.\n> \n> I would say so; \"add -p\" was an ill-executed afterthought. The codepath\n> was originally meant to be used from \"-i\" as the top-level interface that\n> was a fully interactive way to prepare for the next commit, which is an\n> operation that is inherently full-tree.\n> \n> There are two schools of thought in previous threads discussing full-tree\n> vs current-directory-relative. I think each side has merits.\n> \n> If we defaulted to the current directory (i.e. \"git grep\"), that would\n> feel more natural as it is more consistent with how tools that are not git\n> aware (e.g. \"GNU grep\" run in the same directory) behave. A downside is\n> when you are somewhere deep in a working tree, you have to know how deep\n> you are and repeat \"../\" that many times, i.e. \"git grep pattern ../../\"\n> \n> If we defaulted to the root-level (i.e. \"git diff\"), you do not have that\n> downside (iow, \"git diff\" run from a deep directory is a full tree\n> operation), and you can limit the scope to the current directory by a\n> single dot, i.e. \"git diff .\". A huge downside is that this may feel\n> awkward for new people who do not yet breath git [*1*], as no other git\n> aware tool would behave like this, limiting its scope to some directory\n> that is higher above.\n> \n> In the past, I have took the third position, saying that tools that\n> semantically needs to be full-tree should be full-tree (i.e. ones that\n> make or format commits), and others should be relative to the current\n> directory (i.e. ones that are used to inspect your progress, such as\n> grep), but that is not a very understandable guideline that people can\n> easily follow. If we have to choose between the two and make things\n> consistent, my personal preference is to make everything relative to the\n> current working directory.\n\n_Everything_ relative to the current working directory? I can't\nimagine how would that work in practice. Could you explain what would\nthe following commands do, for example, when they are relative to the\ncurrent working directory?\n\n $ cd t\n $ git checkout next\n $ git merge somebranch\n $ git reset HEAD^\n\n\nBest,\nGábor\n"},{"id":"160621","messageId":"7vaai7vdys.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110207183412.GB1900@neumann","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T19:31:23Z","receivedAt":"2011-02-07T19:31:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> _Everything_ relative to the current working directory? I can't\n> imagine how would that work in practice. Could you explain what would\n> the following commands do, for example, when they are relative to the\n> current working directory?\n>\n> $ cd t\n> $ git checkout next\n> $ git merge somebranch\n> $ git reset HEAD^\n\nPerhaps I stated things badly. I was only talking about commands that\ntake pathspecs, and none of the above are relevant to this thread. You\ndon't check out a branch with pathspec, nor merge another branch, nor\nreset the index and the HEAD pointer.\n\nI wouldn't point out that \"git checkout next -- this-file\" is to check out\na file out of a commit, not to check out a branch, as I think you already\nknow that.\n"},{"id":"160622","messageId":"20110207195035.GA13461@sigill.intra.peff.net","threadId":"26424","inReplyTo":"7vhbcguytf.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T19:50:35Z","receivedAt":"2011-02-07T19:50:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:\n\n> I actually do not mind too much myself if all commands that can take\n> pathspecs consistently defaulted to \"full-tree\" pathspec given no\n> pathspec. But if we were to go that route, everybody should join their\n> voice to defend that decision when outside people say \"in 1.8.0 'git grep'\n> run from a subdirectory shows matches from all the irrelevant parts of the\n> tree; with all the cruft its output is unreadable\". I won't be the sole\n> champion of such a behaviour when I do not fully believe in it.\n\nThe problem is that I don't feel comfortable writing an RFC that says\n\"in 1.8.0 we will default to full-tree because it is somehow better\".\nBecause I don't think it is better; it is simply a different way of\nthinking about it, and different people will have different preferences.\n\nI think even the same people may different preferences from project to\nproject. For most of my projects, the scope of the repo is well-defined,\nand I want full-tree semantics (e.g., I hack on a bug, go into t/ to\ntweak and run the tests, and then want to \"git add -u\" the whole thing\nwhen everything looks good). But I also recently worked on a gigantic\nproject that was split into several sub-components. I would cd 3 or 4\nlevels deep into the sub-component that I was working on, and I would\nprefer my \"git add -u\" to stay in that sub-component, and my \"git grep\"\nto look only in that sub-component.\n\nWhich implies to me that the \"relative\" or \"full-tree\" view should be a\nper-repo configurable thing. But that introduces its own set of\nheadaches, as people may script around things like \"git add\", and it\nwould become predictable to do so only from the top-level of the working\ntree.\n\n-Peff\n"},{"id":"160637","messageId":"vpqtygfa7g8.fsf@bauges.imag.fr","threadId":"26424","inReplyTo":"7vhbcguytf.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-07T20:57:43Z","receivedAt":"2011-02-07T20:57:43Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I would say so; \"add -p\" was an ill-executed afterthought. The codepath\n> was originally meant to be used from \"-i\" as the top-level interface that\n> was a fully interactive way to prepare for the next commit, which is an\n> operation that is inherently full-tree.\n\nI agree that \"git add -i\" is a way to prepare the next commit, but you\nseem to imply that \"git add -u\" is not and then I have to disagree.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160639","messageId":"20110207210257.GA14963@sigill.intra.peff.net","threadId":"26424","inReplyTo":"vpqtygfa7g8.fsf@bauges.imag.fr","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-07T21:02:57Z","receivedAt":"2011-02-07T21:02:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 07, 2011 at 09:57:43PM +0100, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > I would say so; \"add -p\" was an ill-executed afterthought. The codepath\n> > was originally meant to be used from \"-i\" as the top-level interface that\n> > was a fully interactive way to prepare for the next commit, which is an\n> > operation that is inherently full-tree.\n> \n> I agree that \"git add -i\" is a way to prepare the next commit, but you\n> seem to imply that \"git add -u\" is not and then I have to disagree.\n\nHow about \"git commit -a\"? Shouldn't that be more or less equivalent to\n\"git add -u && git commit\"? But it is full-tree.\n\nSo I think there is less \"we do it one way, and this is the outlier\" and\nmore \"we are horribly inconsistent\".\n\n-Peff\n"},{"id":"160648","messageId":"7voc6ntt0i.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110207210257.GA14963@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T21:49:17Z","receivedAt":"2011-02-07T21:49:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So I think there is less \"we do it one way, and this is the outlier\" and\n> more \"we are horribly inconsistent\".\n\nYeah, didn't I say I used to be the third camp which I find is hard to\njusitify, and am open to consistency either way?\n"},{"id":"160673","messageId":"4D509B8B.6090607@nextest.com","threadId":"26424","inReplyTo":"7vhbcguytf.fsf@alter.siamese.dyndns.org","subject":"Re: Re: \"git add -u\" broken in git 1.7.4?","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-02-08T01:25:31Z","receivedAt":"2011-02-08T01:25:31Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11:59 AM, Junio C Hamano wrote:\n\n> I actually do not mind too much myself if all commands that can take\n> pathspecs consistently defaulted to \"full-tree\" pathspec given no\n> pathspec. But if we were to go that route, everybody should join their\n> voice to defend that decision when outside people say \"in 1.8.0 'git grep'\n> run from a subdirectory shows matches from all the irrelevant parts of the\n> tree; with all the cruft its output is unreadable\". I won't be the sole\n> champion of such a behaviour when I do not fully believe in it.\n\nIFUC this shouldn't affect any (correctly written) scripts,\nand so the only downside is that (when run in a subdir) commands\nthat are currently spelled:\n\n\tgit xxx\n\nwould with this change need to be spelled:\n\n\tgit xxx .\n\nOne advantage of this approach is that one's fingers would\nlearn the \"only this dir\" two char sequence very quickly.\n\nSo FWIW, I will do my best to help defend such a decision.\n"},{"id":"160674","messageId":"7vwrlbqnhh.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"4D509B8B.6090607@nextest.com","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-08T02:16:58Z","receivedAt":"2011-02-08T02:16:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Raible writes:\n\n> IFUC this shouldn't affect any (correctly written) scripts,\n> and so the only downside is that (when run in a subdir) commands\n> that are currently spelled:\n>\n> \tgit xxx\n>\n> would with this change need to be spelled:\n>\n> \tgit xxx .\n\nIf xxx is grep (or \"add -u\") and the script is running the former form,\nyou already broke it, and I think a script that expects \"git grep\" to\nlimit its scope to the current directory is \"correctly written\". That is\nhow these commands were defined and documented to work.\n\n\"Adding SP plus dot is just a two-byte change\" is not a sensible reason to\nbreak people's scripts. We need to be honest and say \"sorry, but with\nthis release we are breaking your scripts. Let us convince you that the\nbenefit of the resulting consistency outweighs that cost\".\n"},{"id":"160688","messageId":"20110208100518.GA9505@neumann","threadId":"26424","inReplyTo":"20110207195035.GA13461@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-02-08T10:05:18Z","receivedAt":"2011-02-08T10:05:18Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Feb 07, 2011 at 02:50:35PM -0500, Jeff King wrote:\n> On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:\n> \n> > I actually do not mind too much myself if all commands that can take\n> > pathspecs consistently defaulted to \"full-tree\" pathspec given no\n> > pathspec. But if we were to go that route, everybody should join their\n> > voice to defend that decision when outside people say \"in 1.8.0 'git grep'\n> > run from a subdirectory shows matches from all the irrelevant parts of the\n> > tree; with all the cruft its output is unreadable\". I won't be the sole\n> > champion of such a behaviour when I do not fully believe in it.\n> \n> The problem is that I don't feel comfortable writing an RFC that says\n> \"in 1.8.0 we will default to full-tree because it is somehow better\".\n> Because I don't think it is better; it is simply a different way of\n> thinking about it, and different people will have different preferences.\n> \n> I think even the same people may different preferences from project to\n> project. For most of my projects, the scope of the repo is well-defined,\n> and I want full-tree semantics (e.g., I hack on a bug, go into t/ to\n> tweak and run the tests, and then want to \"git add -u\" the whole thing\n> when everything looks good). But I also recently worked on a gigantic\n> project that was split into several sub-components. I would cd 3 or 4\n> levels deep into the sub-component that I was working on, and I would\n> prefer my \"git add -u\" to stay in that sub-component, and my \"git grep\"\n> to look only in that sub-component.\n\nIt sounds like your work focused solely on the sub-component you cd-d\ninto. Did you have any other changes outside of that sub-component?\nBecause when not, then both the current and the whole-tree \"git add -u\"\nwould have the same effect.\n\nThe current and the whole-tree \"git grep\" would behave differently, of\ncourse. But even then a whole-tree \"git grep\" would be harmless and\neasy to limit in scope, though might be a bit annoying in the \"cd deep\ndown\" case. In that case you would immediately see the matches\noutside of cwd, know that you forgot to limit the operation to cwd, so\nyou hit the up key, simply append the \".\" to the last command, and you\nget what you wanted.\n\nAs mentioned in this or other related threads, this is not at all that\nsimple the other way around, i.e. with current \"git grep\" when you are\nin the sub-component and you happen to need a grep on the whole tree,\nbecause you have to pay attention to use the right number of \"../\"s.\n\nA whole-tree \"git add -u\" is just as easy to limit in scope as the\nwhole-tree \"git grep\" would be, but certainly more annoying when you\nforget to limit it to cwd. But even in that case there is no harm\ndone, because all the changes you've made are there, but you have to\nunstage changes from the index or split the commit.\n\nCurrent \"git add -u\" is worst of all, because it's not just difficult\nto circumvent (how many \"../\" do I need?), but it's downright\ndangerous, because you can lose changes when forget that it's limited\nin scope. I managed to do something like this while fixing two\nalready bisected bugs:\n\n git checkout deadbeef # BugA was introduced in that commit\n vim git.c # fix BugA\n cd t\n test ; vim test ; test\n git add -u # again forgetting that a\n # fundamentally whole-tree oriented \n # tool has operations with\n # non-whole-tree defaults...\n git commit -m 'Fix BugA' # will write proper commit msg later\n git branch fix_BugA # to find the commit later\n git reset --hard babefeed # instead of \"git checkout babefeed\"\n # BugB was introduced there\n # goodbye bugfix!\n # hack away to fix BugB # until realisation sets in\n # Damn.\n\nYou could argue that there are several ways I could have prevented\nshooting myself in the foot, e.g. using \"git checkout\" instead of \"git\nreset --hard\", or by using plain \"git commit\" without the \"-m\" option\nI might have noticed the unstaged changes in the commit template. I\nwould even tend to agree, but I still think that git should be\nconsistent with _itself_ in the first place, and since git's\nfundamental concepts are whole-tree oriented and there are many\ncommands that only make sense on the whole tree, defaulting to\nwhole-tree operations for commands taking a pathspec is indeed better.\nAnd safer too.\n\n\nBest,\nGábor\n"},{"id":"160784","messageId":"20110209210312.GB2083@sigill.intra.peff.net","threadId":"26424","inReplyTo":"20110208100518.GA9505@neumann","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-09T21:03:12Z","receivedAt":"2011-02-09T21:03:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 08, 2011 at 11:05:18AM +0100, SZEDER Gábor wrote:\n\n> > I think even the same people may different preferences from project to\n> > project. For most of my projects, the scope of the repo is well-defined,\n> > and I want full-tree semantics (e.g., I hack on a bug, go into t/ to\n> > tweak and run the tests, and then want to \"git add -u\" the whole thing\n> > when everything looks good). But I also recently worked on a gigantic\n> > project that was split into several sub-components. I would cd 3 or 4\n> > levels deep into the sub-component that I was working on, and I would\n> > prefer my \"git add -u\" to stay in that sub-component, and my \"git grep\"\n> > to look only in that sub-component.\n> \n> It sounds like your work focused solely on the sub-component you cd-d\n> into. Did you have any other changes outside of that sub-component?\n> Because when not, then both the current and the whole-tree \"git add -u\"\n> would have the same effect.\n\nYes, I often did have other changes. They were usually one of two types.\nThe build infrastructure was in a separate directory, so one type would\nbe local tweaks to the build that should not end up getting committed.\nThe other type was required changes to another component that would get\ncommitted separately (e.g., while working on component \"foo\" you realize\nthat it depends on a new feature in component \"bar\"; you leave \"foo\"\nmodified in the working tree, work on \"bar\", commit it, then come back\nto \"foo\").\n\n> The current and the whole-tree \"git grep\" would behave differently, of\n> course. But even then a whole-tree \"git grep\" would be harmless and\n> easy to limit in scope, though might be a bit annoying in the \"cd deep\n> down\" case. In that case you would immediately see the matches\n> outside of cwd, know that you forgot to limit the operation to cwd, so\n> you hit the up key, simply append the \".\" to the last command, and you\n> get what you wanted.\n\nYeah, grep is not as annoying because it does not have the \"oops, I just\npushed this commit and it turns out that I screwed up \"git add\" five\nminutes ago and it only had half of the files I intended\" problem.\n\n> As mentioned in this or other related threads, this is not at all that\n> simple the other way around, i.e. with current \"git grep\" when you are\n> in the sub-component and you happen to need a grep on the whole tree,\n> because you have to pay attention to use the right number of \"../\"s.\n\nYes, it is annoying, but that is merely a syntactic issue. If we aliased\n\"/\" to \"the root of the project\", then most arguments for full-tree\ncould be reversed for the relative case (e.g., \"sure, but it's easy\nenough to type 'git add /'\").\n\nFor the record, I would much prefer full-tree behavior as the default,\nand I think the '/' syntax is ugly and confusing. If you were asking at\nthe beginning of \"git add -u\" what the behavior should be, I would\nabsolutely say full-tree. But we're not there; we're talking about\nchanging existing behavior. And I'm not sure there is a clear-cut,\nobvious-to-anybody-who-will-annoyed-with-the-change argument that\nfull-tree behavior is definitively better.\n\nThe most compelling I have seen is \"you tend to notice accidental\nfull-tree sooner than accidental relative behavior\". Which you mentioned\nin your email. I just don't know if that passes the \"will satisfy\nannoyed users\" test.\n\nI dunno. I would not be sad at all if we moved to full-tree defaults\neverywhere. I just don't want to have to be the one that annoyed users\nyell at. :)\n\n-Peff\n"},{"id":"160791","messageId":"7vipwsomq8.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110209210312.GB2083@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-09T22:40:47Z","receivedAt":"2011-02-09T22:40:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The most compelling I have seen is \"you tend to notice accidental\n> full-tree sooner than accidental relative behavior\". Which you mentioned\n> in your email.\n\nHmph. You earlier mentioned \"oops, I just pushed this commit and it turns\nout that I screwed up \"git add\" five minutes ago and it only had half of\nthe files I intended\" problem, but \"oops, I just pushed this commit and it\nturns out that I screwed up \"git add\" five minutes ago and it had more\nchanges than I intended\" problem would be equally annoying, and I don't\nthink one is inherently more likely to be noticed than the other; IOW, it\nis not compelling, but is just an arbitrary and a biased observation, no?\n\nThe most compelling, especially if we _were_ designing from scratch to\nmake things consistent across the command set, would be \"limiting to cwd\nwith single dot is a lot easier to type than counting ../, using / to mean\nthe root of the working tree is confusing, and saying --full-tree is\nannoying\". I fully agree with that.\n\nCan somebody volunteer to come up with a comprehensive list of operations\nthat will change their behaviour when we switch to \"full-tree without\npathspec\" semantics? We mentioned \"grep\" and \"add -u\" already.\n"},{"id":"160798","messageId":"20110209234621.GA12575@sigill.intra.peff.net","threadId":"26424","inReplyTo":"7vipwsomq8.fsf@alter.siamese.dyndns.org","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-09T23:46:21Z","receivedAt":"2011-02-09T23:46:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 09, 2011 at 02:40:47PM -0800, Junio C Hamano wrote:\n\n> > The most compelling I have seen is \"you tend to notice accidental\n> > full-tree sooner than accidental relative behavior\". Which you mentioned\n> > in your email.\n> \n> Hmph. You earlier mentioned \"oops, I just pushed this commit and it turns\n> out that I screwed up \"git add\" five minutes ago and it only had half of\n> the files I intended\" problem, but \"oops, I just pushed this commit and it\n> turns out that I screwed up \"git add\" five minutes ago and it had more\n> changes than I intended\" problem would be equally annoying, and I don't\n> think one is inherently more likely to be noticed than the other; IOW, it\n> is not compelling, but is just an arbitrary and a biased observation, no?\n\nYeah, thinking on it more, it is not so much that you notice sooner[1],\nas the behavior may be less destructive when you do notice. That is,\naccidentally adding too much has put things into the object db.\nAccidentally not adding enough means your changes are susceptible to\n\"git reset --hard\" or other destructive actions.\n\n[1] I seem to remember this argument about noticing sooner coming up in\nprevious discussions, and so I was taking it for granted. But thinking\non it, I can't really come up with a solid reason why one might notice\nerrors sooner in full tree rather than relative behavior.\n\n> Can somebody volunteer to come up with a comprehensive list of operations\n> that will change their behaviour when we switch to \"full-tree without\n> pathspec\" semantics? We mentioned \"grep\" and \"add -u\" already.\n\nI went through the whole list of \"git help -a\" and considered each\ncommand. Quite a few don't take pathspecs, or would be very odd to be\nnot full-tree (e.g., read-tree reads the whole tree, not just some\nsubset based on where you are in the project. Anything else would be\nkind of insane). I omitted those. If you don't see something in this\nlist, it's either because I thought it was irrelevant, or I just missed\nit going through the list; feel free to mention more.\n\nI think everything which takes a pathspec takes it relative to the\ncurrent directory. So we are really just considering the behavior when\n_no_ pathspecs are provided.\n\nThe current behavior is:\n\n add: error (and suggest \"git add .\")\n add -u: relative\n add -A: relative\n add -i: full-tree\n add -p: full-tree\n archive: relative\n checkout: full-tree (e.g., \"git checkout -f\")[1]\n checkout-index: n/a (only checks out arguments)\n clean: relative\n commit -a: full-tree[2]\n diff: full-tree\n diff-files: full-tree\n grep: relative\n ls-files: relative\n ls-tree: relative[3]\n status: shows full-tree, relative by default, absolute\n with status.relativePaths\n reset --hard: full-tree[4]\n log/show/etc: full-tree[5]\n blame: error[6]\n\nNotes:\n\n[1] checkout being full-tree without pathspecs is mostly due to \"git\n checkout\" meaning \"switch to this branch\" and not \"checkout some part of\n the index\". So naturally it is a full-tree operation.\n\n[2] The inconsistency in \"git commit -a\" versus \"git add -u\" is to me\n one of the worst, as I think it is a useful mental model to think of\n \"commit -a\" as \"add -u; commit\".\n\n[3] I can understand ls-files being relative, though I don't agree with\n it. But ls-tree looking at a relative subset of the tree is just\n insane (you were the one who pointed this out to me last time this\n subject came up, too).\n\n[4] I think reset --hard is just a tree operation, since it is \"set HEAD\n to this ref, check it out into the index, _and_ reset the worktree\n to match\". So obviously it should be full-tree. But I think a common\n mental model, especially when resetting to HEAD implicitly, is that\n it is about \"reset my working tree to the HEAD state\". So I included\n it in this list.\n\n[5] Revision traversal is not about the worktree at all, so it has\n always been about the full project. I don't think there's any\n argument there, but I put it in the list as a contrast to ls-tree,\n to which the same argument should apply.\n\n[6] Blame obviously does nothing without a path right now. In theory it\n could eventually grow whole-directory blame. In that case, I would\n expect it to be full-tree (and \"git blame .\" would do what you\n want).\n\nAssuming we move from relative to full-tree, I think the possible things\nto move are:\n\n add -u/-A\n archive\n grep\n clean\n ls-files/ls-tree\n\nI don't think it's worth moving ls-files/ls-tree. They're plumbing that\npeople don't use frequently. So the cost of moving them is high (because\nwe are breaking something meant to be scriptable) and the benefit is low\n(because users don't type them a lot).\n\nObviously add and grep are the two that people have talked about. The\narchive behavior surprised me, and I would think it should be full-tree\nby default. But it is sort of plumbing-ish, in that people have probably\nscripted around and people _don't_ tend to create archives a lot. So it\nmay fall into the same category as ls-files/ls-tree.\n\nThat leaves clean. I would say from a consistency standpoint that it\nshould go full-tree to match the other commands. But it is one of the\nmost destructive commands, and making it full-tree makes it easier to\naccidentally delete, instead of accidentally fail to delete. So that\nmakes me hesitate to switch it to full-tree behavior (though a \"clean\nreflog\" would be a pretty cool feature in general).\n\nSo depending on your view of the above, it may just be \"add -u/-A\" and\n\"grep\" that are worth switching.\n\n-Peff\n"},{"id":"160805","messageId":"AANLkTi=dmqRQqBD2HZfv2x-kxaqrxvSx3r62d09KMP1k@mail.gmail.com","threadId":"26424","inReplyTo":"20110209234621.GA12575@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-10T02:24:55Z","receivedAt":"2011-02-10T02:24:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 10, 2011 at 6:46 AM, Jeff King wrote:\n> Assuming we move from relative to full-tree, I think the possible things\n> to move are:\n>\n>  add -u/-A\n>  archive\n>  grep\n>  clean\n>  ls-files/ls-tree\n>\n> I don't think it's worth moving ls-files/ls-tree. They're plumbing that\n> people don't use frequently. So the cost of moving them is high (because\n> we are breaking something meant to be scriptable) and the benefit is low\n> (because users don't type them a lot).\n\nNo we should not, but we should add --full-tree to\nls-files/ls-tree/archive. I'd love \"ls-files --full-tree\n'*somefile*'\".\n-- \nDuy\n"},{"id":"160808","messageId":"20110210023132.GB5073@sigill.intra.peff.net","threadId":"26424","inReplyTo":"AANLkTi=dmqRQqBD2HZfv2x-kxaqrxvSx3r62d09KMP1k@mail.gmail.com","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-10T02:31:32Z","receivedAt":"2011-02-10T02:31:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 10, 2011 at 09:24:55AM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> > I don't think it's worth moving ls-files/ls-tree. They're plumbing that\n> > people don't use frequently. So the cost of moving them is high (because\n> > we are breaking something meant to be scriptable) and the benefit is low\n> > (because users don't type them a lot).\n> \n> No we should not, but we should add --full-tree to\n> ls-files/ls-tree/archive. I'd love \"ls-files --full-tree\n> '*somefile*'\".\n\nls-tree already has --full-tree (and --full-name, which just gives full\npathnames but still restricts output to files in the current directory).\nls-files. ls-files has --full-name, but AFAIK needs a matching\n--full-tree.\n\n-Peff\n"},{"id":"160811","messageId":"7vd3n061yp.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110210023132.GB5073@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-10T02:46:38Z","receivedAt":"2011-02-10T02:46:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ls-tree already has --full-tree (and --full-name, which just gives full\n> pathnames but still restricts output to files in the current directory).\n> ls-files. ls-files has --full-name, but AFAIK needs a matching\n> --full-tree.\n\n... and --no-full-tree, if we were to make the default tweakable from the\nconfiguration mechanism for Porcelain commands. The convoluted logic\nwould go like this:\n\n 1. 'git clean' can be made default to the full-tree operation by\n setting \"porcelain.fullTreeOnNoPathspec = yes\";\n\n 2. a script may want to defeat random configuration the user may have and\n 'git clean --full-tree' and 'git clean --no-full-tree' are the ways to\n force the semantics it wants;\n\n 3. 'git ls-files' will keep the default of cwd-relativeness, but will gain\n 'git ls-files --full-tree'; naturally people expect --no-full-tree to\n work, even though the command will not be affected by the configuration\n variable porcelain.fullTreeOnNoPathspec.\n"},{"id":"160816","messageId":"4D5397DB.3060609@viscovery.net","threadId":"26424","inReplyTo":"20110209234621.GA12575@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-02-10T07:46:35Z","receivedAt":"2011-02-10T07:46:35Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 2/10/2011 0:46, schrieb Jeff King:\n> The current behavior is:\n> \n> add: error (and suggest \"git add .\")\n> add -u: relative\n> add -A: relative\n> add -i: full-tree\n> add -p: full-tree\n> archive: relative\n> checkout: full-tree (e.g., \"git checkout -f\")[1]\n> checkout-index: n/a (only checks out arguments)\n> clean: relative\n> commit -a: full-tree[2]\n> diff: full-tree\n> diff-files: full-tree\n> grep: relative\n> ls-files: relative\n> ls-tree: relative[3]\n> status: shows full-tree, relative by default, absolute\n> with status.relativePaths\n> reset --hard: full-tree[4]\n> log/show/etc: full-tree[5]\n> blame: error[6]\n\n rerere forget: relative\n\nIt is a destructive command, and the rerere cache is precious, IMO.\nTherefore, I'd vote to make 'git rerere forget' without a pathspec an error.\n\n-- Hannes\n"},{"id":"160817","messageId":"5C96089F-7CEF-44EB-98ED-C5FB9F641180@gmail.com","threadId":"26424","inReplyTo":"20110209234621.GA12575@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Joshua Juran","fromEmail":"jjuran@gmail.com","sentAt":"2011-02-10T08:13:13Z","receivedAt":"2011-02-10T08:13:13Z","isPatch":false,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On Feb 9, 2011, at 3:46 PM, Jeff King wrote:\n\n> The current behavior is:\n>\n> add: error (and suggest \"git add .\")\n> add -u: relative\n> add -A: relative\n> add -i: full-tree\n> add -p: full-tree\n\nadd -e: full-tree\n\nJosh\n"},{"id":"160829","messageId":"vpqpqqzahwv.fsf@bauges.imag.fr","threadId":"26424","inReplyTo":"20110209234621.GA12575@sigill.intra.peff.net","subject":"Re: \"git add -u\" broken in git 1.7.4?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-10T18:00:48Z","receivedAt":"2011-02-10T18:00:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> I don't think it's worth moving ls-files/ls-tree. They're plumbing that\n> people don't use frequently. So the cost of moving them is high (because\n> we are breaking something meant to be scriptable) and the benefit is low\n> (because users don't type them a lot).\n\nRight. At some point, we may want to introduce a porcelain version of\n\"git ls-files\", but we shouldn't change its default behavior.\n\n> The archive behavior surprised me, and I would think it should be full-tree\n> by default. But it is sort of plumbing-ish, in that people have probably\n> scripted around and people _don't_ tend to create archives a lot.\n\nRight. There are probably more calls to \"git archive\" in cron jobs and\nweb interface than directly from the command-line.\n\n> That leaves clean. I would say from a consistency standpoint that it\n> should go full-tree to match the other commands. But it is one of the\n> most destructive commands, and making it full-tree makes it easier to\n> accidentally delete, instead of accidentally fail to delete.\n\nAgreed. That would be really bad surprise for an experience user to\nupgrade Git, type \"git clean -fdx\" from a subdirectory, and to notice\nthe new behavior afterwards ;-).\n\n> So depending on your view of the above, it may just be \"add -u/-A\" and\n> \"grep\" that are worth switching.\n\nAgreed.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161153","messageId":"20110215070426.GA6118@duynguyen-vnpc","threadId":"26424","inReplyTo":"20110209234621.GA12575@sigill.intra.peff.net","subject":"[PATCH] command-list.txt: mark git-archive plumbing","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-15T07:04:26Z","receivedAt":"2011-02-15T07:04:26Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"The command's official status is porcelain. However by the nature of the\ncommand it is frequently used in scripting and therefore its interface\nmust be strictly backward compatible.\n\nMark it plumbing to make it clear.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n On Wed, Feb 09, 2011 at 06:46:21PM -0500, Jeff King wrote:\n > Obviously add and grep are the two that people have talked about. The\n > archive behavior surprised me, and I would think it should be full-tree\n > by default. But it is sort of plumbing-ish, in that people have probably\n > scripted around and people _don't_ tend to create archives a lot. So it\n > may fall into the same category as ls-files/ls-tree.\n \n Perhaps a patch like this for the record?\n\n command-list.txt | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/command-list.txt b/command-list.txt\nindex 95bf18c..7888121 100644\n--- a/command-list.txt\n+++ b/command-list.txt\n@@ -5,7 +5,7 @@ git-am mainporcelain\n git-annotate ancillaryinterrogators\n git-apply plumbingmanipulators\n git-archimport foreignscminterface\n-git-archive mainporcelain\n+git-archive mainporcelain plumbinginterrogators\n git-bisect mainporcelain common\n git-blame ancillaryinterrogators\n git-branch mainporcelain common\n-- \n1.7.3.1.256.g2539c.dirty\n"},{"id":"161203","messageId":"7vwrl1nmdr.fsf@alter.siamese.dyndns.org","threadId":"26424","inReplyTo":"20110215070426.GA6118@duynguyen-vnpc","subject":"Re: [PATCH] command-list.txt: mark git-archive plumbing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T19:11:44Z","receivedAt":"2011-02-15T19:11:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> Perhaps a patch like this for the record?\n\nHmm, I don't think you can have it two ways.\n\nWhat does Documentation/cmd-list.perl do to this line?\n\n> command-list.txt | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n>\n> diff --git a/command-list.txt b/command-list.txt\n> index 95bf18c..7888121 100644\n> --- a/command-list.txt\n> +++ b/command-list.txt\n> @@ -5,7 +5,7 @@ git-am mainporcelain\n> git-annotate ancillaryinterrogators\n> git-apply plumbingmanipulators\n> git-archimport foreignscminterface\n> -git-archive mainporcelain\n> +git-archive mainporcelain plumbinginterrogators\n> git-bisect mainporcelain common\n> git-blame ancillaryinterrogators\n> git-branch mainporcelain common\n> -- \n> 1.7.3.1.256.g2539c.dirty\n"},{"id":"161274","messageId":"AANLkTi=3BUE5Zu6yLjOe-hJ4LBh8qzwVmOdML8GQ0=ss@mail.gmail.com","threadId":"26424","inReplyTo":"7vwrl1nmdr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] command-list.txt: mark git-archive plumbing","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-16T09:32:27Z","receivedAt":"2011-02-16T09:32:27Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 16, 2011 at 2:11 AM, Junio C Hamano wrote:\n> Nguyen Thai Ngoc Duy writes:\n>\n>>   Perhaps a patch like this for the record?\n>\n> Hmm, I don't think you can have it two ways.\n>\n> What does Documentation/cmd-list.perl do to this line?\n\nI see. The first category is used to split commands into a hash.\n\ncmd-list.perl produces cmds-mainporcelain.txt with git-archive and\ncmds-plumbinginterrogators.txt without.\n-- \nDuy\n"}]}