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

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

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

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