{"thread":{"id":"38959","subject":"RFC: git status --amend","startedAt":"2015-03-31T14:59:27Z","lastAt":"2015-04-03T22:05:46Z","messageCount":7,"participants":["Sven Strickroth","Jeff King","Junio C Hamano","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"258744","messageId":"551AB64F.4030400@cs-ware.de","threadId":"38959","inReplyTo":null,"subject":"RFC: git status --amend","fromName":"Sven Strickroth","fromEmail":"sven@cs-ware.de","sentAt":"2015-03-31T14:59:27Z","receivedAt":"2015-03-31T14:59:27Z","isPatch":false,"sender":{"key":"sven@cs-ware.de","avatar":null},"body":"Hi,\n\nfor frontends or scripts it would be helpful to be able to use \"git\nstatus\" for getting the repository status compared to HEAD~1 instead of\nonly HEAD (as provided by \"git commit --amend\" in the pre-filled commit\nmessage).\n\nThus, I'm suggesting to add a \"--amend\" parameter (or a parameter with a\nbetter naming) to \"git status\".\n\nWhat do you think of this idea?\n\n-- \nBest regards,\n Sven Strickroth\n PGP key id F5A9D4C4 @ any key-server\n"},{"id":"258760","messageId":"20150331180414.GB19206@peff.net","threadId":"38959","inReplyTo":"551AB64F.4030400@cs-ware.de","subject":"Re: RFC: git status --amend","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-31T18:04:14Z","receivedAt":"2015-03-31T18:04:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote:\n\n> for frontends or scripts it would be helpful to be able to use \"git\n> status\" for getting the repository status compared to HEAD~1 instead of\n> only HEAD (as provided by \"git commit --amend\" in the pre-filled commit\n> message).\n> \n> Thus, I'm suggesting to add a \"--amend\" parameter (or a parameter with a\n> better naming) to \"git status\".\n> \n> What do you think of this idea?\n\nOnce upon a time \"git status\" really was just \"git commit --dry-run\".\nThese days it has diverged a bit. But I think you could get what you\nwant with:\n\n git commit --dry-run --amend\n\nIt even supports alternate styles like --short.\n\n-Peff\n"},{"id":"258764","messageId":"xmqqvbhhqal6.fsf@gitster.dls.corp.google.com","threadId":"38959","inReplyTo":"20150331180414.GB19206@peff.net","subject":"Re: RFC: git status --amend","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-31T18:35:17Z","receivedAt":"2015-03-31T18:35:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote:\n>\n>> for frontends or scripts it would be helpful to be able to use \"git\n>> status\" for getting the repository status compared to HEAD~1 instead of\n>> only HEAD (as provided by \"git commit --amend\" in the pre-filled commit\n>> message).\n>> \n>> Thus, I'm suggesting to add a \"--amend\" parameter (or a parameter with a\n>> better naming) to \"git status\".\n>> \n>> What do you think of this idea?\n>\n> Once upon a time \"git status\" really was just \"git commit --dry-run\".\n> These days it has diverged a bit. But I think you could get what you\n> want with:\n>\n> git commit --dry-run --amend\n>\n> It even supports alternate styles like --short.\n\nI think everything you said is correct, but your \"diverged a bit\"\nmay hide one difference that could be crucial depending on the use\ncase: pathspec.\n\nWhat \"git commit --dry-run [--other-options] \" does, and\nwhat \"git status [--other-options] \" does, are different.\n\nWith or without --dry-run, to \"git commit\", tells the\ncommand to update the index at the paths specified by it from the\nworking tree contents before proceeding (the contents recorded for\nthe other paths depend on the use of -o or -i option). But ever\nsince \"git status\" departed from being \"git commit -n\", a pathspec\ngiven to the command means completely different thing.\n\nAfter working on various parts of the tree, planning to conclude the\ncurrent work with \"commit\", \"git status directory/\" is a good way to\nsee what you did in that directory without seeing what you did\noutside (which will be included in the commit, too).\n\nBut what you get from \"git commit --no-edit --dry-run directory/\"\nwould be different; it would show all the changes in the working\ntree inside directory/, including the ones that you deliberately\nleft out of the index, as paths to be committed.\n\nHaving said all that, I am a bit torn on this topic. Just like \"git\nstatus\" is a way to ask \"I've worked so far, planning to conclude\nthis with 'git commit'; tell me what I have achieved so far that are\nin the index and in the working tree, possibly limiting to these\npaths?\", I think it is a reasonable thing to ask the same question\nwith \"s/git commit/git commit --amend/\".\n\nOne workaround might be to\n\n git reset --soft HEAD^\n git status []\n ...\n git commit -c @{1}\n\nbut that is simply too error prone and ugly. I would say it would\nbe better if \"status\" knows how to answer that \"I am planning to\nconclude with 'git commit --amend'\" question.\n\nThe reason why I am torn is because I do not think \"status --amend\"\nis a sensible name for that option. \"status\" is not about amending\nanything.\n\nIf the normal \"status\" is \"give me status for the next commit\", this\nnew mode would be \"give me status for the 'commit --amend'\". Naming\nit \"git status --for-amend\" crossed my mind, but it does not sound\ngreat to me, either.\n\nSo...\n"},{"id":"258813","messageId":"20150401084230.GA12282@gmail.com","threadId":"38959","inReplyTo":"xmqqvbhhqal6.fsf@gitster.dls.corp.google.com","subject":"Re: RFC: git status --amend","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2015-04-01T08:43:24Z","receivedAt":"2015-04-01T08:43:24Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Mar 31, 2015 at 11:35:17AM -0700, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote:\n> >\n> >> for frontends or scripts it would be helpful to be able to use \"git\n> >> status\" for getting the repository status compared to HEAD~1 instead of\n> >> only HEAD (as provided by \"git commit --amend\" in the pre-filled commit\n> >> message).\n> >> \n> >> Thus, I'm suggesting to add a \"--amend\" parameter (or a parameter with a\n> >> better naming) to \"git status\".\n> >> \n> >> What do you think of this idea?\n> >\n> > Once upon a time \"git status\" really was just \"git commit --dry-run\".\n> > These days it has diverged a bit. But I think you could get what you\n> > want with:\n> >\n> > git commit --dry-run --amend\n> >\n> > It even supports alternate styles like --short.\n> \n> I think everything you said is correct, but your \"diverged a bit\"\n> may hide one difference that could be crucial depending on the use\n> case: pathspec.\n> \n> What \"git commit --dry-run [--other-options] \" does, and\n> what \"git status [--other-options] \" does, are different.\n> \n> With or without --dry-run, to \"git commit\", tells the\n> command to update the index at the paths specified by it from the\n> working tree contents before proceeding (the contents recorded for\n> the other paths depend on the use of -o or -i option). But ever\n> since \"git status\" departed from being \"git commit -n\", a pathspec\n> given to the command means completely different thing.\n> \n> After working on various parts of the tree, planning to conclude the\n> current work with \"commit\", \"git status directory/\" is a good way to\n> see what you did in that directory without seeing what you did\n> outside (which will be included in the commit, too).\n> \n> But what you get from \"git commit --no-edit --dry-run directory/\"\n> would be different; it would show all the changes in the working\n> tree inside directory/, including the ones that you deliberately\n> left out of the index, as paths to be committed.\n> \n> Having said all that, I am a bit torn on this topic. Just like \"git\n> status\" is a way to ask \"I've worked so far, planning to conclude\n> this with 'git commit'; tell me what I have achieved so far that are\n> in the index and in the working tree, possibly limiting to these\n> paths?\", I think it is a reasonable thing to ask the same question\n> with \"s/git commit/git commit --amend/\".\n> \n> One workaround might be to\n> \n> git reset --soft HEAD^\n> git status []\n> ...\n> git commit -c @{1}\n> \n> but that is simply too error prone and ugly. I would say it would\n> be better if \"status\" knows how to answer that \"I am planning to\n> conclude with 'git commit --amend'\" question.\n> \n> The reason why I am torn is because I do not think \"status --amend\"\n> is a sensible name for that option. \"status\" is not about amending\n> anything.\n> \n> If the normal \"status\" is \"give me status for the next commit\", this\n> new mode would be \"give me status for the 'commit --amend'\". Naming\n> it \"git status --for-amend\" crossed my mind, but it does not sound\n> great to me, either.\n> \n> So...\n\nI think I can understand some of the \"feeling torn\" aspects.\n\nI know exactly the problem that \"status --amend\" is trying to\nsolve, as it is non-trivial to get the status bits correct\nfor \"what it looks like when amending a commit\".\n\ngit-gui and git-cola both do some clever things to make their\namend modes work smoothly for the user, and having something\nlike \"status --amend\" could have made the implementation\nsimpler.\n\nBut \"status --amend\" still makes me torn too because it's too\nspecial-purpose. Taking a step back, \"status\" gives you a lot\nof information, and all of it is relative to HEAD.\n\n\"status --amend\" is really asking to make it all relative to\nHEAD^ instead.\n\nSo I wonder, would the syntax not be more gittish if it were,\n\n\tgit status HEAD\n\tgit status HEAD^\n\tgit status -- \n\nand it'll compare your repo's status relative to any ref.\n\nI like the above because it's general and not hard-wired into\nthe concept of amending a commit, but it enables that use case\nas well.\n\nThe ultimate convenience for script writers would be if this\ncommand gracefully handled the edge cases. I have a separate\ncode path for this one, and eliminating it would be awesome.\n\n\"git init\" time, where no commit exists (and thus \"git status\nHEAD|HEAD^\" makes no sense) is an inconvenience to script\naround. The most convenient behavior for the user would be to\ntreat that situation as being equivalent to comparing against an\nempty tree.\n\nThat could extend to post-\"git init\" when a single commit exists\nand the user asks for \"git status HEAD^\" for amending purposes.\nIt'd be great if the tool was dwim enough to also treat that as\nan empty tree comparison.\n\nI don't know if that's going too far, because normally git\nwould just yell, \"HEAD^ makes no sense!\" and tell the user to\nbugger off, but I can definitely see the utility in a dwimmy\nsoft-edges status tool that papers over some of these edge\ncases.\n\nWould generalizing \"status\" to have a more gittish syntax make\nyou feel less torn?\n-- \nDavid\n"},{"id":"258830","messageId":"xmqqlhibn509.fsf@gitster.dls.corp.google.com","threadId":"38959","inReplyTo":"20150401084230.GA12282@gmail.com","subject":"Re: RFC: git status --amend","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-01T17:16:22Z","receivedAt":"2015-04-01T17:16:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> Would generalizing \"status\" to have a more gittish syntax make\n> you feel less torn?\n\nOne of my early draft responses included a one whose punch line was\n\"Why limit the comparison to HEAD and HEAD^ but no other point of\nreference?\"\n\nBut I discarded it as a useless suggestion before writing it down,\nprimarily because I couldn't come up with an explanation _why_ being\nable to say \"git status --relative-to=next Makefile\" is useful when\non the 'master' branch.\n\nSurely, I may have changes in the Makefile relative to my index\nbecause I am preparing for the next rc release, and the Makefile in\nthe index may be different from that of the 'next' branch because I\nam on my 'master' branch. The potential output can be \"explained\"\nin such a mechanical sense (e.g. \"we generated the output this\nway\").\n\nBut I do not see an easy-to-understand explanation of the _meaning_\nof the output, i.e. \"What does it mean that the working tree file\nhas been modified since the checkout and the index is different\nrelative to that other branch? How does that information help me\nafter I learn it? What would I do differently with that information\nat hand?\"\n\nCompared to that, \"Show me what damage I would inflict if I did\n'commit' now. By the way, I may want to see that information\nlimited to these paths\" is a question whose utility is easily\nexplained, and so is the same question with 'commit' replaced by\n'commit --amend'.\n"},{"id":"258953","messageId":"20150403215744.GA39695@gmail.com","threadId":"38959","inReplyTo":"xmqqlhibn509.fsf@gitster.dls.corp.google.com","subject":"Re: RFC: git status --amend","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2015-04-03T21:57:48Z","receivedAt":"2015-04-03T21:57:48Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Wed, Apr 01, 2015 at 10:16:22AM -0700, Junio C Hamano wrote:\n> David Aguilar writes:\n> \n> > Would generalizing \"status\" to have a more gittish syntax make\n> > you feel less torn?\n> \n> One of my early draft responses included a one whose punch line was\n> \"Why limit the comparison to HEAD and HEAD^ but no other point of\n> reference?\"\n> \n> But I discarded it as a useless suggestion before writing it down,\n> primarily because I couldn't come up with an explanation _why_ being\n> able to say \"git status --relative-to=next Makefile\" is useful when\n> on the 'master' branch.\n\n\nAesthetically it's appealing because it mirrors commands like\n\"git diff HEAD^\", etc.\n\nI can see it being useful for script writers but it's a minority\ncase that's already handled by having \"status --amend\" for the\ncommon case of needing to mimic \"commit --amend\".\n\nBeyond that use case, someone could use it to write a butchery\ntool that gets a quick high-level diff of changes for both index\nand worktree against an arbitrary ref, and then apply those\nchanges selectively using other git tools.\n\nstatus is superior to the other tools (diff-index, diff-files,\nls-files) because we can get all of the information in a single\ngit invocation, which is more of a perf. concern but worth\nconsidering.\n\n> Surely, I may have changes in the Makefile relative to my index\n> because I am preparing for the next rc release, and the Makefile in\n> the index may be different from that of the 'next' branch because I\n> am on my 'master' branch. The potential output can be \"explained\"\n> in such a mechanical sense (e.g. \"we generated the output this\n> way\").\n> \n> But I do not see an easy-to-understand explanation of the _meaning_\n> of the output, i.e. \"What does it mean that the working tree file\n> has been modified since the checkout and the index is different\n> relative to that other branch? How does that information help me\n> after I learn it? What would I do differently with that information\n> at hand?\"\n> \n> Compared to that, \"Show me what damage I would inflict if I did\n> 'commit' now. By the way, I may want to see that information\n> limited to these paths\" is a question whose utility is easily\n> explained, and so is the same question with 'commit' replaced by\n> 'commit --amend'.\n\nYeah, ergonomically it would still make sense to have\n\"status --amend\" (even if it also were to also understand\n\"status \") for symmetry.\n-- \nDavid\n"},{"id":"258955","messageId":"20150403220546.GA14195@peff.net","threadId":"38959","inReplyTo":"20150403215744.GA39695@gmail.com","subject":"Re: RFC: git status --amend","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-03T22:05:46Z","receivedAt":"2015-04-03T22:05:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 03, 2015 at 02:57:48PM -0700, David Aguilar wrote:\n\n> > But I discarded it as a useless suggestion before writing it down,\n> > primarily because I couldn't come up with an explanation _why_ being\n> > able to say \"git status --relative-to=next Makefile\" is useful when\n> > on the 'master' branch.\n> \n> Aesthetically it's appealing because it mirrors commands like\n> \"git diff HEAD^\", etc.\n> \n> I can see it being useful for script writers but it's a minority\n> case that's already handled by having \"status --amend\" for the\n> common case of needing to mimic \"commit --amend\".\n> \n> Beyond that use case, someone could use it to write a butchery\n> tool that gets a quick high-level diff of changes for both index\n> and worktree against an arbitrary ref, and then apply those\n> changes selectively using other git tools.\n\nHmm. What if you had a tool that created commits out of an alternate\nworking tree and index, and then committed directly to a branch without\ntouching HEAD? Then you might run:\n\n GIT_WORK_TREE=... GIT_INDEX_FILE=... git status --relative-to=mybranch\n\nright before running:\n\n old=$(git rev-parse refs/heads/mybranch) &&\n tree=$(GIT_INDEX_FILE=... git commit-tree) &&\n commit=$(echo whatever | git commit-tree -p $old $tree) &&\n git update-ref refs/heads/mybranch $old\n\nor similar. That is basically \"git-new-workdir\", but with no per-workdir\nHEAD. Which is probably crazy, but maybe useful for a one-off commit to\nanother branch or something.\n\nI dunno. I do not have such a tool or plan to work on one, but it is at\nleast plausible to me.\n\n-Peff\n"}]}