On Mon, Jul 18, 2022 at 2:29 PM Glen Choo <chooglen@xxxxxxxxxx> wrote:
>
> Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes:
>
> > On Mon, Jul 18, 2022 at 06:18:11PM +0100, Stephen Finucane wrote:
> >> ...to track evolution of a patch through time.
> >>
> >> tl;dr: How hard would it be to retrofit an 'ChangeID' concept à la the 'Change-
> >> ID' trailer used by Gerrit into git core?
> >
> > I just started working on this for b4, with the notable difference that the
> > change-id trailer is used in the cover letter instead of in individual
> > commits, which moves the concept of "change" from a single commit to a series
> > of commits. IMO, it's much more useful in that scope, because as series are
> > reviewed and iterated, individual patches can get squashed, split up or
> > otherwise transformed.
>
> My 2 cents, since I used to use Gerrit a lot :)
>
> I find persistent per-commit ids really useful, even when patches get
> moved around. E.g. Gerrit can show and diff previous versions of the
> patch, which makes it really easy to tell how the patch has evolved
> over time.
>
> That's not to say that we don't need per-topic ids though ;) E.g. Gerrit
> is pretty bad at handling whole topics - it does naive mapping on a
> per-commit level, so it has no concept of "these (n - 1) patches should
> replace these n patches".
>
> I, for one, would love to see some kind of "rewrite tracking" in Git.
> One use case that comes up often is downstream patches, where patches
> are continuously rebased onto a new upstream; in those cases, it's
> pretty hard to keep track of how the patch has changed over time
Two angles I can think of that partially address this:
1) If you have the old commits still around and know what they were,
you can run range-diff to see differences between any pair of versions
of the commits.
2) cherry-picks and reverts might already include a link to an "old"
commit for you in the commit message ("cherry picked from commit
<hash>" or "This reverts <hash>"). Those could be used to show how
the new commit differs from what would have been done with an
automatic cherry-pick or automatic revert. (By "automatic", I
basically mean what the state of files in the working tree would be
when the operation stops to allow users to resolve conflicts.) In
fact, I wrote some patches to do precisely this quite a while ago
which are up at https://github.com/gitgitgadget/git/pull/1151 if
you're curious. But this approach is not useful for general rebasing,
because there's no automated way to find out what the original commit
was so that you can take a look at such a difference.
