Subject: Re: [RFC] origin link for cherry-pick and revert

From: Jakub Narebski <[email-masked]>
Date: Thu, 11 Sep 2008 10:20:53 +0200

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