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

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 9 Sep 2008, Jeff King wrote:
> On Tue, Sep 09, 2008 at 01:42:52PM -0700, Junio C Hamano wrote:
> 
> > As for "by the way ... was used to make this commit": this is git.  So how
> > you arrived at the tree state you record in a commit *does not matter*.
> 
> But it _does_ matter, which is why we have commit messages to explain
> how you arrived at this tree state.

Well, that is why I was carefull to say that "origin <rev1> <rev2>"
(or 'changeset', or 'cset') means that tree state for given commit
is created out of parent commit (or parent commits in the case of merge)
and of (<rev2> - <rev1>) patch.  This is a bit of enhancement to
"parent <rev>" meaning that tree state for current commit is derived
from tree state of <rev>.

This is nice generalization...

> Now, that being said:
> 
> > After reading the discussion so far, I am still not convinced if this is a
> > good idea, nor this time around it is that much different from what the
> > previous "prior" link discussion tried to do.
> 
> For the record, I am not convinced it is a good idea either; I was
> hoping to steer it in a direction where somebody could say "and now this
> is the useful thing we can do now that we could not do before." If the
> ultimate goal is to put links to other commits into history viewers,
> then the commit message is a reasonable place to do so. The only thing I
> see improving with a header is that it makes more sense for pruning and
> object transfer.

I'm also not all convinced that 'cousin'/'origin'/'changeset'/'cset'
header is a good idea.  I only tried to steer discussion in good
direction if it is somewhat a good idea.

First, if the only goal would be to add extra links (extra edges) to
[graphical] history viewer, then full sha-1 of a commit which can be
recorded in commit message for cherry-picks and reverts should be
enough.  It does mean parsing commit message, and all possibilities
for mistake which are connected to using conventions in free-form part
of commit object; on the other hand it is not _that_ critical.

If however 'origin' links are more (perhaps only a tiny bit more),
for example discussed "weak" links... then I'm not sure if
the tradeoffs are worth it. First, if it is full connectivity like
in 'parent' header case, then a) why not use 'parent' anyway,
b) it pins the history indefinitely long. Second, if it is "weak"
link, i.e. local protect it on prune, then a) there are problems
with transferring the data, and protecting links on transfer,
as somewhere in the middle or at the end there might be repository
which uses older git (backwards compatibility strikes again),
b) git in many, many places assumes that object is valid if it passes,
and all objects linked to from object are valid; we would have either
use some kind of separate 'not strictly checked' packfile/storage,
or have grafts-like thingy.

So I'm not sure if 'origin' links are worth the trouble.


About much, much earlier "prior" link discussion: I think the discussion
about "prior" header link was done before reflogs, or at least before
reflogs got turned on by default.

-- 
Jakub Narebski
Poland