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