Jeff King wrote:
>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.
>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?
Well, the usual way to fix this is to actually startup fetch and tell it
to try and fetch all the weak links (or just fetch a single hash (the
offending origin link)) from upstream; this is by no means the default
operatingmode of fetch, but I don't see any harm in allowing to fetch
those if one really wants to.
>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.
True. And also a Good Thing, I concur.
--
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
