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

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 11, 2008, 19:03 UTC
Message-ID: <20080911190335.GB1451@cuci.nl>
In-Reply-To: <20080911180037.GH5082@mit.edu>

Theodore Tso wrote:

Show 6 quoted lines

>On Thu, Sep 11, 2008 at 05:32:02PM +0200, Stephen R. van den Berg wrote:
>> gc will preserve the commits the origin links point to once they are
>> reachable.  I.e. if the developer doesn't care about the commits the
>> origin links point to (i.e. if the branches are not reachable) then gc
>> just skips them, if the developer *does* care, the origin links are used
>> to keep those objects alive (and, of course, all their parenthood).

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

Ok.

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

Show 6 quoted lines

>been deleted.  99% of the time, the diff between p^ and p will result
>in the equivalent of the diff between q^ and q.  But even if they
>aren't, what use are these isolated, disconnected commits?  So having
>"git gc" retain them commits that are pointed to be this proposed
>origin link doesn't seem to make any sense, and doesn't seem to be
>well thought through.

I beg to differ, but I presume you agree with me now?

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

>  And will this change depending on whether or not -o is
>specified?

No. Actually, cherry-pick will never generate origin links unless -o is specified.

-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."