{"thread":{"id":"52637","subject":"en/rebase-backend (was Re: \"rebase -ri\" (was Re: Problems with ra/rebase-i-more-options - should we revert it?))","startedAt":"2020-01-14T16:53:11Z","lastAt":"2020-01-14T21:26:24Z","messageCount":3,"participants":["Elijah Newren","Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"389749","messageId":"CABPp-BG9eqbhnzU8gzJ_h+=XH4mSOj-Wb5SU7OjXz5ik6c+NnQ@mail.gmail.com","threadId":"52637","inReplyTo":null,"subject":"en/rebase-backend (was Re: \"rebase -ri\" (was Re: Problems with ra/rebase-i-more-options - should we revert it?))","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-01-14T16:52:57Z","receivedAt":"2020-01-14T16:53:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Junio,\n\nOn Mon, Jan 13, 2020 at 2:07 PM Junio C Hamano wrote:\n>\n> Junio C Hamano writes:\n>\n> > Junio C Hamano writes:\n> >\n> >> I will push out what I wish to be able to tag as the final [*1*]\n> >> shortly but without actually tagging, so that it can get a bit wider\n> >> exposure than just the usual \"Gitster tested locally and then did\n> >> let Travis try them\" testing.\n> >\n> > I haven't heard from any failure report so (taking no news as good\n> > news) I'll cut the final today based on what is already on the\n> > public repositories everywhere.\n>\n> By the way, as one of the methods to double check that my result of\n> reverting the merge made sense, I ran \"git rebase -ri v2.24.0 pu\"\n> and excised the merge and the problematic topic out of the todo\n> list. With the rerere database populated beforehand, it was more or\n> less a painless exercise (except for one topic, en/rebase-backend,\n> which is one of the topics that was queued forking 'master' after\n> the topic got merged *and* actually depended on what the topic did)\n> and after about 1700+ steps (which did not take more than 20\n> minutes, including the time spent for the manual rebasing of\n> en/rebase-backend topic) I got the same tree for 'pu' I pushed out\n> last night.\n\nI wonder if I should have been the one fixing up the en/rebase-backend topic...\n\nAlso, with the new release and the review comments Phillip posted on\nthe en/rebase-backend series, would you rather see me address those as\nadditional patches on top of en/rebase-backend, or should we kick that\ntopic out of next and have me send a full re-roll? I'm not sure\nwhat'd be better and I don't mind going either direction...\n"},{"id":"389777","messageId":"20200114205651.GA74460@google.com","threadId":"52637","inReplyTo":"CABPp-BG9eqbhnzU8gzJ_h+=XH4mSOj-Wb5SU7OjXz5ik6c+NnQ@mail.gmail.com","subject":"Re: en/rebase-backend (was Re: \"rebase -ri\" (was Re: Problems with ra/rebase-i-more-options - should we revert it?))","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2020-01-14T20:59:26Z","receivedAt":"2020-01-14T20:59:34Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Tue, Jan 14, 2020 at 08:52:57AM -0800, Elijah Newren wrote:\n> Hi Junio,\n> \n> On Mon, Jan 13, 2020 at 2:07 PM Junio C Hamano wrote:\n> >\n> > Junio C Hamano writes:\n> >\n> > > Junio C Hamano writes:\n> > >\n> > >> I will push out what I wish to be able to tag as the final [*1*]\n> > >> shortly but without actually tagging, so that it can get a bit wider\n> > >> exposure than just the usual \"Gitster tested locally and then did\n> > >> let Travis try them\" testing.\n> > >\n> > > I haven't heard from any failure report so (taking no news as good\n> > > news) I'll cut the final today based on what is already on the\n> > > public repositories everywhere.\n> >\n> > By the way, as one of the methods to double check that my result of\n> > reverting the merge made sense, I ran \"git rebase -ri v2.24.0 pu\"\n> > and excised the merge and the problematic topic out of the todo\n> > list. With the rerere database populated beforehand, it was more or\n> > less a painless exercise (except for one topic, en/rebase-backend,\n> > which is one of the topics that was queued forking 'master' after\n> > the topic got merged *and* actually depended on what the topic did)\n> > and after about 1700+ steps (which did not take more than 20\n> > minutes, including the time spent for the manual rebasing of\n> > en/rebase-backend topic) I got the same tree for 'pu' I pushed out\n> > last night.\n> \n> I wonder if I should have been the one fixing up the en/rebase-backend topic...\n> \n> Also, with the new release and the review comments Phillip posted on\n> the en/rebase-backend series, would you rather see me address those as\n> additional patches on top of en/rebase-backend, or should we kick that\n> topic out of next and have me send a full re-roll? I'm not sure\n> what'd be better and I don't mind going either direction...\n\n\nFor what it's worth, I had started to look into one of the bugs Jonathan\nNieder reported[1] as a patch on top of en/rebase-backend topic. I'll\nkeep an eye on this thread; if you're interested in rerolling the whole\ntopic then it might be less time for you to identify the right place to\ncall \"post-commit\" than it would be for me, plus less conflict\nresolution time.\n\n[1]: https://lore.kernel.org/git/20200110231436.GA24315@google.com/\n(bullet point 1)\n\n - Emily\n"},{"id":"389783","messageId":"CABPp-BECzff3tWNSJU2YNmNxSW1f=SDnoPQpRHKtQ-Moba+mRQ@mail.gmail.com","threadId":"52637","inReplyTo":"20200114205651.GA74460@google.com","subject":"Re: en/rebase-backend (was Re: \"rebase -ri\" (was Re: Problems with ra/rebase-i-more-options - should we revert it?))","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-01-14T21:26:10Z","receivedAt":"2020-01-14T21:26:24Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Emily,\n\nOn Tue, Jan 14, 2020 at 12:59 PM Emily Shaffer wrote:\n>\n> On Tue, Jan 14, 2020 at 08:52:57AM -0800, Elijah Newren wrote:\n> > Hi Junio,\n> >\n> > On Mon, Jan 13, 2020 at 2:07 PM Junio C Hamano wrote:\n> > >\n> > > Junio C Hamano writes:\n> > >\n> > > > Junio C Hamano writes:\n> > > >\n> > > >> I will push out what I wish to be able to tag as the final [*1*]\n> > > >> shortly but without actually tagging, so that it can get a bit wider\n> > > >> exposure than just the usual \"Gitster tested locally and then did\n> > > >> let Travis try them\" testing.\n> > > >\n> > > > I haven't heard from any failure report so (taking no news as good\n> > > > news) I'll cut the final today based on what is already on the\n> > > > public repositories everywhere.\n> > >\n> > > By the way, as one of the methods to double check that my result of\n> > > reverting the merge made sense, I ran \"git rebase -ri v2.24.0 pu\"\n> > > and excised the merge and the problematic topic out of the todo\n> > > list. With the rerere database populated beforehand, it was more or\n> > > less a painless exercise (except for one topic, en/rebase-backend,\n> > > which is one of the topics that was queued forking 'master' after\n> > > the topic got merged *and* actually depended on what the topic did)\n> > > and after about 1700+ steps (which did not take more than 20\n> > > minutes, including the time spent for the manual rebasing of\n> > > en/rebase-backend topic) I got the same tree for 'pu' I pushed out\n> > > last night.\n> >\n> > I wonder if I should have been the one fixing up the en/rebase-backend topic...\n> >\n> > Also, with the new release and the review comments Phillip posted on\n> > the en/rebase-backend series, would you rather see me address those as\n> > additional patches on top of en/rebase-backend, or should we kick that\n> > topic out of next and have me send a full re-roll? I'm not sure\n> > what'd be better and I don't mind going either direction...\n>\n>\n> For what it's worth, I had started to look into one of the bugs Jonathan\n> Nieder reported[1] as a patch on top of en/rebase-backend topic. I'll\n> keep an eye on this thread; if you're interested in rerolling the whole\n> topic then it might be less time for you to identify the right place to\n> call \"post-commit\" than it would be for me, plus less conflict\n> resolution time.\n>\n> [1]: https://lore.kernel.org/git/20200110231436.GA24315@google.com/\n> (bullet point 1)\n\nOoh, that'd be great if you could fix the post-commit piece,\nespecially since you're more familiar with the hooks in general and\nprobably have access to the actual usecases where people are using\npost-commit hooks.\n\nI am planning on rerolling the topic, but I'd be happy to insert a\npatch authored by you into the series. Or maybe it'd be even better\nto just merge them as totally independent series -- I strongly doubt\nthere would be any conflicts. I didn't touch the am codepaths in\nen/rebase-backend (any am codepaths I touched were submitted\nseparately and already made it into v2.25.0), and since the resolution\nof the post-commit hook sounded like it should be modifying 'am' to\nbehave like the merge/interactive backends (as per Junio's\ncomments[2]), the fix should be orthogonal to the rest of\nen/rebase-backend.\n\n[2] https://lore.kernel.org/git/xmqqa76sl67u.fsf@gitster-ct.c.googlers.com/\n"}]}