Re: [RFC] origin link for cherry-pick and revert
- From
Jeff King <peff@peff.net>
- Date
- Sep 11, 2008, 23:26 UTC
- Message-ID
- <20080911232610.GA4279@coredump.intra.peff.net>
- In-Reply-To
- <alpine.LFD.1.10.0809111533110.3384@nehalem.linux-foundation.org>
On Thu, Sep 11, 2008 at 04:10:26PM -0700, Linus Torvalds wrote:
Show 10 quoted lines
> > 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