by nativecoinc on 3/5/23, 3:59 PM with 7 comments
by nativecoinc on 3/5/23, 3:59 PM
> I've been calling this proposal `git replay` or `git replace` but I'd like to hear other suggestions for what to name it. It works like rebase except with one very important difference. Instead of orphaning the original commit, it keeps a pointer to it in the commit just like a `parent` entry but calls it `replaces` instead to distinguish it from regular history. In the resulting commit history, following `parent` pointers shows exactly the same history as if the commit had been rebased. Meanwhile, the history of iterating on the change itself is available by following `replaces` pointers. The new commit replaces the old one but keeps it around to record how the change evolved.
Ts'o thinks[1] that this is too simplistic, citing some workflows that he has experience with from working on Linux. He says that they use metadata in the form of key-value pairs in the commit messages in order to track cherry-picks across trees, how to test the commit, and even the fact that a commit has been dropped in the current tree.[3]
> My experience, from seeing these much more complex use cases --- starting with something as simple as the Linux Kernel Stable Kernel Series, and extending to something much more complex such as the workflow that is used to support a Google Kernel Rebase, is that using just a simple extra "Replaces" pointer in the commit header is not nearly expressive enough. And, if you make it a core part of the commit data structure, there are all sorts of compatibility headaches with older versions of git that wouldn't know about it. And if it then turns out it's not sufficient more the more complex workflows anyway, maybe adding a new "replace" pointer in the core git data structures isn't worth it. It might be that just keeping such things as trailers in the commit body might be the better way to go
[1] https://lore.kernel.org/git/CALiLy7pBvyqA+NjTZHOK9t0AFGYbwqw...
[2] Submission link
[3] How? By making an “empty commit” (I presume: a commit which doesn’t change the tree) and adding the “dropped” metadata to the commit message.
by gumby on 3/5/23, 7:21 PM
Both come from the fundamental question: “When (if) we look back in history, what are we looking for?” Keeping everything as it was reduces the risk of deleting something that will later be important; consolidating is supposed to reduce the risk of missing the needle in the haystack or discouraging looking back at all.
Curating the past is 99% wasted effort since looking back is rare. I think the best compromise is to add some automation if you really care, as Ted suggested.