Theodore Tso wrote:
>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.
>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."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
