Jakub Narebski wrote:
>On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> On the contrary, my current proposal only needs to verify the validity
>> of a single commit, changing it like this will require the system to
>> verify the validity of two commits. Given the rareness of the origin
>> links this will hardly present a problem, but it *does* increase
>> the overhead in checking a bit.
>Errr... wasn't you proposing to keep/protect against pruning <cousin>
>AND <cousin>^<mainline>? You want to have _diff_ (changeset) protected,
>not a single tree state.
Actually, making sure that the commit we reference in the origin link
exists, we implicitly prove that all the parents of that commit exist as
well. Then again, this point is moot since I already conceded (in a
different thread) that storing two hashes is better.
>>>> - git rev-list --topo-order will take origin links into account to
>>>> ensure proper ordering.
>Hmmm... while I think it might be a good idea, I'm not sure about its
>overhead. Should be much, I guess.
Actually, I have already programmed this part, and the overhead is close
to zero.
>>>> - git blame will follow and use the origin link if the object exists.
>>> Hmmmm... I'm not sure about that.
>> Care to explain your doubts?
>> The reason I want this behaviour, is because it's all about tracking
>> content, and that part of the content happens to come from somewhere
>> else, and therefore blame should look there to "dig deeper" into it.
>But blame is all about what commit brought some line to currents version.
>So the cherry-pick itself, or revert of a commit itself would be blamed,
>and should be blamed, not its parents, nor commit which got cherry-picked,
>or commit which got reversed.
Well, it depends, I guess.
If you'd go for a "committer" based display, then following origin links
is bad.
If you'd go for an "author" based display, then following origin links
should be the default (IMHO).
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
--
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
