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

["Stephen R. van den Berg" <srb@cuci.nl>]

Jakub Narebski wrote:
>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 

Rightfully so, of course.

>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).

Well, the train of thought here goes as follows:
1. Sure, why not add a field (zero or more) at the bottom of the free-form
   commit message reading like:

   Origin: bbb896d8e10f736bfda8f587c0009c358c9a8599 ee837244df2e2e4e9171f508f83f353730db9e53

2. Add support to cherry-pick/revert to actually generate the field upon
   demand.

3. Then add support to prune/gc/fsck/blame/log --graph to take the field
   into account.

4. Add support to filter-branch/rebase to renumber the field if necessary.

5. Add support to --topo-order to use the field if present and reachable.

6. For bonus points: add support to log to suppress the display of the
   field at the end of the commit message, and redisplay the field
   as Origin: bbb896d..ee83724
   next to the Parent/Merge fields.

Well, and after having done steps 1 to 5, the net result is that it
works almost as if the field is present in the header, except that:
- It is now at the end of the body in the commit message.
- It takes more time to find and parse it.

So that gives two minuses, and no pluses.
So short-circuiting the reasoning suggests that since the only thing
that actually changes now is the position of the field (at the top or
end of the commit message), we might as well do it right and put it in
the top, that gets rid of the two minuses.

Anything I missed?

Basically it means that:

a. If there is a better solution to tracking the backports, I'll gladly
   use that instead, but simply using the current really freeform
   approach doesn't cut it (it currently refers to a single commit,
   instead of a pair of commits, and takes too long to parse out in a
   --top-order or blame command).  Better solutions I haven't heard so
   far.

b. I need the integrity protection of a commit to make sure that the
   origin fields cannot be altered later; blame would be too easy to fool
   otherwise.  So using the notes solution seems to be out (it would also
   be quite a performance hit again).

c. I consider the Origin: field at the end of the commit message a
   workable solution, but it smells like X-header-extension-messes as in
   E-mail headers, and it incurs a small performance hit (in case of
   --topo-order/blame/prune/fsck), but maybe this performance hit can be
   minimised by making sure that the fields are *always* at the end
   of the commit message.

d. Using the proposed origin header in the standard commit header has
   close to zero overhead (in most commits the field is not present), yet
   codecomplexitywise it is almost identical with the Origin: field at
   the end of the commit message.

I find it remarkable though that people are dragging their feet at
solution d, yet are quite ok with solution c.  IMO solution c and d are
almost identical, except that solution c is ugly, and solution d is
elegant.  But if it makes it easier to prove the usefulness by
implementing the ugly solution first, that's fine.
-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."