Re: Refactoring the tag object; Introducing soft references (softrefs); Git 'notes' (take 2)

(Resending this in plaintext; sorry to those who got it twice.)

Being able to specify relationships between commits after the fact seems like a very useful facility.

Does it make sense to have type information to record what the relationship between two objects means? Without that, it seems like it'll be hard to build much of a tool set on top of this feature, since no two tools that made use of it could unambiguously query just their own softrefs.

A few use cases for relationships-after-the-fact come to mind in addition to the one the patch itself mentions:

A facility like this could replace the info/grafts file, or at least provide another way to turn a regular commit into a merge commit. Just put a "manually specified merge parent" ref between the target revision and the one you want git to think you've merged from. That would scale a lot better than info/grafts does, I suspect, if only by virtue of being O(log n) searchable thanks to the sorting.

One could easily imagine recording a "cherry picked" softref, which could, e.g., be the rebase machinery to skip over an already-applied revision. IMO the lack of any tool-readable history about cherry picking -- which is, after all, a sort of merge, at least conceptually -- is a shortcoming in present-day git. (Not a huge one, but if nothing else it'd be great to see cherry picking represented in, e.g., the gitk history display.)

It might be possible to annotate rebases to make pulling from rebased branches less troublesome. If you have

A--B--C--D
    \
     -E--F--G

and you rebase E onto D, a "rebased from" softref could be recorded between E and E':

A--B--C--D
    \     \
     -E....E'--F'--G'

Then a pulling client could potentially use that information to cleanly replay the rebase operation to keep its history straight. Perhaps if you could record historical rebases like that, you could do away with the current gotchas involving rebasing shared repositories. One negative side effect would be that you'd end up needing to keep E around where before you'd have been able to throw it away, but it should delta compress well, and you can, I think, still prune revisions F and G in the above picture. Or maybe it's enough to just keep E's SHA1 around without actually retaining its contents.

But in any event, this seems like the start of a useful new set of capabilities for git.

-Steve