Re: ia64 git pull

From: Linus Torvalds
Date: Thu Apr 21 2005 - 17:33:13 EST




On Thu, 21 Apr 2005 tony.luck@xxxxxxxxx wrote:
>
> I can't quite see how to manage multiple "heads" in git. I notice that in
> your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> perhaps that is a clue.

It's mainly a clue to bad practice, in my opinion. I personally like the
"one repository, one head" approach, and if you want multiple heads you
just do multiple repositories (and you can then mix just the object
database - set your SHA1_FILE_DIRECTORY environment variable to point to
the shared object database, and you're good to go).

But yes, if you want to mix heads in the same repo, you can do so, but
it's a bit dangerous to switch between them, since you'll have to blow any
dirty state away, or you end up having checked-out state that is
inconsistent with the particular head you're working on.

Switching a head is pretty easy from a _technical_ perspective: make sure
your tree is clean (ie fully checked in), and switch the .git/HEAD symlink
to point to a new head. Then just do

read-tree .git/HEAD
checkout-cache -f -a

and you're done. Assuming most checked-out state matches, it should be
basically instantaneous.

Oh, and you may want to check that yoy didn't have any files that are now
stale, using "show-files --others" to show what files are _not_ being
tracked in the head you just switched to.

I think Pasky has helper functions for doing this, but since I think
multiple heads is really too confusing for mere mortals like me, I've not
looked at it.

> I'd like to have at least two, or perhaps even three "HEADS" active in my
> tree at all times. One would correspond to my old "release" tree ... pointing
> to changes that I think are ready to go into the Linus tree. A second would
> be the "testing" tree ... ready for Andrew to pull into "-mm", but not ready
> for the base. The third (which might only exist in my local tree) would be
> for changes that I'm playing around with.

I _really_ suggest having separate directories and not play with heads.

As shown above, git can technically support what you're doing very
efficiently, but the problem is not technology - it's user confusion. It's
just too damn easy to do the wrong thing if you end up using the same
directory for all your heads, and switch between them.

In contrast, having separate directories, all with their own individual
heads, you are much more likely to know what you're up to by just getting
the hints from the environment.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/