Jeff King wrote:
>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.
>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.
Quite. I'll drop the old format and adapt my proposal to use the double
hash.
As far as the naming of the field is concerned: a changeset is what the
field describes, but changeset implies no sense of direction; origin
makes it clear that the current commit was derived *from* the changeset
represented by "origin".
--
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
