{"thread":{"id":"34101","subject":"New feature discussion: git rebase --status","startedAt":"2013-06-11T12:35:29Z","lastAt":"2013-06-13T12:19:53Z","messageCount":16,"participants":["Mathieu Liénard--Mayor","Thomas Rast","John Keeping","Matthieu Moy","Hilco Wijbenga","Linus Torvalds","Célestin Matte","Antoine Pelisse","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"220428","messageId":"fb379a75c6c1af6dcff2e65bef1f1836@ensibm.imag.fr","threadId":"34101","inReplyTo":null,"subject":"New feature discussion: git rebase --status","fromName":"Mathieu Liénard--Mayor","fromEmail":"mathieu.lienard--mayor@ensimag.fr","sentAt":"2013-06-11T12:35:29Z","receivedAt":"2013-06-11T12:35:29Z","isPatch":false,"sender":{"key":"mathieu.lienard--mayor@ensimag.fr","avatar":null},"body":"(Got the idea from:\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)\n\nWhen in the middle of a rebase, users can be easily confused about\nwhat to do, or where they are in the rebase process.\n\nAll the information is available in .git/rebase-merge/, but I believe\nit would be helpful to have a command (for example 'git rebase\n--status') which would explicitely indicate the state of the process.\n\nFor instance, the output could look like:\n\n$ git rebase --status\nRebasing my_last_commit onto base_commit\nAlready applied 2 patches:\n\tb170635... my_commit_message\n\tb170635... my_commit_message\nCurrently applying b170635... my_commit_message\n2 patches left to apply:\n\tb170635... my_commit_message\n\tb170635... my_commit_message\n\n\nAnother nice thing could be to improve the output of 'git status' by\nsaying the number of patches left to apply.\nAs an example, it could say:\n\tYou are currently rebasing (patch 3/5).\n\nWhat do you think?\nDoes the name rebase --status seem appropriate?\nShould the output be providing more/less information?\n\nThanks =]\n-- \nMathieu Liénard--Mayor,\n2nd year at Grenoble INP - ENSIMAG\n(+33)6 80 56 30 02\n"},{"id":"220429","messageId":"871u8895xh.fsf@linux-k42r.v.cablecom.net","threadId":"34101","inReplyTo":"fb379a75c6c1af6dcff2e65bef1f1836@ensibm.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-11T12:40:26Z","receivedAt":"2013-06-11T12:40:26Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Mathieu Liénard--Mayor writes:\n\n> (Got the idea from:\n> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)\n>\n> When in the middle of a rebase, users can be easily confused about\n> what to do, or where they are in the rebase process.\n>\n> All the information is available in .git/rebase-merge/, but I believe\n> it would be helpful to have a command (for example 'git rebase\n> --status') which would explicitely indicate the state of the process.\n>\n> For instance, the output could look like:\n>\n> $ git rebase --status\n> Rebasing my_last_commit onto base_commit\n> Already applied 2 patches:\n> \tb170635... my_commit_message\n> \tb170635... my_commit_message\n> Currently applying b170635... my_commit_message\n> 2 patches left to apply:\n> \tb170635... my_commit_message\n> \tb170635... my_commit_message\n>\n>\n> Another nice thing could be to improve the output of 'git status' by\n> saying the number of patches left to apply.\n> As an example, it could say:\n> \tYou are currently rebasing (patch 3/5).\n>\n> What do you think?\n> Does the name rebase --status seem appropriate?\n> Should the output be providing more/less information?\n\nI think a worthy goal would be to arrange things such that the \"here's\nwhat you do next\" messages are shared between --status and the code that\nstops. I.e., the same code should generate\n\n When you have resolved this problem, run \"git rebase --continue\". \n If you prefer to skip this patch, run \"git rebase --skip\" instead. \n To check out the original branch and stop rebasing, run \"git rebase --abort\".\n\nin both cases. Naturally --status should also explain how it got into\nthis state, as you outlined above.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220431","messageId":"20130611125521.GL22905@serenity.lan","threadId":"34101","inReplyTo":"fb379a75c6c1af6dcff2e65bef1f1836@ensibm.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-11T12:55:21Z","receivedAt":"2013-06-11T12:55:21Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 11, 2013 at 02:35:29PM +0200, Mathieu Liénard--Mayor wrote:\n> (Got the idea from:\n> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)\n> \n> When in the middle of a rebase, users can be easily confused about\n> what to do, or where they are in the rebase process.\n> \n> All the information is available in .git/rebase-merge/, but I believe\n> it would be helpful to have a command (for example 'git rebase\n> --status') which would explicitely indicate the state of the process.\n> \n> For instance, the output could look like:\n> \n> $ git rebase --status\n> Rebasing my_last_commit onto base_commit\n> Already applied 2 patches:\n> \tb170635... my_commit_message\n> \tb170635... my_commit_message\n> Currently applying b170635... my_commit_message\n> 2 patches left to apply:\n> \tb170635... my_commit_message\n> \tb170635... my_commit_message\n\nThe one piece of information that I often want is the SHA1 of the commit\nthat is currently being applied. Currently I have to look through my\nscrollback for the \"stopping\" message or poke around in .git/.\n\nHaving that in the output of \"git status\" would be really nice, but the\noutput format you've posted is a big improvement over what we have at\nthe moment for this case.\n\nActually, the same applies for cherry-pick and revert when they have\nbeen given a range - showing the commit that is currently being applied\nin \"git status\" would be nice there as well.\n"},{"id":"220432","messageId":"vpqbo7c4wen.fsf@anie.imag.fr","threadId":"34101","inReplyTo":"20130611125521.GL22905@serenity.lan","subject":"Re: New feature discussion: git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-11T13:19:44Z","receivedAt":"2013-06-11T13:19:44Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"John Keeping writes:\n\n> The one piece of information that I often want is the SHA1 of the commit\n> that is currently being applied. Currently I have to look through my\n> scrollback for the \"stopping\" message or poke around in .git/.\n>\n> Having that in the output of \"git status\" would be really nice,\n\n... and should be rather easy as it is the content of\n.git/rebase-merge/stopped-sha\n\nPerhaps \"git status\" could say stg like \"(applying 1d3fb08, 2/5)\"\n\n> output format you've posted is a big improvement over what we have at\n> the moment for this case.\n\nMy idea when I wrote the item on the wiki was to keep the a very short\nsummary in \"git status\", and to put all the information one could whish\nin a separate command. I'd describe it as a complement more than an\nimprovement ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220465","messageId":"CAE1pOi0azF1pFqhU1Dq3qeXXF+n9xBcAnHOHapTDjbNXop0d2g@mail.gmail.com","threadId":"34101","inReplyTo":"vpqbo7c4wen.fsf@anie.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2013-06-11T17:18:28Z","receivedAt":"2013-06-11T17:18:28Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 11 June 2013 06:19, Matthieu Moy wrote:\n> John Keeping writes:\n>\n>> The one piece of information that I often want is the SHA1 of the commit\n>> that is currently being applied. Currently I have to look through my\n>> scrollback for the \"stopping\" message or poke around in .git/.\n>>\n>> Having that in the output of \"git status\" would be really nice,\n>\n> ... and should be rather easy as it is the content of\n> .git/rebase-merge/stopped-sha\n>\n> Perhaps \"git status\" could say stg like \"(applying 1d3fb08, 2/5)\"\n>\n>> output format you've posted is a big improvement over what we have at\n>> the moment for this case.\n>\n> My idea when I wrote the item on the wiki was to keep the a very short\n> summary in \"git status\", and to put all the information one could whish\n> in a separate command. I'd describe it as a complement more than an\n> improvement ;-).\n\nHaving \"git status\" display (even more) \"context sensitive\"\ninformation during \"git rebase\" or \"git merge\" would be very welcome.\nPlease, if at all possible, don't make that a separate command.\n"},{"id":"220467","messageId":"CA+55aFwtBm2RPwgXNa48zQM7ONCgzOEN2XdA_MeHsGu4=BDq5w@mail.gmail.com","threadId":"34101","inReplyTo":"CAE1pOi0azF1pFqhU1Dq3qeXXF+n9xBcAnHOHapTDjbNXop0d2g@mail.gmail.com","subject":"Re: New feature discussion: git rebase --status","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-06-11T17:23:25Z","receivedAt":"2013-06-11T17:23:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga\n wrote:\n>\n> Having \"git status\" display (even more) \"context sensitive\"\n> information during \"git rebase\" or \"git merge\" would be very welcome.\n> Please, if at all possible, don't make that a separate command.\n\nI agree. The rebase state etc is something that would be much better\nin \"git status\" output, and would avoid having people learn about\nanother new flag to random commands.\n\n Linus\n"},{"id":"220591","messageId":"fa9c12a81ef2e92ba75dd1271d9e0b2d@ensibm.imag.fr","threadId":"34101","inReplyTo":"CA+55aFwtBm2RPwgXNa48zQM7ONCgzOEN2XdA_MeHsGu4=BDq5w@mail.gmail.com","subject":"Re: New feature discussion: git rebase --status","fromName":"Mathieu Liénard--Mayor","fromEmail":"mathieu.lienard--mayor@ensimag.fr","sentAt":"2013-06-12T10:17:23Z","receivedAt":"2013-06-12T10:17:23Z","isPatch":false,"sender":{"key":"mathieu.lienard--mayor@ensimag.fr","avatar":null},"body":"After a few hours, here's a quick summary of your opinions:\n\n-'git status' should be the command to display the information instead \nof a --status flag\n-the SHA1 of the patch being applied currently is a very important \ninformation\n-displaying how we got to this state would be nice\n\nI had in mind a slight change in the current status message, just to \ninclude the SHA1 and where we're at in the rebasing. It would look like \nthis:\n\n$ git status\n# HEAD detached from ecb9f3e\n# You are currently editing a832578... my_commit_message [3/5] while \nrebasing.\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your \nchanges)\n# ......\n# ......\n\nNow, I'm not sure if we should always display the list of commits \nalready applied and those left to apply. What I mean is that maybe it \nwould be better to make status require a flag to display the two lists.\nSomething like (not sure about the flag's name):\n\n$ git status --rebase-state\n# HEAD detached from ecb9f3e\n# Already applied 2 patches:\n# \tb170635... my_commit_message\n# \tb170635... my_commit_message\n# You are currently editing a832578... my_commit_message [3/5] while \nrebasing.\n# 2 patches left to apply:\n#\tb170635... my_commit_message\n#\tb170635... my_commit_message\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your \nchanges)\n# ......\n# ......\n\nWhat do you guys think ?\n\n-- \nMathieu Liénard--Mayor,\n2nd year at Grenoble INP - ENSIMAG\n(+33)6 80 56 30 02\n"},{"id":"220592","messageId":"51B857B0.5030603@ensimag.fr","threadId":"34101","inReplyTo":"fa9c12a81ef2e92ba75dd1271d9e0b2d@ensibm.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Célestin Matte","fromEmail":"celestin.matte@ensimag.fr","sentAt":"2013-06-12T11:12:48Z","receivedAt":"2013-06-12T11:12:48Z","isPatch":false,"sender":{"key":"celestin.matte@ensimag.fr","avatar":"https://avatars.githubusercontent.com/u/2753554?v=4"},"body":"Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :\n> Now, I'm not sure if we should always display the list of commits\n> already applied and those left to apply. What I mean is that maybe it\n> would be better to make status require a flag to display the two lists.\n> Something like (not sure about the flag's name):\n> \n> $ git status --rebase-state\n> # HEAD detached from ecb9f3e\n> # Already applied 2 patches:\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # You are currently editing a832578... my_commit_message [3/5] while\n> rebasing.\n> # 2 patches left to apply:\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # (use \"git commit --amend\" to amend the current commit)\n> # (use \"git rebase --continue\" once you are satisfied with your changes)\n> # ......\n> # ......\n> \n> What do you guys think ?\n\nI agree. When you're in the process of rebasing a big list of commits,\nit would produce a lot of not-so-useful output, when what you want to\nsee is, most of the time, which commit you are currently editing.\nSo, in my opinion, whole lists should not be displayed by default.\n\nNow, if I could suggest an improvement over that list: when you rebase\nsome commits, I'm quite sure the history of what you already did is\nstored somewhere since you can revert it which git rebase --abort. It\nwould be nice to improve that list by displaying these informations, like:\n\n$ git status --rebase-state\n# HEAD detached from ecb9f3e\n# Already applied 4 patches:\n# b170635... my_commit_message\n# b170635... my_commit_message\n# new: b170635... my_commit_message\n# modified: b170635... my_commit_message\n# reworded: b170635... my_commit_message\n# You are currently editing a832578... my_commit_message [5/8] while\nrebasing.\n# 2 patches left to apply:\n# b170635... my_commit_message\n# b170635... my_commit_message\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your changes)\n# ......\n# ......\n\nI have no idea how complicated it would be to do that, though.\nWhat do you think?\n\n-- \nCélestin Matte\n"},{"id":"220593","messageId":"3cafe99fe3b868e6fc025110d324b9c8@ensibm.imag.fr","threadId":"34101","inReplyTo":"51B857B0.5030603@ensimag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Mathieu Liénard--Mayor","fromEmail":"mathieu.lienard--mayor@ensimag.fr","sentAt":"2013-06-12T11:23:32Z","receivedAt":"2013-06-12T11:23:32Z","isPatch":false,"sender":{"key":"mathieu.lienard--mayor@ensimag.fr","avatar":null},"body":"Le 2013-06-12 13:12, Célestin Matte a écrit :\n> Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :\n>> Now, I'm not sure if we should always display the list of commits\n>> already applied and those left to apply. What I mean is that maybe \n>> it\n>> would be better to make status require a flag to display the two \n>> lists.\n>> Something like (not sure about the flag's name):\n>>\n>> $ git status --rebase-state\n>> # HEAD detached from ecb9f3e\n>> # Already applied 2 patches:\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>> # You are currently editing a832578... my_commit_message [3/5] while\n>> rebasing.\n>> # 2 patches left to apply:\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>> # (use \"git commit --amend\" to amend the current commit)\n>> # (use \"git rebase --continue\" once you are satisfied with your \n>> changes)\n>> # ......\n>> # ......\n>>\n>> What do you guys think ?\n>\n> I agree. When you're in the process of rebasing a big list of \n> commits,\n> it would produce a lot of not-so-useful output, when what you want to\n> see is, most of the time, which commit you are currently editing.\n> So, in my opinion, whole lists should not be displayed by default.\n>\n> Now, if I could suggest an improvement over that list: when you \n> rebase\n> some commits, I'm quite sure the history of what you already did is\n> stored somewhere since you can revert it which git rebase --abort. It\n> would be nice to improve that list by displaying these informations, \n> like:\n>\n> $ git status --rebase-state\n> # HEAD detached from ecb9f3e\n> # Already applied 4 patches:\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # new: b170635... my_commit_message\n> # modified: b170635... my_commit_message\n> # reworded: b170635... my_commit_message\n> # You are currently editing a832578... my_commit_message [5/8] while\n> rebasing.\n> # 2 patches left to apply:\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # (use \"git commit --amend\" to amend the current commit)\n> # (use \"git rebase --continue\" once you are satisfied with your \n> changes)\n> # ......\n> # ......\n>\n> I have no idea how complicated it would be to do that, though.\n> What do you think?\n\nIf i'm not mistaking, it shouldn't be too hard, since it's pretty close \nto\nthe content of .git/rebase-merge/done:\n reword a832578 rm: better error message on failure for multiple \nfiles\n edit fd0330b rm: introduce advice.rmHints to shorten messages\n\n-- \nMathieu Liénard--Mayor,\n2nd year at Grenoble INP - ENSIMAG\n(+33)6 80 56 30 02\n"},{"id":"220601","messageId":"CALWbr2xhhUNTo54u7K5iFr+wSMSiX6JrgTX=QJsDQ6E30uwDzQ@mail.gmail.com","threadId":"34101","inReplyTo":"3cafe99fe3b868e6fc025110d324b9c8@ensibm.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-06-12T12:28:51Z","receivedAt":"2013-06-12T12:28:51Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor\n wrote:\n> Le 2013-06-12 13:12, Célestin Matte a écrit :\n>\n>> Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :\n>>>\n>>> Now, I'm not sure if we should always display the list of commits\n>>> already applied and those left to apply. What I mean is that maybe it\n>>> would be better to make status require a flag to display the two lists.\n>>> Something like (not sure about the flag's name):\n>>>\n>>> $ git status --rebase-state\n>>> # HEAD detached from ecb9f3e\n>>> # Already applied 2 patches:\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>> # You are currently editing a832578... my_commit_message [3/5] while\n>>> rebasing.\n>>> # 2 patches left to apply:\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>> # (use \"git commit --amend\" to amend the current commit)\n>>> # (use \"git rebase --continue\" once you are satisfied with your\n>>> changes)\n>>> # ......\n>>> # ......\n>>>\n>>> What do you guys think ?\n>>\n>>\n>> I agree. When you're in the process of rebasing a big list of commits,\n>> it would produce a lot of not-so-useful output, when what you want to\n>> see is, most of the time, which commit you are currently editing.\n>> So, in my opinion, whole lists should not be displayed by default.\n\nMaybe we can display previous and next commits to provide some\ncontext. Like we do for diff.\nFor example:\n\n$ git status\n# HEAD detached from ecb9f3e\n# Already applied 330 patches (displaying next 3):\n# b170635... my_commit_message\n# b170635... my_commit_message\n# b170635... my_commit_message\n# Already applied 119 (displaying last 3)\n# b170635... my_commit_message\n# b170635... my_commit_message\n# b170635... my_commit_message\n# You are currently editing a832578... my_commit_message [120/450]\nwhile rebasing.\n\nAlso, I'm not sure about the \"--rebase-state\" flag. We should probably\nhave some option to disable it (and re-enable if the default is\nchanged through a config variable), but my understanding from previous\nmessages was that not having to learn a new option to use that was\nquite important. As a consequence, I removed it from my example.\n"},{"id":"220604","messageId":"vpqehc7y00a.fsf@anie.imag.fr","threadId":"34101","inReplyTo":"fa9c12a81ef2e92ba75dd1271d9e0b2d@ensibm.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-12T12:41:25Z","receivedAt":"2013-06-12T12:41:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Mathieu Liénard--Mayor writes:\n\n> $ git status\n> # HEAD detached from ecb9f3e\n> # You are currently editing a832578... my_commit_message [3/5] while\n> rebasing.\n\nShowing the commit message here is too much IMHO. With a typical\n50-characters message, it already gives\n\n# You are currently editing a832578 __________________________________________________ [3/5] while rebasing\n\nand we usually try to fit everything on a 80-columns terminal.\n\nMy vote would go for just showing the short sha1. The user can run \"git\nshow $sha1\" to get more information if needed, it's just a copy-paste\naway. If we want to show the commit message, it should be on its own\nline.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220605","messageId":"7a0e5a6d3251dff96d4cc8b3ffb9957e@ensibm.imag.fr","threadId":"34101","inReplyTo":"CAH_OBifOeSSWB-LPT=Zv2AGEf5+nTh7yxE-1ijD0snFp3RS8Dw@mail.gmail.com","subject":"Re: New feature discussion: git rebase --status","fromName":"Mathieu Liénard--Mayor","fromEmail":"mathieu.lienard--mayor@ensimag.fr","sentAt":"2013-06-12T12:50:44Z","receivedAt":"2013-06-12T12:50:44Z","isPatch":false,"sender":{"key":"mathieu.lienard--mayor@ensimag.fr","avatar":null},"body":"Le 2013-06-12 14:44, shawn wilson a écrit :\n> Either leave it or just show the next, last, and current commit. Not\n> a whole --continue, --amend, etc stuff. The first time I had to \n> rebase\n> (about a month ago) it took me a minute to Google and figure the rest\n> out.\n\nWell, the current output looks like:\n\n$ git status\n# HEAD detached from ecb9f3e\n# You are currently editing a commit while rebasing.\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your \nchanges)\n# .....\n\nso I don't think removing those pieces of advice would be a good idea,\nespecially since you can deactivate it with advice.statusHints.\n\n> On Jun 12, 2013 8:29 AM, \"Antoine Pelisse\" \n> wrote:\n>\n>> On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor\n>> wrote:\n>> > Le 2013-06-12 13:12, Célestin Matte a écrit :\n>> >\n>> >> Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :\n>> >>>\n>> >>> Now, I'm not sure if we should always display the list of \n>> commits\n>> >>> already applied and those left to apply. What I mean is that \n>> maybe it\n>> >>> would be better to make status require a flag to display the two \n>> lists.\n>> >>> Something like (not sure about the flag's name):\n>> >>>\n>> >>> $ git status --rebase-state\n>> >>> # HEAD detached from ecb9f3e\n>> >>> # Already applied 2 patches:\n>> >>> #     b170635... my_commit_message\n>> >>> #     b170635... my_commit_message\n>> >>> # You are currently editing a832578... my_commit_message [3/5] \n>> while\n>> >>> rebasing.\n>> >>> # 2 patches left to apply:\n>> >>> #    b170635... my_commit_message\n>> >>> #    b170635... my_commit_message\n>> >>> #   (use \"git commit --amend\" to amend the current commit)\n>> >>> #   (use \"git rebase --continue\" once you are satisfied with \n>> your\n>> >>> changes)\n>> >>> # ......\n>> >>> # ......\n>> >>>\n>> >>> What do you guys think ?\n>> >>\n>> >>\n>> >> I agree. When you're in the process of rebasing a big list of \n>> commits,\n>> >> it would produce a lot of not-so-useful output, when what you \n>> want to\n>> >> see is, most of the time, which commit you are currently editing.\n>> >> So, in my opinion, whole lists should not be displayed by \n>> default.\n>>\n>> Maybe we can display previous and next commits to provide some\n>> context. Like we do for diff.\n>> For example:\n>>\n>> $ git status\n>> # HEAD detached from ecb9f3e\n>> # Already applied 330 patches (displaying next 3):\n>> #     b170635... my_commit_message\n>> #     b170635... my_commit_message\n>> #     b170635... my_commit_message\n>> # Already applied 119 (displaying last 3)\n>> #     b170635... my_commit_message\n>> #     b170635... my_commit_message\n>> #     b170635... my_commit_message\n>> # You are currently editing a832578... my_commit_message [120/450]\n>> while rebasing.\n>>\n>> Also, I'm not sure about the \"--rebase-state\" flag. We should \n>> probably\n>> have some option to disable it (and re-enable if the default is\n>> changed through a config variable), but my understanding from \n>> previous\n>> messages was that not having to learn a new option to use that was\n>> quite important. As a consequence, I removed it from my example.\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html \n>> [1]\n>\n>\n> Links:\n> ------\n> [1] http://vger.kernel.org/majordomo-info.html\n\n-- \nMathieu Liénard--Mayor,\n2nd year at Grenoble INP - ENSIMAG\n(+33)6 80 56 30 02\n"},{"id":"220607","messageId":"20130612125226.GP22905@serenity.lan","threadId":"34101","inReplyTo":"vpqehc7y00a.fsf@anie.imag.fr","subject":"Re: New feature discussion: git rebase --status","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-12T12:52:26Z","receivedAt":"2013-06-12T12:52:26Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jun 12, 2013 at 02:41:25PM +0200, Matthieu Moy wrote:\n> Mathieu Liénard--Mayor writes:\n> \n> > $ git status\n> > # HEAD detached from ecb9f3e\n> > # You are currently editing a832578... my_commit_message [3/5] while\n> > rebasing.\n> \n> Showing the commit message here is too much IMHO. With a typical\n> 50-characters message, it already gives\n> \n> # You are currently editing a832578 __________________________________________________ [3/5] while rebasing\n> \n> and we usually try to fit everything on a 80-columns terminal.\n> \n> My vote would go for just showing the short sha1. The user can run \"git\n> show $sha1\" to get more information if needed, it's just a copy-paste\n> away. If we want to show the commit message, it should be on its own\n> line.\n\nI agree. I liked your earlier suggestion of adding something like\n\"(applying 1d3fb08, 2/5)\". Where \"applying\" should be \"cherry picking\"\nor \"reverting\" when appropriate.\n\nI actually think this should be the only change to the default status\noutput, additional information on the full list of commits being applied\nshould either come from \"git rebase --status\" or some new flag to \"git\nstatus\" which is off by default.\n"},{"id":"220681","messageId":"7vzjuvynt0.fsf@alter.siamese.dyndns.org","threadId":"34101","inReplyTo":"CALWbr2xhhUNTo54u7K5iFr+wSMSiX6JrgTX=QJsDQ6E30uwDzQ@mail.gmail.com","subject":"Re: New feature discussion: git rebase --status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-12T22:19:39Z","receivedAt":"2013-06-12T22:19:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antoine Pelisse writes:\n\n> Maybe we can display previous and next commits to provide some\n> context. Like we do for diff.\n> For example:\n>\n> $ git status\n> # HEAD detached from ecb9f3e\n> # Already applied 330 patches (displaying next 3):\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # Already applied 119 (displaying last 3)\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n\nI think you meant one of them to be\n\n # Still to be applied 119 (showing the first 3)\n\ninstead. I am not sure if it is worth 8 lines, especially given\nthat \"git log --oneline -$n\" would give you \"Already applied\" part\nthat is beyond what will be shown in this message easily if you\nwanted to. So it might be enough to show \"The one that has last\nbeen replayed\" (aka \"HEAD\") and \"The one you are in the middle of\nreplaying\".\n"},{"id":"220692","messageId":"CALWbr2x-4_QSurvScYL+2Utn=-K3Knb7Kif9SAvV_V-ZdvPfCw@mail.gmail.com","threadId":"34101","inReplyTo":"7vzjuvynt0.fsf@alter.siamese.dyndns.org","subject":"Re: New feature discussion: git rebase --status","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-06-13T05:52:56Z","receivedAt":"2013-06-13T05:52:56Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano wrote:\n> Antoine Pelisse writes:\n>\n>> Maybe we can display previous and next commits to provide some\n>> context. Like we do for diff.\n>> For example:\n>>\n>> $ git status\n>> # HEAD detached from ecb9f3e\n>> # Already applied 330 patches (displaying next 3):\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>> # Already applied 119 (displaying last 3)\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>> # b170635... my_commit_message\n>\n> I think you meant one of them to be\n>\n> # Still to be applied 119 (showing the first 3)\n>\n> instead.\n\nOf course,\n\n> I am not sure if it is worth 8 lines, especially given\n> that \"git log --oneline -$n\" would give you \"Already applied\" part\n> that is beyond what will be shown in this message easily if you\n> wanted to. So it might be enough to show \"The one that has last\n> been replayed\" (aka \"HEAD\") and \"The one you are in the middle of\n> replaying\".\n\nThat's very true. The piece of information that is hard to get is\n\"what's left to be done\".\n\nSo something like this would make sense:\n\n$ git status\n# HEAD detached from ecb9f3e\n# You are currently editing a832578... my_commit_message [120/450]\nwhile rebasing.\n# 320 patches left to apply (showing next 3):\n# b170635... my_commit_message\n# b170635... my_commit_message\n# b170635... my_commit_message\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your changes)\n\nSo that's 4 extra lines compared to current output. But should we make\nit a default ?\n"},{"id":"220718","messageId":"dc115f90be3bc5830473a6648bf37df5@ensibm.imag.fr","threadId":"34101","inReplyTo":"CALWbr2x-4_QSurvScYL+2Utn=-K3Knb7Kif9SAvV_V-ZdvPfCw@mail.gmail.com","subject":"Re: New feature discussion: git rebase --status","fromName":"Mathieu Liénard--Mayor","fromEmail":"mathieu.lienard--mayor@ensimag.fr","sentAt":"2013-06-13T12:19:53Z","receivedAt":"2013-06-13T12:19:53Z","isPatch":false,"sender":{"key":"mathieu.lienard--mayor@ensimag.fr","avatar":null},"body":"Le 2013-06-13 07:52, Antoine Pelisse a écrit :\n> On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano \n> wrote:\n>> Antoine Pelisse writes:\n>>\n>>> Maybe we can display previous and next commits to provide some\n>>> context. Like we do for diff.\n>>> For example:\n>>>\n>>> $ git status\n>>> # HEAD detached from ecb9f3e\n>>> # Already applied 330 patches (displaying next 3):\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>> # Already applied 119 (displaying last 3)\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>> # b170635... my_commit_message\n>>\n>> I think you meant one of them to be\n>>\n>> # Still to be applied 119 (showing the first 3)\n>>\n>> instead.\n>\n> Of course,\n>\n>> I am not sure if it is worth 8 lines, especially given\n>> that \"git log --oneline -$n\" would give you \"Already applied\" part\n>> that is beyond what will be shown in this message easily if you\n>> wanted to. So it might be enough to show \"The one that has last\n>> been replayed\" (aka \"HEAD\") and \"The one you are in the middle of\n>> replaying\".\n>\n> That's very true. The piece of information that is hard to get is\n> \"what's left to be done\".\n>\n> So something like this would make sense:\n>\n> $ git status\n> # HEAD detached from ecb9f3e\n> # You are currently editing a832578... my_commit_message [120/450]\n> while rebasing.\n> # 320 patches left to apply (showing next 3):\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # b170635... my_commit_message\n> # (use \"git commit --amend\" to amend the current commit)\n> # (use \"git rebase --continue\" once you are satisfied with your \n> changes)\n>\n> So that's 4 extra lines compared to current output. But should we \n> make\n> it a default ?\nPersonally I believe we should not make it the default output.\n\nCurrently, the output I'm working on is the following:\n\n$ git status\n# HEAD detached from ecb9f3e\n# You are currently editing a832578 while rebasing branch 'split-rm-v7' \non 'ecb9f3e'.\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your \nchanges)\n\n$ git status --rebase-todo\n# HEAD detached from ecb9f3e\n# You are currently editing a832578 while rebasing branch 'split-rm-v7' \non 'ecb9f3e'.\n# Still 2 patches left to apply:\n# e a832578 rm: better error message on failure for multiple files\n# e fd0330b rm: introduce advice.rmHints to shorten messages\n# (use \"git commit --amend\" to amend the current commit)\n# (use \"git rebase --continue\" once you are satisfied with your \nchanges)\n\nI'm still unsure about the name of the flag, I chose that one \naccordingly\nto .git/merge-rebase/rebase-todo\n\n-- \nMathieu Liénard--Mayor,\n2nd year at Grenoble INP - ENSIMAG\n(+33)6 80 56 30 02\n"}]}