Re: Updated git HOWTO for kernel hackers

On Thu, 23 Jun 2005, Jeff Garzik wrote:

Please re-read what I said.

Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not associated with the tree, and they _cannot_ and _must_not_ be so, exactly because that would make them global instead of private, and it would fundamentally make them not be distributed, and would mean that they'd be pointless as anything but "Linus' official tags".

That's what we had in BK _AND IT DOES NOT WORK_!

Does it help when I scream?

And I suggested that if you want that, then you pull on the TAG. You take my modification, you test it, and you see if

	git fetch tag ..repo.. tagname

works.

That solves exactly the case that Greg is complaining about, and it solves it in a _sane_ manner: you tell git that you want a tag, and git fetches it for you. It's that simple, and it does not introduce the _BROKEN_ notion that tags are associated directly with the commit itself and somehow visible to all.

And multiple users -- clearly including you -- aren't listening to me. Tags are separate from the source they tag, and they HAVE TO BE. There is no "you automatically get the tags when you get the tree", because the two don't have a 1:1 relationship.

And not making them separate breaks a lot of things. As mentioned, it fundamentally breaks the distributed nature, but that also means that it breaks whenever two people use the same name for a tag, for example. You can't "merge" tags. BK had a very strange form of merging, which was (I think) to pick the one last in the BK ChangeSet file, but that didn't make it "right". You just never noticed, because Linux could never use tags at all due to the lack of privacy, except for big releases..

How is this AT ALL different from just having a separate script that does this? You've introduced nothing but syntactic fluff, and you've made it less flexible at the same time. First off, you might want to get new tags _without_ fetching anything else, and you might indeed want to get the tags _first_ in order to decide what you want to fetch. In fact, in many cases that's exactly what you want, namely you want to fetch the data based on the tag.

Secondly, if your worry is that you forget, then hell, write a small shell function, and be done with it.

BUT DO NOT MESS UP THINGS FOR OTHER PEOPLE.

When I fetch somebody elses head, I had better not fetch his tags. His tags may not even make _sense_ in what I have - he may tag things in other branches that I'm not fetching at all. In fact, his tag-namespace might be _different_ from mine, ie he might have tagged something "broken" in his tree, and I tagged something _else_ "broken" in mine, just because it happens to be a very useful tag for when you want to mark "ok, that was a broken tree".

It is wrong, wrong, _wrong_ to think that fetching somebody elses tree means that you should fetch his tags. The _only_ reason you think it's right is because you've only ever seen centralized tags: tags were the one thing that BK kept centralized.

But once people realize that they can use tags in their own trees, and nobody else will ever notice, they'll slowly start using them. Maybe it takes a few months or even longer. But it will happen. And I refuse to make stupid decisions that makes it not work.

And thinking that "fetching a tree fetches all the tags from that tree" really _is_ a stupid decision. It's missing the big picture. It's missing the fact that tags _should_ be normal every-day things that you just use as "book-marks", and that the kind of big "synchronization point for many people" tag should actually be the _rare_ case.

The fact that global tags make that private "bookmark" usage impossible should be a big red blinking sign saying "don't do global tags".

And I already suggested a trivial script. Send me the script patch, instead of arguing for stupid things.

			Linus