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

On Thu, 11 Sep 2008, Jeff King wrote:

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