(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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
