{"thread":{"id":"50941","subject":"Generating a todo file for non-interactive rebasing","startedAt":"2019-04-16T15:44:45Z","lastAt":"2019-04-17T17:11:24Z","messageCount":4,"participants":["Drew DeVault","Phillip Wood","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"373979","messageId":"20190416153709.GA19000@homura.localdomain","threadId":"50941","inReplyTo":null,"subject":"Generating a todo file for non-interactive rebasing","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2019-04-16T15:37:10Z","receivedAt":"2019-04-16T15:44:45Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Hiya!\n\nWhenever I do a particularly long rebase on a branch, sorting out\nconflicts from upstream, I find that it's often useful to have the\nadditional context that you get during an interactive rebase, such as\nrecent commands run, commands planned to run, and so on, to get a better\nidea of where I'm at during the rebase. These show when you run `git\nstatus` during an interactive rebase.\n\nHowever, the code that generates this report relies on a todo list being\ngenerated in the rebase state directory. A todo list which consists only\nof \"pick\" commands is functionally equivalent to a non-interactive\nrebase, the only difference being that the editor isn't shown to the\nuser.\n\nIs there any reason not to refactor the rebase command to always\ngenerate a todo list? This would simplify the internals and provide more\ncontext to the user during hairy rebases. It might also be useful to run\n--edit-todo if you realize your rebase strategy needs to change partway\nthrough a rebase which was initially non-interactive.\n\nNote: I'm a non-subscriber, please Cc me on replies.\n\n-- \nDrew DeVault\n"},{"id":"374050","messageId":"07e0259b-0d7a-b109-cd3c-ccfbf17ad573@gmail.com","threadId":"50941","inReplyTo":"20190416153709.GA19000@homura.localdomain","subject":"Re: Generating a todo file for non-interactive rebasing","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-04-17T14:59:12Z","receivedAt":"2019-04-17T14:59:19Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Drew\n\nOn 16/04/2019 16:37, Drew DeVault wrote:\n> Hiya!\n> \n> Whenever I do a particularly long rebase on a branch, sorting out\n> conflicts from upstream, I find that it's often useful to have the\n> additional context that you get during an interactive rebase, such as\n> recent commands run, commands planned to run, and so on, to get a better\n> idea of where I'm at during the rebase. These show when you run `git\n> status` during an interactive rebase.\n> \n> However, the code that generates this report relies on a todo list being\n> generated in the rebase state directory. A todo list which consists only\n> of \"pick\" commands is functionally equivalent to a non-interactive\n> rebase, the only difference being that the editor isn't shown to the\n> user.\n> \n> Is there any reason not to refactor the rebase command to always\n> generate a todo list? This would simplify the internals and provide more\n> context to the user during hairy rebases. It might also be useful to run\n> --edit-todo if you realize your rebase strategy needs to change partway\n> through a rebase which was initially non-interactive.\n\nThings are moving in that direction. Currently --merge, --keep-empty, \n--recreate-merges and --exec will result in a todo list being used \nregardless of --interactive. There was some discussion a couple of \nmonths ago about making --merge the default if there were no am specific \noptions given but I've not noticed a patch for that yet. There is also a \nGSoC project that will implement some of the am specific options for the \ninteractive backend with the long term aim of removing the am based backend.\n\nBest Wishes\n\nPhillip\n> \n> Note: I'm a non-subscriber, please Cc me on replies.\n> \n"},{"id":"374055","messageId":"nycvar.QRO.7.76.6.1904171754060.46@tvgsbejvaqbjf.bet","threadId":"50941","inReplyTo":"20190416153709.GA19000@homura.localdomain","subject":"Re: Generating a todo file for non-interactive rebasing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-04-17T16:11:21Z","receivedAt":"2019-04-17T16:11:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Drew,\n\nOn Tue, 16 Apr 2019, Drew DeVault wrote:\n\n> Whenever I do a particularly long rebase on a branch, sorting out\n> conflicts from upstream, I find that it's often useful to have the\n> additional context that you get during an interactive rebase, such as\n> recent commands run, commands planned to run, and so on, to get a better\n> idea of where I'm at during the rebase. These show when you run `git\n> status` during an interactive rebase.\n>\n> However, the code that generates this report relies on a todo list being\n> generated in the rebase state directory. A todo list which consists only\n> of \"pick\" commands is functionally equivalent to a non-interactive\n> rebase, the only difference being that the editor isn't shown to the\n> user.\n>\n> Is there any reason not to refactor the rebase command to always\n> generate a todo list? This would simplify the internals and provide more\n> context to the user during hairy rebases. It might also be useful to run\n> --edit-todo if you realize your rebase strategy needs to change partway\n> through a rebase which was initially non-interactive.\n\nThe default mode of the rebase command is actually not based on picks, but\ninternally generates mails, puts them into an mbox, and then pretends to\napply those patches from a mailing list.\n\nThat mode is obviously very different from the interactive rebase, so\nthere is not quite the simplification in store that you hoped for.\n\nHowever, we recently changed the way the --merge backend works, and it is\nnow indeed backed by the same machinery as the interactive rebase.\nMeaning: if you call `git rebase -m <options>...`, you have what you\nwished for. This change is part of v2.21.0.\n\nTo my surprise, Elijah Newren (who authored that change) then demonstrated\nthat in most cases, the `--merge` backend is actually *faster* than the\ndefault (`--am`) backend. There were patches floating around to make it\nthe default rebase backend for that reason, but those patches were not\npicked up yet.\n\nShort version: if you add `--merge` or `-m` to your `git rebase`\ninvocations, you already get what you want.\n\nCiao,\nJohannes\n"},{"id":"374058","messageId":"20190417171118.GC1178@homura.localdomain","threadId":"50941","inReplyTo":"nycvar.QRO.7.76.6.1904171754060.46@tvgsbejvaqbjf.bet","subject":"Re: Generating a todo file for non-interactive rebasing","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2019-04-17T17:11:19Z","receivedAt":"2019-04-17T17:11:24Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Thanks for clarifying this, folks.\n\nOn 2019-04-17  6:11 PM, Johannes Schindelin wrote:\n> To my surprise, Elijah Newren (who authored that change) then demonstrated\n> that in most cases, the `--merge` backend is actually *faster* than the\n> default (`--am`) backend. There were patches floating around to make it\n> the default rebase backend for that reason, but those patches were not\n> picked up yet.\n\nWould be cool to see these picked up.\n"}]}