Stephen R. van den Berg wrote: [...] > Please focus on the semantics and on the *non*-made up use case of > development of several stable branches with backports between them. > Discussing made-up use cases is wasting energy at this point. By the way, I would really consider trying first to host 'origin' links not in repository database itself, but in some extra database inside git repository, like reflog or index. Git community is _very_ reluctant to modifying / extending format of persistent objects. From all the proposals to add some extra header to a 'commit' object: the 'prior' link to previous version of rebased, cherry-picked or redone commit (superceded somewhat by local reflog, on by default in modern git); the generic 'note' header, with examples of usage including _non-linking_ cherry-pick and reverted commit-id, merge strategy used, and hints for rename detection, i.e. something like #pragma in C (rejected on the grounds that it was too generic and didn't have well defined semantic); the 'generation' header which was meant to help and speed up sorting commits, with root (parentless) commit having generation of 1, and each commit having generation being 1 more than maximum of generations of its parents (I think that backwards compatibility killed it, and the fact that date-based heuristics was improved); only the 'encoding' header was accepted. So I think you should go the route of externally (outside 'commit' objects) maintaing 'origin'/'changeset'/'cset' links (like XLink extended links ;-)) as a prototype to examine consequences of the idea. That was the way _submodule_ support was added to Git, by the way. First there were (at least) two implementations maintaining submodules outside object database (see http://git.or.cz/gitwiki/SubprojectSupport especially "References" section), then it was officially added first at the level of plumbing support, as extension of a 'tree' object (and index format, I think). -- Jakub Narebski Poland -- 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
