{"thread":{"id":"59321","subject":"When exactly should REBASE_HEAD exist?","startedAt":"2023-02-28T13:18:32Z","lastAt":"2023-03-20T08:42:26Z","messageCount":25,"participants":["Stefan Haller","Phillip Wood","Chris Torek","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"472841","messageId":"961e68d7-5f43-c385-10fa-455b8e2f32d0@haller-berlin.de","threadId":"59321","inReplyTo":null,"subject":"When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-02-28T12:55:20Z","receivedAt":"2023-02-28T13:18:32Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"As far as I can tell, REBASE_HEAD always points to the last commit that\nwas attempted to be applied in a rebase, not matter whether that attempt\nwas successful or not. In other words, when you break in a rebase with\n\"edit\" or \"break\", REBASE_HEAD is the same as HEAD (except when you\nbreak before the first commit, in that case REBASE_HEAD is unset).\n\nI wonder whether it would make sense to set REBASE_HEAD only when\napplying a patch failed. That seems to be the main use case of it.\n\nThe reason why I am asking this is: I'm using lazygit, which, during\ninteractive rebases, shows a combined view of the real commits that were\nalready applied, and the remaining commits that are yet to be applied\n(it gets these by parsing rebase-merge/git-rebase-todo); something like\nthis, when I set the 2nd commit to \"edit\":\n\n pick 4th commit\n pick 3rd commit\n 2nd commit <-- YOU ARE HERE\n 1st commit\n\nThis is great, but assuming that the 2nd commit conflicted, currently\nthe display looks like this:\n\n pick 4th commit\n pick 3rd commit\n 1st commit <-- YOU ARE HERE\n\nI would like to extend this to also show a \"fake entry\" for the commit\nthat conflicted, if there is one. REBASE_HEAD is perfect for this,\nexcept that I need a way to distinguish whether it was applied already\nor not.\n\nI currently do that by comparing it against HEAD, and only showing it\nwhen they are different. That doesn't always work though, e.g. when I\namend the current \"edit\" commit.\n\nAny better suggestions how to work around this?\n\n-Stefan\n\n"},{"id":"472918","messageId":"374f83c2-7bf0-38be-26ae-de28340c37d2@dunelm.org.uk","threadId":"59321","inReplyTo":"961e68d7-5f43-c385-10fa-455b8e2f32d0@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-02T10:19:33Z","receivedAt":"2023-03-02T10:19:50Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 28/02/2023 12:55, Stefan Haller wrote:\n> As far as I can tell, REBASE_HEAD always points to the last commit that\n> was attempted to be applied in a rebase, not matter whether that attempt\n> was successful or not. In other words, when you break in a rebase with\n> \"edit\" or \"break\", REBASE_HEAD is the same as HEAD \n\nAs you said at the beginning REBASE_HEAD points to the commit that we're \ntrying to pick, so it will only be the same as HEAD if the pick was \nsuccessful and it was not rebased onto a new parent. I think it is \nuseful to have REBASE_HEAD set when editing a commit as I find it is \nsometimes useful to look at the original commit. I don't think we do (or \nshould) set it when rebase stops for a \"break\" command or a failed \n\"exec\" command.\n\n>(except when you\n> break before the first commit, in that case REBASE_HEAD is unset).\n> \n> I wonder whether it would make sense to set REBASE_HEAD only when\n> applying a patch failed. That seems to be the main use case of it.\n\nAs I mentioned above, I think having it available when editing a commit \nus useful.\n\n> The reason why I am asking this is: I'm using lazygit, which, during\n> interactive rebases, shows a combined view of the real commits that were\n> already applied, and the remaining commits that are yet to be applied\n> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n> this, when I set the 2nd commit to \"edit\":\n> \n> pick 4th commit\n> pick 3rd commit\n> 2nd commit <-- YOU ARE HERE\n> 1st commit\n> \n> This is great, but assuming that the 2nd commit conflicted, currently\n> the display looks like this:\n> \n> pick 4th commit\n> pick 3rd commit\n> 1st commit <-- YOU ARE HERE\n> \n> I would like to extend this to also show a \"fake entry\" for the commit\n> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n> except that I need a way to distinguish whether it was applied already\n> or not.\n\nCan you check the index for conflicts when the rebase stops?\n\nBest Wishes\n\nPhillip\n\n> I currently do that by comparing it against HEAD, and only showing it\n> when they are different. That doesn't always work though, e.g. when I\n> amend the current \"edit\" commit.\n> \n> Any better suggestions how to work around this?\n> \n> -Stefan\n> \n"},{"id":"472932","messageId":"f28bb5a7-ec68-dce2-9b63-7bfb5330c33e@haller-berlin.de","threadId":"59321","inReplyTo":"374f83c2-7bf0-38be-26ae-de28340c37d2@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-02T20:27:22Z","receivedAt":"2023-03-02T20:27:43Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 02.03.23 11:19, Phillip Wood wrote:\n> On 28/02/2023 12:55, Stefan Haller wrote:\n>> As far as I can tell, REBASE_HEAD always points to the last commit that\n>> was attempted to be applied in a rebase, not matter whether that attempt\n>> was successful or not. In other words, when you break in a rebase with\n>> \"edit\" or \"break\", REBASE_HEAD is the same as HEAD \n> \n> As you said at the beginning REBASE_HEAD points to the commit that we're\n> trying to pick, so it will only be the same as HEAD if the pick was\n> successful and it was not rebased onto a new parent.\n\nRight, I was a bit sloppy in describing the current behavior.\n\n> I think it is\n> useful to have REBASE_HEAD set when editing a commit as I find it is\n> sometimes useful to look at the original commit.\n\nOK.\n\n>> The reason why I am asking this is: I'm using lazygit, which, during\n>> interactive rebases, shows a combined view of the real commits that were\n>> already applied, and the remaining commits that are yet to be applied\n>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>> this, when I set the 2nd commit to \"edit\":\n>>\n>>    pick   4th commit\n>>    pick   3rd commit\n>>           2nd commit  <-- YOU ARE HERE\n>>           1st commit\n>>\n>> This is great, but assuming that the 2nd commit conflicted, currently\n>> the display looks like this:\n>>\n>>    pick   4th commit\n>>    pick   3rd commit\n>>           1st commit  <-- YOU ARE HERE\n>>\n>> I would like to extend this to also show a \"fake entry\" for the commit\n>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>> except that I need a way to distinguish whether it was applied already\n>> or not.\n> \n> Can you check the index for conflicts when the rebase stops?\n\nI could do that, but then the fake entry would go away as soon as I have\nstaged all conflict resolutions. I would find it useful for it to stay\nvisible in that case, until I continue the rebase.\n\n-Stefan\n"},{"id":"472951","messageId":"c237c1e3-5cd0-503d-ff4b-96f645a659f3@haller-berlin.de","threadId":"59321","inReplyTo":"f28bb5a7-ec68-dce2-9b63-7bfb5330c33e@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-03T10:57:04Z","receivedAt":"2023-03-03T10:57:23Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 02.03.23 21:27, Stefan Haller wrote:\n> On 02.03.23 11:19, Phillip Wood wrote:\n>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>> interactive rebases, shows a combined view of the real commits that were\n>>> already applied, and the remaining commits that are yet to be applied\n>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>> this, when I set the 2nd commit to \"edit\":\n>>>\n>>>    pick   4th commit\n>>>    pick   3rd commit\n>>>           2nd commit  <-- YOU ARE HERE\n>>>           1st commit\n>>>\n>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>> the display looks like this:\n>>>\n>>>    pick   4th commit\n>>>    pick   3rd commit\n>>>           1st commit  <-- YOU ARE HERE\n>>>\n>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>> except that I need a way to distinguish whether it was applied already\n>>> or not.\n>>\n>> Can you check the index for conflicts when the rebase stops?\n> \n> I could do that, but then the fake entry would go away as soon as I have\n> staged all conflict resolutions. I would find it useful for it to stay\n> visible in that case, until I continue the rebase.\n\nIt seems that I can get close by checking whether the file\n.git/rebase-merge/amend exists. If it does, the current patch was\napplied already, and I don't show the fake entry. If it doesn't, we\nstill need to commit the changes from REBASE-HEAD, so it makes sense to\nshow it in the list.\n\nDoes this sound like a reasonable approach? I must admit that the code\nin sequencer.c is too complex for me to tell at a glance whether there\nare situations where this heuristic would do the wrong thing.\n\n-Stefan\n"},{"id":"472974","messageId":"CAPx1Gvdik+QhTw8U1vd0cW1yZ9GbgDpmW7apxnXdY=E0okLpTQ@mail.gmail.com","threadId":"59321","inReplyTo":"c237c1e3-5cd0-503d-ff4b-96f645a659f3@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2023-03-03T21:25:19Z","receivedAt":"2023-03-03T21:25:40Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Fri, Mar 3, 2023 at 3:04 AM Stefan Haller wrote:\n> It seems that I can get close by checking whether the file\n> .git/rebase-merge/amend exists.\n\nThe location and existence of this file depends on Git version and\nwhether you're using added working trees, so that's not generally\nthe right directionA to go. It would be best if `git status`\nreported all of this information directly: perhaps --porcelain=v2\ncan be augmented to provide this, or there might even be a\n--porcelain=v3 if necessary.\n\nOf course, you'll still have to do some kind of guesswork for\nversions of Git that don't produce the right status.\n\nIn any case someone would need to add the desired information\nto `git status`.\n\nChris\n"},{"id":"472990","messageId":"347052f1-dd7d-dc72-6171-a858eea94747@haller-berlin.de","threadId":"59321","inReplyTo":"CAPx1Gvdik+QhTw8U1vd0cW1yZ9GbgDpmW7apxnXdY=E0okLpTQ@mail.gmail.com","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-04T08:36:47Z","receivedAt":"2023-03-04T08:36:56Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 03.03.23 22:25, Chris Torek wrote:\n> On Fri, Mar 3, 2023 at 3:04 AM Stefan Haller wrote:\n>> It seems that I can get close by checking whether the file\n>> .git/rebase-merge/amend exists.\n> \n> The location and existence of this file depends on Git version and\n> whether you're using added working trees, so that's not generally\n> the right directionA to go.\n\nFrom what I can see, the current behavior of the .git/rebase-merge/amend\nfile was done in 2.12, that would be more than good enough for me. Did I\nmiss any changes to the behavior since then?\n\nI'm surprised to hear that worktrees play a role in this. Do you have\nmore details about this?\n\n> It would be best if `git status`\n> reported all of this information directly: perhaps --porcelain=v2\n> can be augmented to provide this, or there might even be a\n> --porcelain=v3 if necessary.\n\nYes, that would be nice, but based on what state would it provide this\ninformation? Are you suggesting that some new file should be added to\n.git/rebase-merge/ to keep track of it (more reliably than the amend\nfile does today), or could the information be derived somehow from what\nexists already? And if it's the latter, then why shouldn't I be able to\ndo that myself in the same way for the time being?\n\n-Stefan\n"},{"id":"473029","messageId":"db9f3be7-097f-006e-927a-91be7a50360c@dunelm.org.uk","threadId":"59321","inReplyTo":"f28bb5a7-ec68-dce2-9b63-7bfb5330c33e@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-05T14:31:55Z","receivedAt":"2023-03-05T14:32:12Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 02/03/2023 20:27, Stefan Haller wrote:\n> On 02.03.23 11:19, Phillip Wood wrote:\n>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>> interactive rebases, shows a combined view of the real commits that were\n>>> already applied, and the remaining commits that are yet to be applied\n>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>> this, when I set the 2nd commit to \"edit\":\n>>>\n>>>    pick   4th commit\n>>>    pick   3rd commit\n>>>           2nd commit  <-- YOU ARE HERE\n>>>           1st commit\n>>>\n>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>> the display looks like this:\n>>>\n>>>    pick   4th commit\n>>>    pick   3rd commit\n>>>           1st commit  <-- YOU ARE HERE\n>>>\n>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>> except that I need a way to distinguish whether it was applied already\n>>> or not.\n>>\n>> Can you check the index for conflicts when the rebase stops?\n> \n> I could do that, but then the fake entry would go away as soon as I have\n> staged all conflict resolutions. I would find it useful for it to stay\n> visible in that case, until I continue the rebase.\n\nI've not used lazygit but looking at the github page it seems that it is \na persistent process that runs \"git rebase\". If that's the case I would \nthink that you can check for conflicts when the rebase stops and keep \nthat value in memory until the rebase is started again.\n\nAnother thing to bear in mind is that if the commit being picked has \nalready been applied upstream then the rebase will stop without \nconflicts but you'd want to add the commit being picked to the list in \nlazygit.\n\nI think your best bet might be to read \"$(git rev-parse --git-path \nrebase-merge/done)\" the last line of which contains the last todo \ncommand the rebase tried to execute. Not that failed command are \nsometimes rescheduled (for example when a pick would overwrite an \nuntracked file) so you'd need to check the first line of \"$(git \nrev-parse --git-path rebase-merge/git-rebase-todo)\" as well.\n\nBest Wishes\n\nPhillip\n\n> -Stefan\n"},{"id":"473030","messageId":"65f9d6c3-d7eb-5059-74d1-b9c150ddcccf@dunelm.org.uk","threadId":"59321","inReplyTo":"c237c1e3-5cd0-503d-ff4b-96f645a659f3@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-05T14:33:30Z","receivedAt":"2023-03-05T14:33:42Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 03/03/2023 10:57, Stefan Haller wrote:\n> On 02.03.23 21:27, Stefan Haller wrote:\n>> On 02.03.23 11:19, Phillip Wood wrote:\n>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>> interactive rebases, shows a combined view of the real commits that were\n>>>> already applied, and the remaining commits that are yet to be applied\n>>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>>> this, when I set the 2nd commit to \"edit\":\n>>>>\n>>>>    pick   4th commit\n>>>>    pick   3rd commit\n>>>>           2nd commit  <-- YOU ARE HERE\n>>>>           1st commit\n>>>>\n>>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>>> the display looks like this:\n>>>>\n>>>>    pick   4th commit\n>>>>    pick   3rd commit\n>>>>           1st commit  <-- YOU ARE HERE\n>>>>\n>>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>> except that I need a way to distinguish whether it was applied already\n>>>> or not.\n>>>\n>>> Can you check the index for conflicts when the rebase stops?\n>>\n>> I could do that, but then the fake entry would go away as soon as I have\n>> staged all conflict resolutions. I would find it useful for it to stay\n>> visible in that case, until I continue the rebase.\n> \n> It seems that I can get close by checking whether the file\n> .git/rebase-merge/amend exists. If it does, the current patch was\n> applied already, and I don't show the fake entry. If it doesn't, we\n> still need to commit the changes from REBASE-HEAD, so it makes sense to\n> show it in the list.\n> \n> Does this sound like a reasonable approach? I must admit that the code\n> in sequencer.c is too complex for me to tell at a glance whether there\n> are situations where this heuristic would do the wrong thing.\n\nWhen a fixup or squash stops for a confict resolution that file also \nexists as the result needs to be squashed into HEAD.\n\nBest Wishes\n\nPhillip\n"},{"id":"473031","messageId":"675876fa-cafb-b418-da88-93f3459fe270@haller-berlin.de","threadId":"59321","inReplyTo":"65f9d6c3-d7eb-5059-74d1-b9c150ddcccf@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-05T16:58:54Z","receivedAt":"2023-03-05T16:59:04Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 05.03.23 15:33, Phillip Wood wrote:\n> Hi Stefan\n> \n> On 03/03/2023 10:57, Stefan Haller wrote:\n>> On 02.03.23 21:27, Stefan Haller wrote:\n>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>>> interactive rebases, shows a combined view of the real commits that\n>>>>> were\n>>>>> already applied, and the remaining commits that are yet to be applied\n>>>>> (it gets these by parsing rebase-merge/git-rebase-todo); something\n>>>>> like\n>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>\n>>>>>     pick   4th commit\n>>>>>     pick   3rd commit\n>>>>>            2nd commit  <-- YOU ARE HERE\n>>>>>            1st commit\n>>>>>\n>>>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>>>> the display looks like this:\n>>>>>\n>>>>>     pick   4th commit\n>>>>>     pick   3rd commit\n>>>>>            1st commit  <-- YOU ARE HERE\n>>>>>\n>>>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>> except that I need a way to distinguish whether it was applied already\n>>>>> or not.\n>>>>\n>>>> Can you check the index for conflicts when the rebase stops?\n>>>\n>>> I could do that, but then the fake entry would go away as soon as I have\n>>> staged all conflict resolutions. I would find it useful for it to stay\n>>> visible in that case, until I continue the rebase.\n>>\n>> It seems that I can get close by checking whether the file\n>> .git/rebase-merge/amend exists. If it does, the current patch was\n>> applied already, and I don't show the fake entry. If it doesn't, we\n>> still need to commit the changes from REBASE-HEAD, so it makes sense to\n>> show it in the list.\n> \n> When a fixup or squash stops for a confict resolution that file also\n> exists as the result needs to be squashed into HEAD.\n\nAh damn, yes. And that's even a pretty common situation, so I can't just\nignore it as a rare edge case.\n\n-Stefan\n"},{"id":"473032","messageId":"3ab454f1-2bb5-d990-4cc4-4e2fde2ba294@haller-berlin.de","threadId":"59321","inReplyTo":"db9f3be7-097f-006e-927a-91be7a50360c@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-05T16:59:08Z","receivedAt":"2023-03-05T16:59:13Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 05.03.23 15:31, Phillip Wood wrote:\n> Hi Stefan\n> \n> On 02/03/2023 20:27, Stefan Haller wrote:\n>> On 02.03.23 11:19, Phillip Wood wrote:\n>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>> interactive rebases, shows a combined view of the real commits that\n>>>> were\n>>>> already applied, and the remaining commits that are yet to be applied\n>>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>>> this, when I set the 2nd commit to \"edit\":\n>>>>\n>>>>     pick   4th commit\n>>>>     pick   3rd commit\n>>>>            2nd commit  <-- YOU ARE HERE\n>>>>            1st commit\n>>>>\n>>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>>> the display looks like this:\n>>>>\n>>>>     pick   4th commit\n>>>>     pick   3rd commit\n>>>>            1st commit  <-- YOU ARE HERE\n>>>>\n>>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>> except that I need a way to distinguish whether it was applied already\n>>>> or not.\n>>>\n>>> Can you check the index for conflicts when the rebase stops?\n>>\n>> I could do that, but then the fake entry would go away as soon as I have\n>> staged all conflict resolutions. I would find it useful for it to stay\n>> visible in that case, until I continue the rebase.\n> \n> I've not used lazygit but looking at the github page it seems that it is\n> a persistent process that runs \"git rebase\". If that's the case I would\n> think that you can check for conflicts when the rebase stops and keep\n> that value in memory until the rebase is started again.\n\nI had considered that, but it would be preferable if it were possible to\nquit lazygit, start it again, and have it show the same state again. Or\neven start the rebase outside of lazygit while it isn't running at all,\nand then start it and have it display the correct state.\n\n> I think your best bet might be to read \"$(git rev-parse --git-path\n> rebase-merge/done)\" the last line of which contains the last todo\n> command the rebase tried to execute.\n\nI'm not sure I understand; you mean in order to distinguish whether it\nwas a pick or a fixup?\n\n-Stefan\n"},{"id":"473033","messageId":"97eec89b-6a10-434a-a9aa-54c266da7fb1@haller-berlin.de","threadId":"59321","inReplyTo":"3ab454f1-2bb5-d990-4cc4-4e2fde2ba294@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-05T19:13:02Z","receivedAt":"2023-03-05T19:13:10Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 05.03.23 17:59, Stefan Haller wrote:\n> On 05.03.23 15:31, Phillip Wood wrote:\n>> Hi Stefan\n>>\n>> On 02/03/2023 20:27, Stefan Haller wrote:\n>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>>> interactive rebases, shows a combined view of the real commits that\n>>>>> were\n>>>>> already applied, and the remaining commits that are yet to be applied\n>>>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>\n>>>>>     pick   4th commit\n>>>>>     pick   3rd commit\n>>>>>            2nd commit  <-- YOU ARE HERE\n>>>>>            1st commit\n>>>>>\n>>>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>>>> the display looks like this:\n>>>>>\n>>>>>     pick   4th commit\n>>>>>     pick   3rd commit\n>>>>>            1st commit  <-- YOU ARE HERE\n>>>>>\n>>>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>> except that I need a way to distinguish whether it was applied already\n>>>>> or not.\n>>>>\n>>>> Can you check the index for conflicts when the rebase stops?\n>>>\n>>> I could do that, but then the fake entry would go away as soon as I have\n>>> staged all conflict resolutions. I would find it useful for it to stay\n>>> visible in that case, until I continue the rebase.\n>>\n>> I've not used lazygit but looking at the github page it seems that it is\n>> a persistent process that runs \"git rebase\". If that's the case I would\n>> think that you can check for conflicts when the rebase stops and keep\n>> that value in memory until the rebase is started again.\n> \n> I had considered that, but it would be preferable if it were possible to\n> quit lazygit, start it again, and have it show the same state again. Or\n> even start the rebase outside of lazygit while it isn't running at all,\n> and then start it and have it display the correct state.\n> \n>> I think your best bet might be to read \"$(git rev-parse --git-path\n>> rebase-merge/done)\" the last line of which contains the last todo\n>> command the rebase tried to execute.\n> \n> I'm not sure I understand; you mean in order to distinguish whether it\n> was a pick or a fixup?\n\nOK, I guess it's something like\n\nshow_fake_entry :=\n REBASE_HEAD exists\n && (last command in \"done\" file was not \"edit\"\n || \"amend\" file exists)\n\nIs that what you meant? (Minus the bit about rescheduling failed\ncommands, which I still need to wrap my head around...)\n\n-Stefan\n"},{"id":"473034","messageId":"18763465-de3b-7e64-129b-1f9337ea1924@dunelm.org.uk","threadId":"59321","inReplyTo":"97eec89b-6a10-434a-a9aa-54c266da7fb1@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-05T20:15:23Z","receivedAt":"2023-03-05T20:15:35Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 05/03/2023 19:13, Stefan Haller wrote:\n> On 05.03.23 17:59, Stefan Haller wrote:\n>> On 05.03.23 15:31, Phillip Wood wrote:\n>>> Hi Stefan\n>>>\n>>> On 02/03/2023 20:27, Stefan Haller wrote:\n>>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>>>> interactive rebases, shows a combined view of the real commits that\n>>>>>> were\n>>>>>> already applied, and the remaining commits that are yet to be applied\n>>>>>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>>\n>>>>>>     pick   4th commit\n>>>>>>     pick   3rd commit\n>>>>>>            2nd commit  <-- YOU ARE HERE\n>>>>>>            1st commit\n>>>>>>\n>>>>>> This is great, but assuming that the 2nd commit conflicted, currently\n>>>>>> the display looks like this:\n>>>>>>\n>>>>>>     pick   4th commit\n>>>>>>     pick   3rd commit\n>>>>>>            1st commit  <-- YOU ARE HERE\n>>>>>>\n>>>>>> I would like to extend this to also show a \"fake entry\" for the commit\n>>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>>> except that I need a way to distinguish whether it was applied already\n>>>>>> or not.\n>>>>>\n>>>>> Can you check the index for conflicts when the rebase stops?\n>>>>\n>>>> I could do that, but then the fake entry would go away as soon as I have\n>>>> staged all conflict resolutions. I would find it useful for it to stay\n>>>> visible in that case, until I continue the rebase.\n>>>\n>>> I've not used lazygit but looking at the github page it seems that it is\n>>> a persistent process that runs \"git rebase\". If that's the case I would\n>>> think that you can check for conflicts when the rebase stops and keep\n>>> that value in memory until the rebase is started again.\n>>\n>> I had considered that, but it would be preferable if it were possible to\n>> quit lazygit, start it again, and have it show the same state again. Or\n>> even start the rebase outside of lazygit while it isn't running at all,\n>> and then start it and have it display the correct state.\n>>\n>>> I think your best bet might be to read \"$(git rev-parse --git-path\n>>> rebase-merge/done)\" the last line of which contains the last todo\n>>> command the rebase tried to execute.\n>>\n>> I'm not sure I understand; you mean in order to distinguish whether it\n>> was a pick or a fixup?\n> \n> OK, I guess it's something like\n> \n> show_fake_entry :=\n> REBASE_HEAD exists\n> && (last command in \"done\" file was not \"edit\"\n> || \"amend\" file exists)\n> \n> Is that what you meant? (Minus the bit about rescheduling failed\n> commands, which I still need to wrap my head around...)\n\nI meant you could just use the done file to get the last command, there \nis no need to look at REBASE_HEAD.\n\nBest Wishes\n\nPhillip\n\n> -Stefan\n"},{"id":"473038","messageId":"CAPx1Gvc+rBMe1bsg8XW_DyPUN9aJu9tQyhMLP0Zu-aeWCkzSGw@mail.gmail.com","threadId":"59321","inReplyTo":"347052f1-dd7d-dc72-6171-a858eea94747@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2023-03-06T03:31:04Z","receivedAt":"2023-03-06T03:31:24Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Sat, Mar 4, 2023 at 12:36 AM Stefan Haller wrote:\n> From what I can see, the current behavior of the .git/rebase-merge/amend\n> file was done in 2.12, that would be more than good enough for me. Did I\n> miss any changes to the behavior since then?\n\nProbably not - but `git status` remains the right place to decode the\ninformation, since it will be updated appropriately whenever this changes.\n\n> I'm surprised to hear that worktrees play a role in this. Do you have\n> more details about this?\n\n$ git worktree add foo\n$ cd ../foo\n$ git rebase -i HEAD~2\n\nputs the rebase-todo file into\n`.git/worktrees/foo/rebase-merge/git-rebase-todo`;\nall the status files will likewise be in the `.git/worktrees/foo/`\ndirectory.\n\n>> It would be best if `git status`\n>> reported all of this information directly ...\n\n> Yes, that would be nice, but based on what state would it provide this\n> information? Are you suggesting that some new file should be added to\n> .git/rebase-merge/ to keep track of it (more reliably than the amend\n> file does today), or could the information be derived somehow from what\n> exists already?\n\nI don't know which parts are reliably derive-able today, but to\nthe extent that `git status` *can't* provide the necessary information,\nI'd call that a bug in `gitt status`, to be fixed by saving that information\nsomewhere. Until it exists, there's nothing you can do, but if and when\n(a) it does exist and (b) `git status` provides it, it won't matter\nwhether it's in some added worktree, or moves around or changes\nform: you'll get it in a reliable fashion.\n\nIn other words, this is not helpful *yet*. :-)\n\nChris\n"},{"id":"473120","messageId":"48f58b30-13d7-cd1d-6f7d-6cc63d2c9178@haller-berlin.de","threadId":"59321","inReplyTo":"CAPx1Gvc+rBMe1bsg8XW_DyPUN9aJu9tQyhMLP0Zu-aeWCkzSGw@mail.gmail.com","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-07T13:16:48Z","receivedAt":"2023-03-07T13:18:17Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 06.03.23 04:31, Chris Torek wrote:\n> On Sat, Mar 4, 2023 at 12:36 AM Stefan Haller wrote:\n>> I'm surprised to hear that worktrees play a role in this. Do you have\n>> more details about this?\n> \n> $ git worktree add foo\n> $ cd ../foo\n> $ git rebase -i HEAD~2\n> \n> puts the rebase-todo file into\n> `.git/worktrees/foo/rebase-merge/git-rebase-todo`;\n> all the status files will likewise be in the `.git/worktrees/foo/`\n> directory.\n\nI see. That should be taken care of by not hard-coding \".git/...\", but\nusing something like \"git rev-parse --git-path ...\". We are doing that\nalready, otherwise most of lazygit's other rebase commands wouldn't work\nin worktrees.\n\n>>> It would be best if `git status`\n>>> reported all of this information directly ...\n> \n>> Yes, that would be nice, but based on what state would it provide this\n>> information? Are you suggesting that some new file should be added to\n>> .git/rebase-merge/ to keep track of it (more reliably than the amend\n>> file does today), or could the information be derived somehow from what\n>> exists already?\n> \n> I don't know which parts are reliably derive-able today, but to\n> the extent that `git status` *can't* provide the necessary information,\n> I'd call that a bug in `gitt status`, to be fixed by saving that information\n> somewhere. Until it exists, there's nothing you can do, but if and when\n> (a) it does exist and (b) `git status` provides it, it won't matter\n> whether it's in some added worktree, or moves around or changes\n> form: you'll get it in a reliable fashion.\n> \n> In other words, this is not helpful *yet*. :-)\n\nI see, thanks for the explanation. I agree. Trouble is, I don't have the\ncapacity to drive such an addition to git status, and I doubt anybody\nelse would be interested in doing it for me (are you? :-), so...\n\n-Stefan\n"},{"id":"473132","messageId":"xmqqo7p4zb8d.fsf@gitster.g","threadId":"59321","inReplyTo":"961e68d7-5f43-c385-10fa-455b8e2f32d0@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-07T18:07:30Z","receivedAt":"2023-03-07T18:12:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Haller writes:\n\n> The reason why I am asking this is: I'm using lazygit, which, during\n> interactive rebases, shows a combined view of the real commits that were\n> already applied, and the remaining commits that are yet to be applied\n> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n> this, when I set the 2nd commit to \"edit\":\n>\n> pick 4th commit\n> pick 3rd commit\n> 2nd commit <-- YOU ARE HERE\n> 1st commit\n>\n> This is great, but ...\n\nStepping a bit, how does our \"git status\" fare here? It shows what\nstep in a sequence \"rebase -i\" the user who got control back (due to\n\"break\", \"exec sh\", \"edit\" or a conflicted \"pick\") is in. Or at\nleast it tries to. Does it suffer from the same \"great, but ...\"?\n\nIf it works better than how lazygit shows, perhaps how it computes\nthe current state can be reproduced, or better yet, the current\nstate it computed can be exposed, and it can be prototyped by\nparsing \"LC_ALL=C git status -uno\" output, perhaps?\n"},{"id":"473210","messageId":"28b78355-e3db-d33a-c576-653740a4a1f3@haller-berlin.de","threadId":"59321","inReplyTo":"xmqqo7p4zb8d.fsf@gitster.g","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-08T19:02:26Z","receivedAt":"2023-03-08T19:03:23Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 07.03.23 19:07, Junio C Hamano wrote:\n> Stefan Haller writes:\n> \n>> The reason why I am asking this is: I'm using lazygit, which, during\n>> interactive rebases, shows a combined view of the real commits that were\n>> already applied, and the remaining commits that are yet to be applied\n>> (it gets these by parsing rebase-merge/git-rebase-todo); something like\n>> this, when I set the 2nd commit to \"edit\":\n>>\n>> pick 4th commit\n>> pick 3rd commit\n>> 2nd commit <-- YOU ARE HERE\n>> 1st commit\n>>\n>> This is great, but ...\n> \n> Stepping a bit, how does our \"git status\" fare here? It shows what\n> step in a sequence \"rebase -i\" the user who got control back (due to\n> \"break\", \"exec sh\", \"edit\" or a conflicted \"pick\") is in. Or at\n> least it tries to. Does it suffer from the same \"great, but ...\"?\n> \n> If it works better than how lazygit shows, perhaps how it computes\n> the current state can be reproduced, or better yet, the current\n> state it computed can be exposed, and it can be prototyped by\n> parsing \"LC_ALL=C git status -uno\" output, perhaps?\n\nIt fares a little better, but not much, and it doesn't look like I can\nuse its information to implement the behavior I want.\n\nThe difference to lazygit is that git status shows both the last few\nentries of the \"done\" file and the first few entries of the\n\"git-rebase-todo\" file, so at least I have a complete picture of which\ncommits are involved. Lazygit doesn't show the \"done\" file, only the\ncommits that are on the branch now, so the currently conflicting commit\nis missing.\n\nIn addition, git status shows the message \"(fix conflicts and then run\n\"git rebase --continue\")\", but only if there are unmerged files; once I\nresolve all conflicts and stage the changes, that message is no longer\nshown, and at that point I don't see any way to tell whether the last\ncommit was applied successfully or not.\n\n-Stefan\n"},{"id":"473211","messageId":"4d13d02a-ddaf-7b8f-7a27-c7a030816523@haller-berlin.de","threadId":"59321","inReplyTo":"18763465-de3b-7e64-129b-1f9337ea1924@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-08T19:02:17Z","receivedAt":"2023-03-08T19:03:26Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 05.03.23 21:15, Phillip Wood wrote:\n> Hi Stefan\n> \n> On 05/03/2023 19:13, Stefan Haller wrote:\n>> On 05.03.23 17:59, Stefan Haller wrote:\n>>> On 05.03.23 15:31, Phillip Wood wrote:\n>>>> Hi Stefan\n>>>>\n>>>> On 02/03/2023 20:27, Stefan Haller wrote:\n>>>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>>>>> interactive rebases, shows a combined view of the real commits that\n>>>>>>> were\n>>>>>>> already applied, and the remaining commits that are yet to be\n>>>>>>> applied\n>>>>>>> (it gets these by parsing rebase-merge/git-rebase-todo);\n>>>>>>> something like\n>>>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>>>\n>>>>>>>      pick   4th commit\n>>>>>>>      pick   3rd commit\n>>>>>>>             2nd commit  <-- YOU ARE HERE\n>>>>>>>             1st commit\n>>>>>>>\n>>>>>>> This is great, but assuming that the 2nd commit conflicted,\n>>>>>>> currently\n>>>>>>> the display looks like this:\n>>>>>>>\n>>>>>>>      pick   4th commit\n>>>>>>>      pick   3rd commit\n>>>>>>>             1st commit  <-- YOU ARE HERE\n>>>>>>>\n>>>>>>> I would like to extend this to also show a \"fake entry\" for the\n>>>>>>> commit\n>>>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>>>> except that I need a way to distinguish whether it was applied\n>>>>>>> already\n>>>>>>> or not.\n>>>>>>\n>>>>>> Can you check the index for conflicts when the rebase stops?\n>>>>>\n>>>>> I could do that, but then the fake entry would go away as soon as I\n>>>>> have\n>>>>> staged all conflict resolutions. I would find it useful for it to stay\n>>>>> visible in that case, until I continue the rebase.\n>>>>\n>>>> I've not used lazygit but looking at the github page it seems that\n>>>> it is\n>>>> a persistent process that runs \"git rebase\". If that's the case I would\n>>>> think that you can check for conflicts when the rebase stops and keep\n>>>> that value in memory until the rebase is started again.\n>>>\n>>> I had considered that, but it would be preferable if it were possible to\n>>> quit lazygit, start it again, and have it show the same state again. Or\n>>> even start the rebase outside of lazygit while it isn't running at all,\n>>> and then start it and have it display the correct state.\n>>>\n>>>> I think your best bet might be to read \"$(git rev-parse --git-path\n>>>> rebase-merge/done)\" the last line of which contains the last todo\n>>>> command the rebase tried to execute.\n>>>\n>>> I'm not sure I understand; you mean in order to distinguish whether it\n>>> was a pick or a fixup?\n>>\n>> OK, I guess it's something like\n>>\n>> show_fake_entry :=\n>>    REBASE_HEAD exists\n>>    && (last command in \"done\" file was not \"edit\"\n>>        || \"amend\" file exists)\n>>\n>> Is that what you meant? (Minus the bit about rescheduling failed\n>> commands, which I still need to wrap my head around...)\n> \n> I meant you could just use the done file to get the last command, there\n> is no need to look at REBASE_HEAD.\n\nOK, I see. Sounds like a possible algorithm could be:\n\nfunc commitNameToShowAsTheCurrentlyConflictingCommit() {\n lastDone := last command of \"done\" file\n if lastDone.command is \"break\" or \"exec\" {\n return nil\n }\n\n next := first command of \"git-rebase-todo\" file\n if lastDone == next {\n // Command was rescheduled and shows in remaining todos already\n return nil\n }\n\n if lastDone.command is \"edit\" {\n if \"amend\" file exists {\n // \"edit\" command was successful\n return nil\n }\n }\n\n return lastDone.commitName\n}\n\nDoes this sound reasonable?\n\n-Stefan\n"},{"id":"473217","messageId":"xmqqa60nt4jd.fsf@gitster.g","threadId":"59321","inReplyTo":"28b78355-e3db-d33a-c576-653740a4a1f3@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-08T19:40:54Z","receivedAt":"2023-03-08T19:41:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Haller writes:\n\n> On 07.03.23 19:07, Junio C Hamano wrote:\n> ...\n>> Stepping a bit, how does our \"git status\" fare here? It shows what\n>> step in a sequence \"rebase -i\" the user who got control back (due to\n>> \"break\", \"exec sh\", \"edit\" or a conflicted \"pick\") is in. Or at\n>> least it tries to. Does it suffer from the same \"great, but ...\"?\n>> ...\n>\n> It fares a little better, but not much, and it doesn't look like I can\n> use its information to implement the behavior I want.\n\nThanks. That is the kind of information I was trying to find. It\nmeans that the current \"git status\" does not give our users enough\nclue as to where in their \"rebase -i\" session they are at, and we\nwill help more users by teaching \"git status\" the trick you are\ndesigning. Instead of peeking into how the implementation details\nlike REBASE_HEAD currently happen to work, making sure underlying\n\"git\" knows how to present the information you want and letting it\nperform the heavy lifting would make sure the solution will stay\nsupported across versions of future git.\n\n\n\n"},{"id":"473286","messageId":"7a79f579-651c-2fae-124e-66a10b4784a1@haller-berlin.de","threadId":"59321","inReplyTo":"xmqqa60nt4jd.fsf@gitster.g","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-09T14:45:03Z","receivedAt":"2023-03-09T14:55:49Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 08.03.23 20:40, Junio C Hamano wrote:\n> Stefan Haller writes:\n> \n>> On 07.03.23 19:07, Junio C Hamano wrote:\n>> ...\n>>> Stepping a bit, how does our \"git status\" fare here? It shows what\n>>> step in a sequence \"rebase -i\" the user who got control back (due to\n>>> \"break\", \"exec sh\", \"edit\" or a conflicted \"pick\") is in. Or at\n>>> least it tries to. Does it suffer from the same \"great, but ...\"?\n>>> ...\n>>\n>> It fares a little better, but not much, and it doesn't look like I can\n>> use its information to implement the behavior I want.\n> \n> Thanks. That is the kind of information I was trying to find. It\n> means that the current \"git status\" does not give our users enough\n> clue as to where in their \"rebase -i\" session they are at, and we\n> will help more users by teaching \"git status\" the trick you are\n> designing. Instead of peeking into how the implementation details\n> like REBASE_HEAD currently happen to work, making sure underlying\n> \"git\" knows how to present the information you want and letting it\n> perform the heavy lifting would make sure the solution will stay\n> supported across versions of future git.\n\nYes; as I said over in the other branch of this thread, I agree that it\nwould be great to have this in status, but I'm afraid I'm not the one to\ndrive the work to get it in there. I don't have the capacity to\ncontribute to yet another open source project.\n\nIf somebody else wanted to take this on, I'd be happy to join any design\ndiscussions, or do early testing to see if whatever is being added works\nfor my use case.\n\n-Stefan\n"},{"id":"473350","messageId":"722659e9-02ac-a9d2-b0fd-b9a2a3d85753@dunelm.org.uk","threadId":"59321","inReplyTo":"4d13d02a-ddaf-7b8f-7a27-c7a030816523@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-10T09:56:28Z","receivedAt":"2023-03-10T09:56:41Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 08/03/2023 19:02, Stefan Haller wrote:\n> On 05.03.23 21:15, Phillip Wood wrote:\n>> Hi Stefan\n>>\n>> On 05/03/2023 19:13, Stefan Haller wrote:\n>>> On 05.03.23 17:59, Stefan Haller wrote:\n>>>> On 05.03.23 15:31, Phillip Wood wrote:\n>>>>> Hi Stefan\n>>>>>\n>>>>> On 02/03/2023 20:27, Stefan Haller wrote:\n>>>>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>>>>> The reason why I am asking this is: I'm using lazygit, which, during\n>>>>>>>> interactive rebases, shows a combined view of the real commits that\n>>>>>>>> were\n>>>>>>>> already applied, and the remaining commits that are yet to be\n>>>>>>>> applied\n>>>>>>>> (it gets these by parsing rebase-merge/git-rebase-todo);\n>>>>>>>> something like\n>>>>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>>>>\n>>>>>>>>      pick   4th commit\n>>>>>>>>      pick   3rd commit\n>>>>>>>>             2nd commit  <-- YOU ARE HERE\n>>>>>>>>             1st commit\n>>>>>>>>\n>>>>>>>> This is great, but assuming that the 2nd commit conflicted,\n>>>>>>>> currently\n>>>>>>>> the display looks like this:\n>>>>>>>>\n>>>>>>>>      pick   4th commit\n>>>>>>>>      pick   3rd commit\n>>>>>>>>             1st commit  <-- YOU ARE HERE\n>>>>>>>>\n>>>>>>>> I would like to extend this to also show a \"fake entry\" for the\n>>>>>>>> commit\n>>>>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>>>>> except that I need a way to distinguish whether it was applied\n>>>>>>>> already\n>>>>>>>> or not.\n> OK, I see. Sounds like a possible algorithm could be:\n> \n> func commitNameToShowAsTheCurrentlyConflictingCommit() {\n\nGoing back to your original email, if all you want to do is show \"YOU \nARE HERE\" against the correct commit then you can get that from the last \nentry in the \"done\" file irrespective of whether there were conflicts or \nnot. If you also want to show whether it was picked cleanly or not then \nit is more complicated.\n\n> lastDone := last command of \"done\" file\n> if lastDone.command is \"break\" or \"exec\" {\n> return nil\n> }\n> \n> next := first command of \"git-rebase-todo\" file\n> if lastDone == next {\n> // Command was rescheduled and shows in remaining todos already\n> return nil\n> }\n\nI don't know what your current implementation looks like but if I was \nstarting from scratch I think it would be simpler to always use the last \ncommand from \"done\" and then suppress the first command from \n\"git-rebase-todo\" if it is the same. That way the \"YOU ARE HERE\" always \nmarks the last command from \"done\"\n\n> if lastDone.command is \"edit\" {\n> if \"amend\" file exists {\n> // \"edit\" command was successful\n> return nil\n> }\n> }\n\nIf you need to know if the pick was successful or not then that should \ntell you, but if all you need to know is which commit the rebase stopped \non then you don't need this.\n\nBest Wishes\n\nPhillip\n\n\n> return lastDone.commitName\n> }\n> \n> Does this sound reasonable?\n\n"},{"id":"473371","messageId":"805626af-b147-d3cf-5257-a5b90b7cf1d9@haller-berlin.de","threadId":"59321","inReplyTo":"722659e9-02ac-a9d2-b0fd-b9a2a3d85753@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-10T17:42:03Z","receivedAt":"2023-03-10T17:49:43Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 10.03.23 10:56, Phillip Wood wrote:\n> Hi Stefan\n> \n> On 08/03/2023 19:02, Stefan Haller wrote:\n>> On 05.03.23 21:15, Phillip Wood wrote:\n>>> Hi Stefan\n>>>\n>>> On 05/03/2023 19:13, Stefan Haller wrote:\n>>>> On 05.03.23 17:59, Stefan Haller wrote:\n>>>>> On 05.03.23 15:31, Phillip Wood wrote:\n>>>>>> Hi Stefan\n>>>>>>\n>>>>>> On 02/03/2023 20:27, Stefan Haller wrote:\n>>>>>>> On 02.03.23 11:19, Phillip Wood wrote:\n>>>>>>>> On 28/02/2023 12:55, Stefan Haller wrote:\n>>>>>>>>> The reason why I am asking this is: I'm using lazygit, which,\n>>>>>>>>> during\n>>>>>>>>> interactive rebases, shows a combined view of the real commits\n>>>>>>>>> that\n>>>>>>>>> were\n>>>>>>>>> already applied, and the remaining commits that are yet to be\n>>>>>>>>> applied\n>>>>>>>>> (it gets these by parsing rebase-merge/git-rebase-todo);\n>>>>>>>>> something like\n>>>>>>>>> this, when I set the 2nd commit to \"edit\":\n>>>>>>>>>\n>>>>>>>>>       pick   4th commit\n>>>>>>>>>       pick   3rd commit\n>>>>>>>>>              2nd commit  <-- YOU ARE HERE\n>>>>>>>>>              1st commit\n>>>>>>>>>\n>>>>>>>>> This is great, but assuming that the 2nd commit conflicted,\n>>>>>>>>> currently\n>>>>>>>>> the display looks like this:\n>>>>>>>>>\n>>>>>>>>>       pick   4th commit\n>>>>>>>>>       pick   3rd commit\n>>>>>>>>>              1st commit  <-- YOU ARE HERE\n>>>>>>>>>\n>>>>>>>>> I would like to extend this to also show a \"fake entry\" for the\n>>>>>>>>> commit\n>>>>>>>>> that conflicted, if there is one. REBASE_HEAD is perfect for this,\n>>>>>>>>> except that I need a way to distinguish whether it was applied\n>>>>>>>>> already\n>>>>>>>>> or not.\n>> OK, I see. Sounds like a possible algorithm could be:\n>>\n>> func commitNameToShowAsTheCurrentlyConflictingCommit() {\n> \n> Going back to your original email, if all you want to do is show \"YOU\n> ARE HERE\" against the correct commit then you can get that from the last\n> entry in the \"done\" file irrespective of whether there were conflicts or\n> not. If you also want to show whether it was picked cleanly or not then\n> it is more complicated.\n\nIn my first example above, I'm editing the 2nd commit and it applied\ncleanly. What I see in that case is\n\npick 4th commit\npick 3rd commit\n 2nd commit <-- YOU ARE HERE\n 1st commit\n\n2nd commit is the current HEAD, which corresponds to the last entry in\nthe \"done\" file, so there's no reason to display the \"done\" file entry\ntoo in this case.\n\nOnly if it wasn't applied cleanly (and wasn't rescheduled) do I want to\nshow the \"done\" entry. This way I always see four entries in my list, no\nmatter what happened (unless I drop commits, of course), which is what I\nwant.\n\n>>      lastDone := last command of \"done\" file\n>>      if lastDone.command is \"break\" or \"exec\" {\n>>          return nil\n>>      }\n>>\n>>      next := first command of \"git-rebase-todo\" file\n>>      if lastDone == next {\n>>          // Command was rescheduled and shows in remaining todos already\n>>          return nil\n>>      }\n> \n> I don't know what your current implementation looks like but if I was\n> starting from scratch I think it would be simpler to always use the last\n> command from \"done\" and then suppress the first command from\n> \"git-rebase-todo\" if it is the same.\n\nThat would also be possible, but in lazygit it makes things harder,\nbecause items from \"git-rebase-todo\" can be interacted with (e.g. moved\nup or down, or dropped), whereas the \"done\" entry is only for display\npurposes and can't be interacted with. That's why I called it a \"fake\"\nentry above.\n\nI tried the algorithm now and seems to do exactly what I want, so thanks\nfor the help with this, I'm happy now.\n\nThere's a slight correction though: if a command is rescheduled, then\ngit appears to re-append the last successful command to the end of the\n\"done\" file (it's in there twice now). So I have to check the\nsecond-to-last command of \"done\" against the first command of\n\"git-rebase-todo\" to find out if a command was rescheduled.\n\n-Stefan\n"},{"id":"473603","messageId":"f7577c57-f70d-cca3-3f25-18525d40d79b@dunelm.org.uk","threadId":"59321","inReplyTo":"805626af-b147-d3cf-5257-a5b90b7cf1d9@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-16T17:46:15Z","receivedAt":"2023-03-16T17:46:39Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 10/03/2023 17:42, Stefan Haller wrote:\n> I tried the algorithm now and seems to do exactly what I want, so thanks\n> for the help with this, I'm happy now.\n\nI'm glad you've got something working\n\n> There's a slight correction though: if a command is rescheduled, then\n> git appears to re-append the last successful command to the end of the\n> \"done\" file (it's in there twice now). So I have to check the > second-to-last command of \"done\" against the first command of\n> \"git-rebase-todo\" to find out if a command was rescheduled.\n\nOh, sorry I'd misremembered how it works. I think it is actually a bug \nthat we write the last successful command to \"done\" again when \nrescheduling but it sounds like you have a reliable work-around.\n\nBest Wishes\n\nPhillip\n\n> -Stefan\n"},{"id":"473731","messageId":"0eb3ed02-139a-b114-939a-d2ad286af743@dunelm.org.uk","threadId":"59321","inReplyTo":"f7577c57-f70d-cca3-3f25-18525d40d79b@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-03-19T14:50:03Z","receivedAt":"2023-03-19T14:50:14Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Stefan\n\nOn 16/03/2023 17:46, Phillip Wood wrote:\n> Hi Stefan\n> \n> On 10/03/2023 17:42, Stefan Haller wrote:\n>> I tried the algorithm now and seems to do exactly what I want, so thanks\n>> for the help with this, I'm happy now.\n> \n> I'm glad you've got something working\n> \n>> There's a slight correction though: if a command is rescheduled, then\n>> git appears to re-append the last successful command to the end of the\n>> \"done\" file (it's in there twice now). So I have to check the > \n>> second-to-last command of \"done\" against the first command of\n>> \"git-rebase-todo\" to find out if a command was rescheduled.\n> \n> Oh, sorry I'd misremembered how it works. I think it is actually a bug \n> that we write the last successful command to \"done\" again when \n> rescheduling but it sounds like you have a reliable work-around.\n\nHmm, I think it is a bit complicated to do this reliably as if \"pick B\" \nhas conflicts and git-rebase-todo contains\n\n\texec make test\n\nand done contains\n\n\tpick A\n\texec make test\n\tpick B\n\nit looks like \"exec make test\" has been rescheduled when in fact \"pick \nB\" failed with conflicts. If you look at the last three lines of \"done\" \nyou can distinguish the two cases but it is a bit of a faff. I've \nsubmitted a bugfix at \nhttps://lore.kernel.org/git/pull.1492.git.1679237337683.gitgitgadget@gmail.com\n\nBest Wishes\n\nPhillip\n\n> Best Wishes\n> \n> Phillip\n> \n>> -Stefan\n"},{"id":"473748","messageId":"1e943dab-23c7-9eed-df4c-c89084d2387b@haller-berlin.de","threadId":"59321","inReplyTo":"0eb3ed02-139a-b114-939a-d2ad286af743@dunelm.org.uk","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-20T07:29:07Z","receivedAt":"2023-03-20T07:29:17Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 19.03.23 15:50, Phillip Wood wrote:\n> Hmm, I think it is a bit complicated to do this reliably as if \"pick B\"\n> has conflicts and git-rebase-todo contains\n> \n>     exec make test\n> \n> and done contains\n> \n>     pick A\n>     exec make test\n>     pick B\n> \n> it looks like \"exec make test\" has been rescheduled when in fact \"pick\n> B\" failed with conflicts. If you look at the last three lines of \"done\"\n> you can distinguish the two cases but it is a bit of a faff.\n\nAh, thanks for coming up with this tricky case. I'm leaning towards\nsimply ignoring it, since (at least for my usage of git) it's very\nuncommon; if I use \"-x make test\" to check all commits, I almost always\ndo that in place, so I won't get conflicts.\n\nBut it's one more argument for adding the information to git status, I\nsuppose.\n\n-Stefan\n"},{"id":"473750","messageId":"66bcf561-b604-db2b-fa0c-fa9fbc379562@haller-berlin.de","threadId":"59321","inReplyTo":"1e943dab-23c7-9eed-df4c-c89084d2387b@haller-berlin.de","subject":"Re: When exactly should REBASE_HEAD exist?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2023-03-20T08:42:18Z","receivedAt":"2023-03-20T08:42:26Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 20.03.23 08:29, Stefan Haller wrote:\n> Ah, thanks for coming up with this tricky case. I'm leaning towards\n> simply ignoring it, since (at least for my usage of git) it's very\n> uncommon; if I use \"-x make test\" to check all commits, I almost always\n> do that in place, so I won't get conflicts.\n\nOn the other hand, it seems easy enough to do it properly, so why not.\nSomething like this:\n\n num_done := len(done)\n is_rescheduled :=\n # for new versions of git:\n done[num_done - 1] == todo[0]\n # for older versions of git:\n || (num_done >= 3\n && done[num_done - 2] == todo[0]\n && done[num_done - 1] == done[num_done - 3])\n\nCould I be missing any other cases with this logic?\n\n-Stefan\n"}]}