Re: [RFC] origin link for cherry-pick and revert

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 11 Sep 2008, Jeff King 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.

If somebody has a workflow where they want to track "origin" commits, then 
they can do it today with the in-body approach. But that has nothing 
what-so-ever to do with the question of "let's change object file format 
to some odd special-case that we just made up and is only apparently 
useful for some special workflow that uses special tools and special 
rules".

I want the git object database to have really clear semantics. The fields 
we have now, we have because we _require_ them. There is nothing unclear 
what-so-ever about the semantics of author/commiter-ship, parenthood, 
trees, or anything else.

And there are _zero_ issues about "workflow". The workflow doesn't matter, 
the objects always make sense, and they always work exactly the same way. 
There are no special magic cases that are in the least questionable in any 
way.

So this argument is about more than just "minimalism", although I'll also 
admit to that being an issue - I want to be able to basically explain how 
git data structures work to any CS student, and not have any extra fat or 
any gray areas. It's about everything having a clear design, and a clear 
meaning, and there never being any question what-so-ever about what the 
real "meaning" of something is.

Then, if you have some special use case or rules for your particular 
project, well that's where you can have things like formatting rules for 
how the commit messages should look like. If somebody wants to use fixed 
format rules for their project, that's fine. And THAT is where "workflow" 
issues come up. 

But "workflow" has nothing to do with core git data structures. They were 
designed for speed, stability, simplicity and good taste. The _workflow_ 
part has been designed on separately on top of that (example: the whole 
thing with a single-line top summary of a commit so that we can have "git 
shortlog" and the "gitk" single-line commit view etc).

Of course, good and generally useful workflows can then be reflected in 
how tools work, where that single line commit summary is an example of 
that: it's not something that git data structures _enforce_ or even care 
about, but it's obviously something that a lot of the porcelain expects, 
and without it, lots of tools will output less useful information.

The same goes for the existing SHA1-in-comment support: some tools already 
support it and help view it in certain ways, even though it is in no way a 
core data structure issue. And _extending_ on that kind of helpful 
porcelain support certainly makes sense.

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.

			Linus