On Sunday 10 June 2007, Steven Grimm wrote: > 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. Actually MadCoder/Pierre had a similar idea on IRC. He wanted to separate softrefs into namespaces, so that softrefs for tags could live in a different place than softrefs associated with his "gits" bug tracker. I haven't thought very much about this, but it's certainly possible to do something like this. What do the rest of y'all think? > 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. Yes, I _knew_ this was similar to grafts in some way :) While working on this, I tried to see if I could leverage grafts somewhere in my design, but I found them to be too commit-bound and specific. But when you look at it the other way it seems to make more sense. > 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. Whoa. I hadn't even imagined this, but I guess you're right. I actually thought about solving the same problem (using a much worse method) way back in May [1], but I'd since totally forgotten about it. > But in any event, this seems like the start of a useful new set of > capabilities for git. Thanks a lot for sharing your ideas. :) Have fun! ...Johan [1] http://article.gmane.org/gmane.comp.version-control.git/46137 -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
