Re: Bring together merge and rebase

From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Date: Dec 26, 2017, 23:30 UTC
Message-ID: <c03c67f2-7d2c-da94-08f8-48c41c2a55ed@gmail.com>
In-Reply-To: <CA+P7+xp9v8adrbF7JUYa3X+PvurHiW1QNTnodJt6-vyB3_dWAQ@mail.gmail.com>

Very interesting topic, just this one part I wanted to comment on:

On 26/12/2017 02:28, Jacob Keller wrote:

Show 5 quoted lines

> 
> What about some way to take the reflog and turn it into a commit-based
> linkage and export that? Rather than tying it into the individual
> commit history, keep track of it outside the commit, possibly via
> something like notes, or some other mechanism.

This seems like the most useful approach, might be not touching reflog per se, but having some kind of "cherry-picked commits source" log (where rebasing is a subset of cherry-picking). What Johannes mentioned, a mapping between "old" and "new" commits. Might be notes could fit in nicely, but I`m not competent to comment on that at the moment.

For me, the most interesting use case is not even tied to code review (thus no review comments to think about), but a situation where one might be rebasing a set of downstream patches on top of updating upstream - it might be possible for a bug to slip through due to some upstream changes, even where there are no conflicts and test suite is executed regularly (might be test reveling the bug is yet to be added).

In that situation, instead of just going back in "regular" history (single dimension) and eventually finding the offending (rebased) commit (its N-th rebased version, that is), it might be great to actually keep drilling down the "rebase history" now (second dimension), finding the exact rebase iteration / rebased commit version where the error first appeared.

Carl, you described this well in your document[1], and Johannes provided a valuable first-hand experience[2] from working around the very same native Git limitation for years, mentioning using (fragile, costly and not very automatible) rebased commits message search to drill down the second dimension (rebase iterations), which seems to be the only possible approach at the moment, with "vanilla" Git, at least.

So this might be much more interesting case, if code review one is less appropriate because of review comments being also relevant to commit rebase iterations (which should be then stored somewhere, too, relating to corresponding commits, not to lose context).

Regards, Buga

p.s. "Merging rebase" and "shears.sh" script[3] seem to be orthogonal to this - really great on their own in improving rebase itself and making it smarter and much more powerful and useful, where I guess they would benefit from native Git "cherry-picked (rebased) commits iterations tracking" (old/source <> new/destination commit mapping), too, as would other Git tools.

[1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/ [2] https://public-inbox.org/git/20171226040843.h7o6txkrp6zlv7u5@glandium.org/T/#m2e5079488bed2968d4ea52a10051a06c06ff61e0 [3] https://github.com/git-for-windows/build-extra/blob/af9cff5005/shears.sh#L12-L18