Git needs a information preserving rebase [LWN.net]

Git needs a information preserving rebase

Posted Sep 16, 2019 12:00 UTC (Mon) by jrincayc (guest, #29129)
Parent article: Change IDs for kernel patches

Side note: Git needs to by default preserve information during a rebase. As in just as each commit records the parents, patches produced by rebase should record the git id of the patches that were used for the rebase. This would allow automated tools to more easily figure out where a patch came from.

to post comments

Git needs a information preserving rebase

Posted Sep 16, 2019 13:51 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

Maybe only if those commits are actually available somewhere? References to commits which only existed locally before rebases seems like pure noise to me. Also, what do you do for split/joined commits? Do the magic fixup! or squash! prefixes suppress this? What about manual fixup or squash?

(From a heavy git-rebase user :) )

Git needs a information preserving rebase

Posted Sep 16, 2019 16:01 UTC (Mon) by zblaxell (subscriber, #26385) [Link]

Indeed, the whole point of git rebases is that they are *not*
information-preserving. Rebase is a tool to discard irrelevant cruft:
typos, failed experiments, rejected patches, accidentally added binaries,
commits where you forgot to add "-s", and so forth.

If someone comes up with a way to import and archive patch review
discussions (perhaps in a separate branch or tree) and reference them
in git commits in a way that plays nicely with 'git push' and 'git gc',
then rebase should preserve _that_.

Git needs a information preserving rebase

Posted Sep 17, 2019 9:57 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

I just had the same idea when reading the discussion above. We could have "git rebase", "git am", "git commit --amend", "git cherry-pick" automatically append a tag "original-id:" with the ID of the original patch. In case of fixup/squash, it may very well merge all of them. This way we do keep good traceability in patch series with exactly *zero* effort nor risk of mistake on the developer's side. In fact the developer would only make an effort to remove the tag!

This would also cover part of what is already being done with "cherry-pick -x" that's used a lot for backports. And very often the information provided there would be useful because it would reference a commit ID which is available in another public tree, and even if that tree is not publicly available it would at least serve as a common tracking key.