On Thu, Sep 11, 2008 at 04:10:26PM -0700, Linus Torvalds wrote:

quoted text
> > 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.

quoted text
> [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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html