On Thu, Sep 11, 2008 at 04:10:26PM -0700, Linus Torvalds wrote: > > And obviously in Linus's workflow such references are basically useless, > > and they should just not be generated. > > This has _nothing_ to do with workflows or anything else. > > Why are people claiming these total red herrings? > > I have asked several times what it is that makes it so important that the > "origin" information be in the headers. Nobody has been able to explain > why it's so different from just doing it in the free-form part. NOBODY. The message you are responding to has nothing to do with an origin header versus putting it in the free-form part. It is equally a problem with both approaches. I was purely commenting on the "if I mention an arbitrary sha-1, what is the person reading it supposed to _do_ with it, if they may never have seen that sha-1" issue. So yes, it has _everything_ to do with workflows. In Stephen's case, he claims that all references will be to commits on long-lived branches. In which case, it is a non-issue because they will have the referenced commits. But in the general case, people will not have them, and there is potential head-scratching. My point is that even if a feature works for Stephen's workflow, it may not be a good feature for everyone, since other solutions handle the general case (as well as his case) much better. > [ranting about how the origin header is bad] > The only thing I have ever argued against is adding commit headers that > have no sane semantics and don't make sense as internal git data > structures. Yes, and I totally agree with everything you said. If you read the mail you are responding to carefully, you will see that I never mention an origin header versus the free-form commit. -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
