On Tue, Apr 08, 2025 at 04:58:58PM +0100, Phillip Wood wrote: > On 08/04/2025 15:27, Junio C Hamano wrote: > > Something like this should allow us avoid relying on "change ID"s > > that can collide elsewhere in the world without having a central > > authority to assign them. > > This is similar in spirit to the "git evolve" proposal [1]. One of the > objections to that was that it required all of the rewritten commits to be > pushed back to the remote, rather than just the current version. So if I > rewrite a branch three times and push the result for review all of the > intermediate state gets pushed as well. That is because the intermediate > commits were needed to track the chain of rewritten commits to avoid the > problem Elijah described [2] when trying to follow cherry-picked-from > trailers. If the predecessor information was stored separately to the commit > it refers to (in a notes ref for example) then we could in principle > simplify the chain of rewrites when pushing so that we only need to push the > final version of the commit and a mapping from the version that we fetched > from the remote. One might as well have a way to push reflogs. But so much internal history is just distracting. Half the point of linear history upstream is to drop all the internal history that no one should care about. Even during code review this is too much and too distracting. Some users commit very often, and for them this would make their work rather difficult to review. > Tracking predecessors as you describe is certainly a more complete solution > to tracking the evolution of commits and it addresses the shortcomings of > change-ids you outlined in your previous mail. It is a lot more work to > implement though. There's also that. IMO that's ETOOMUCH. Just change IDs / series IDs should suffice.
