Re: git merging

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 17 Jun 2005, Jeff Garzik wrote:
> 
> This is definitely not the case; my .git/HEAD is _always_ a symlink.

Ok. Are you sure that you gave the same arguments (or rather, lack of
arguments) to both fsck and "git prune"? The thing is, they are both
really the same thing, so I'm pretty surprised. If git prune says 
something is unreachable, then git-fsck-cache shouldn't complain about it 
being gone, because one just depends on the other..

> My git-switch-tree script, attached, demonstrates how .git/HEAD symlink 
> is retargetted to the specified branch.  My workflow depends on 
> .git/HEAD being a symlink.

Btw, you can now do the same thing more safely and guarantee that it 
doesn't overwrite any old information by using

	git-read-tree -m -u <old-head> <new-head>

which basically switches from "old" to "new", and verifies that all the 
old index contents were valid in "old-head", and that any file that was 
dirty is not different in "new-head".

Your old script would silently overwrite any dirty state in your working
directory, and drop anything that you had done a git-update-cache on but
not committed.

Now, you may have _depended_ on that behaviour as a way to just reset the 
tree to a known state, but if so, I'd suggest using

	git-read-tree --reset HEAD && git-checkout-cache -q -f -u -a

for that instead (which will also throw away any partial merges).

So for the "switch" case, you might make it be something like

	if [ ! -f .git/refs/heads/$1 ]
	then
		echo "Branch '$1' not found"
		exit 1;
	fi
	git-read-tree -m -u HEAD "heads/$1" && ln -sf refs/heads/$1 .git/HEAD

which should do the right thing.

Totally untested, of course ;)

[ But the two-tree read-tree is definitely not untested: this is how we 
  do a safe "fast forward" in the git-resolve-script, which really ends up 
  being the exact same thing: it "switches" from one head to another ].

		Linus