Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)

On Tue, 25 Apr 2006, sean wrote:

But the point is, we don't generally _want_ to pull, push, or clone this crud.

I for one would literally have to add code to say "if any commit we poll has this random field, I refuse to pull".

There's two ways to have true interoperability (and in a distributed system, that's the thing that matters):

 - keep on piling on the sh*t
 - keep it simple so that people know exactly what the rules are.

Guess which one I am religiously in favour of.

That's my whole point: the "rules" for this suggested "prior" or "related" field simply don't exist, and it doesn't even seem to be the case that people can agree what it _means_ in that nobody has actually explained what the thing would do and why you would use it.

If you cannot explain to the other side what a field is used for, then that field - by definition - is not useful for the other side. It will just result in confusion, because different users will have different notions of what to do with the field (if anything).

So some users might consider it to have meaning, and actually do different things when it exists. Others would ignore it entirely. Yet thirds would ignore it, but consider it a link that must exist - which would break whenever those people would interact with the people who ignore it, and think that it's superfluous.

This is why it has to have real meaning. If there are no rules, things will break. Some things will pull them, others won't, yet third things will do random things.

If you just want to have something that "follows" an archive, it's easy enough to do: have a totally separate ref, that is a real branch, but may not even contain any files at all. You can - perfectly validly - have a chain of commits where all the information is in the "free-form" text area as far as git is concerned, but where the trees are all empty.

You'll find that all git users can pull such a commit, and you can use all the normal git ops on them, and you can hide your own metadata in there. And it would still be a valid git tree - your metadata would be your private thing, and you can keep it along-side the "normal" git data, and you can have your own "extended fsck", and "git pull/push" still continues to work.

Junio does something like that with the "todo" branch, for example (it's human-readable, not automated, but that doesn't really change anything). You can do

	git ls-tree todo
	git cat-file blob todo:Porcelainistas | less -S

and in general do anything you damn well please there. WITHOUT making up any new (and unnecessary) format semantics that nobody else cares about and that don't have very well-specified meaning.

		Linus