Hi Junio, On Mon, 13 Jan 2020, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > >> I will push out what I wish to be able to tag as the final [*1*] > >> shortly but without actually tagging, so that it can get a bit wider > >> exposure than just the usual "Gitster tested locally and then did let > >> Travis try them" testing. > > > > I haven't heard from any failure report so (taking no news as good > > news) I'll cut the final today based on what is already on the public > > repositories everywhere. > > By the way, as one of the methods to double check that my result of > reverting the merge made sense, I ran "git rebase -ri v2.24.0 pu" > and excised the merge and the problematic topic out of the todo > list. With the rerere database populated beforehand, it was more or > less a painless exercise (except for one topic, en/rebase-backend, > which is one of the topics that was queued forking 'master' after > the topic got merged *and* actually depended on what the topic did) > and after about 1700+ steps (which did not take more than 20 > minutes, including the time spent for the manual rebasing of > en/rebase-backend topic) I got the same tree for 'pu' I pushed out > last night. Nice! > One thing I noticed that "rebase -ri" could be taught to handle > better was that the side branches that were merged to the final > result did not get relabeled. Those merges that appear on the first > parent chain leading to 'pu' call themselves as "Merge branch 'blah'" > and many of them (i.e. the ones that forked before the merge of the > topic getting excised from the mainline) did just merge the tip of > the named branch without touching the commits on the side branch, > but some branches did have to be rebased, but their tips did not get > updated (only the tentative rewritten/<topic> labels were pointing > at the updated tip during the rebase, which are of course discarded > after we are done). This has been discussed on the list before this past September, but I think the discussion has stalled after v2 was sent, most likely due to my suggestions asking for more, I hate to admit: https://lore.kernel.org/git/20190907234413.1591-1-wh109@xxxxxxxxx/ > But other than that, it was quite nice. > > It is less transparent (at least to me) and probably less efficient > than the current workflow to rebuild 'pu' for a few times every day > ("less efficient" is primarily because the established workflow is > quite optimized to the way I work), so it is not likely for me to > switch to "rebase -ri" any time soon. But it makes me feel safe to > know that there is another tool I can use to double-check the result > of everyday workflow. I understand. There is definitely a non-negligible cost involved whenever switching from one flow that works to another that might not yet work as well. I had the same hiccups when switching the Git garden shears over to `--rebase-merges` (it was worth it because the result is so much faster on Windows, of course). Having said that, if you ever find yourself wanting Just One Feature in `--rebase-merges` that would make it worthwhile for you to think about switching your patch-based workflow to a `rebase -ir`-based one, please let me know, and I will try my best to accommodate. Ciao, Dscho
