Re: Properties of trees referencing commit objects (mode 160000)?

[Jeff King <peff@peff.net>]

On Sun, Mar 20, 2016 at 04:22:02PM -0700, Josh Triplett wrote:

> I want to track the evolution of a patch series or other commit history,
> through non-fast-forwarding actions like rebase, rebase -i, or commit
> --amend.  Similar in spirit to reflog, but with intentional commits and
> commit messages, and most importantly with the ability to share and
> collaborate on it.  For each version of the patch series, I plan to
> track the commit at the end of the series, and optionally the commit at
> the base of the patch series (to simplify tracking of rebasing); I'll
> use the tree object associated with the commit to track the cover
> letter, and perhaps meta-changelog entries associated with v2/v3/vN of
> the series.
> 
> Patch series almost always need to evolve through non-fast-forwarding
> history.  And I've seen that done in two ways: either pull the patch
> series out of git, put it in quilt or similar, and track the quilt
> series with git; or pull the versioning of the patch series out of git
> and track it with branch names like feature-v2, feature-2016-03-20,
> feature-rebased, and feature-rebased-4.4-fixed-foo-fixed-bar.  That last
> one closely matches a real-world example I've recently seen.  And that
> starts to look a lot like the naming of files and documents in
> organizations that haven't yet discovered the wonders of version
> control.
> 
> I'd like to have the best of both worlds: handle the patch series in
> git, *and* handle the versioning of the patch series in git.

It seems like you could represent this in git by storing a merge commit
for each revision of the patch series, with one parent as the current
real tip of the series, and the other as the merge-commit for the
previous revision of the series. The tree would be the same as current
tip commit's tree. You could store metadata about the series in the
merge commits (presumably including some marker to say "I'm a special
series-revision commit, not a regular merge").

That's roughly the same as having "feature-v1", "feature-v2", etc, in a
tree, except that you have to walk down the parent pointers to discover
each entry, rather than walking the tree.

The resulting history would be viewable with naive "git log", but you
would probably want to use "--first-parent" to see just the revisions,
or some to-be-invented option to see just the most recent commits (e.g.,
something like: if the commit subject is "magic-token: my-series", then
skip this commit, show the second parent, and then walk down the first
parent chain, skipping commits until we hit a commit that doesn't have
"magic-token: my-series" in it).

And it would just work for transferring revisions. You'd probably have
one ref per patch series (pointing to the marker commit of the most
recent version), and the "real" clean history of the project would never
include any of the revision markers at all (though it could if you
really wanted to).

But I will be the first to admit that I haven't thought too hard on
this. It may even be that I just unconsciously regurgitated somebody
else's storage scheme. Once upon a time I was interesting in "topgit",
"guilt", and other tools, but I haven't looked at them in years.

So it may well be that somebody tried something like this, and already
discovered its downsides. :)

-Peff