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

[Theodore Tso <tytso@MIT.EDU>]

On Thu, Sep 11, 2008 at 09:03:35PM +0200, Stephen R. van den Berg wrote:
> >This seems wrong.  OK, suppose you have branches A, B, C, and D, while
> >you are on branch C, you cherry pick commit 'p' from branch B, so that
> >there is a new commit q on branch C which has an origin link
> >containing the commit ID's p^ and 'p.    
> 
> >Now suppose branch B gets deleted, and you do a "git gc".  All of the
> >commits that were part of branch B will vanish except for p^ and p,
> 
> Not quite.  Obviously all parents of p and p^ will continue to exist.
> I.e. deleting branch B will cause all commits from p till the tip of B
> (except p itself) to vanish.  Keeping p implies that the whole chain of
> parents below p will continue to exist and be reachable.  That's the way
> a git repository works.

That's still not very useful, since you still don't have a label for
this anonymous series of commit chain that just dead ends at commit p.
How would anyone find this useful?

> >which in your model will stick around because they are origin links
> >commit q on branch C.  But what good is are these two commits?  They
> >represent two snapshots in time, with no context now that branch B has
> 
> The context are all their ancestors, which continue to exist, and that
> is all you need.

Need for what?  What useful information would you devine from it?

> >Oh, BTW, suppose you then further do a "git cherry-pick -o" of commit
> >q while you are on branch D.  Presumably this will create a new
> >commit, r.  But will the origin-link of commit r be p^ and p, or q^
> >and q?
> 
> It will be q^..q, and specifically not p^..p, using ^p..p would be
> lying.  We aim to document the evolvement of the patch in time.
> Cherry-pick itself will always ignore the origin links present on the
> old commit, it simply creates new ones as if the old ones didn't exist.

So if you never pull branch C (where commit q resides), there is no
way for you to know that commits p and r are related.  How.... not
useful.

If the scenario was being able to tell which stable branches had a
particular bug fixes, I think my proposal of attaching a bug
identifier is a far superior solution.

Again, what's the use case of "trying to document the development of
the patch in time?"  Aside from drawing pretty dotted lines
everywhere, what *good* does this actually achieve?  How would it
affect other git commands' behavior, and how would this change in
behavior actually be considered a net improvement over what we have
now?

						- Ted