On Tue, Sep 09, 2008 at 09:43:54PM +0200, Stephen R. van den Berg wrote: > >Besides I very much prefer using 'origin <sha1> <sha2>' (as proposed > > The simplicity sounds inviting. I'd like to hear from others who have > more experience (than I have) with the git vs. changeset paradigms about > this. This allows a bit more flexibility in specifying the origin, the > question is if it's needed. One thing to keep in mind is that you are not just proposing some new behavior for a command, but rather a new header for the data structure that we will live with from now until eternity. So I think it makes sense to allow the general case even if nobody is generating it yet, if there is some chance that it may be useful for somebody to generate in the future. And yes, you can get _too_ general to the point where your semantics become meaningless. But I don't think that is the case here. You are defining the origin field as "by the way, the difference between state X and state Y was used to make this commit". cherry-pick just happens to make Y=X^, but something like rebase could use a series. As for "git vs changeset": this is git. So you have a sequence of tree states whether that is what you want or not. Thus you are specifying the difference between _some_ pair of commits. I don't see any benefit to restricting it to a commit and one of its parents. > 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. Actually, it could decrease it. If I tell you that you must have "X" and "X^2", then you could get away with just checking if you have "X". But you might also want to check whether "X" even _has_ a second parent. And that means not just looking up the object, but accessing it (resolving deltas if need be, uncompressing, parsing the object). With "X" and "Y", it is just two object lookups. Now obviously you don't have to be quite so careful in the "hash plus parent" case. And if you are going to _do_ anything with the origin field, you will end up accessing those objects anyway. But in that case, you end up with the same number of lookups and accesses anyway: 2 of each. > >On the other hand this leads to the following question: what happens > >if you cherry-pick or revert a commit which has its own 'origin' > >links? > > Nothing special. cherry-pick/revert behave as if the existing origin links > were not present in the first place. I think that is smart; if somebody wants to drill down into the history of origin links, they can do so at lookup time. -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
