On Thu, Sep 11, 2008 at 04:04:53PM -0400, Theodore Tso wrote: > > 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. That is a good point. Stephen has explained his workflow, and I can see why he wants to reference the cherry-picked commits, and how he thinks that the referenced commits will always be available in that workflow. And obviously in Linus's workflow such references are basically useless, and they should just not be generated. But what about workflows in between? When I pull from some developer who has added a weak reference to a particular commit SHA1, but I _don't_ have that commit, my next question "OK, so what was in that commit?". What is the mechanism by which I find out more information on that SHA1? Using a key that is meaningful to an external database (like a bug tracker) means that you can go to that database to look up more information. -Peff -- 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
