Re: git merging

On Fri, 17 Jun 2005, Jeff Garzik wrote:

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

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