Re: Updated git HOWTO for kernel hackers

[Jeff Garzik <jgarzik@pobox.com>]

Linus Torvalds wrote:
> 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 

For general git implementation, strongly agreed.


> 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..

Agreed.


> 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.

That's a fair point.  A separate script would be better.


> 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".
[...]
> 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.

For my use, I require all "Linus official tags" to be present in all my 
kernel trees, precisely because it is a big sync point for many people.

User A sends me a patch against 2.6.12-rc2, user B sends me a patch 
against 2.6.12-rc3, user C sends me a patch against 2.6.12...  I create 
a branch with
	cp .git/refs/tags/$kversion .git/refs/heads/foo-net-drvr
	git checkout -f foo-net-drvr
apply the patch, then pull linux-2.6.git to merge up to the latest version.

So in my case, the rare case is the 99% common case :)

I suppose this usage is just highly specific to me.

	Jeff