Re: basics... when reading docs doesn't help

On Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:

Yeah, that is all the loose objects. That's 1.1GB of stuff as loose objects, which also likely means that your tree was not only using up too much disk-space, it was probably running about ten times slower than than it needs to be for many operations.

Using pack-files ends up speeding up a lot of "big" operations a *lot*. If all you do is look at individual commits, you'll probably not notice much, but even something as simple as running "gitk" with no parameters (which will thus traverse the whole history) should be a *lot* faster after it's been all re-packed.

Well, it will generally remove all loose objects, since they get put into the pack-files instead. So it didn't remove "everything", but it does remove everything that "git count-objects" normally counts (if you give count-objects the "-v" flag for verbose output, it will talk about packed objects too).

That looks about right. Packing generally uses about a tenth of the disk-space of loose objects - both from the use of deltas, and from the fact that you don't any disk block fragmentation. And because looking at objects then doesn't require any system calls any more (just the initial "mmap pack and read index" stuff), it ends up being much faster too, despite the added overhead of doing the whole delta-chain thing.

You need to mark "refs/heads/origin" as always following the remote "master", even if it gets re-based. You do that by adding a "+" before the refspec that describes the remote.

These days, with git-1.5.x, "git clone" will do that for you (and make the remotes fall under "refs/remotes/origin/*" instead - they're considered separate branches from the local branches these days). However, since you created the repository with an older git version, it still uses the original format (and even though you upgraded your git binary, it will use the old-fashioned branch format for remote branches and for configuration).

So in your case, the remote is probably described by the .git/remotes/origin file, and it looks something like

	URL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
	Pull: master:origin

and you should just change that "Pull:" line to have a "+" in front of the refspec:

	URL: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
	Pull: +master:origin

which tells git that the remote "master" branch should now *unconditionally* be followed into the local "origin" branch when you pull.

(In a more modern setup, you wouldn't have a .git/remotes/origin file at all, insead you would have something like this in the .git/config file:

	[remote "origin"]
		url = git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
		fetch = +refs/heads/*:refs/remotes/origin/*

	[branch "master"]
		remote = origin
		merge = refs/heads/master

which means that there is a remote called "origin", and all of the remote heads in that remote ("refs/heads/*") will be fetched into the local repository under "refs/remotes/origin/*". And the "+" again means that we do this even if it's not a fast-forward, ie we trust the remote explicitly.

So "git fetch origin" will fetch *all* branches from "origin" into your local repository, but to distinguish them from your *own* branches, they will be under .git/refs/remotes/ instead of your "real" local branches that are in ".git/refs/heads/. So you can now see the difference between your *local* version of a branch X and the remote version of that same branch by using "X" and "remotes/origin/X" respectively to describe that branch.

Then, the second part of the above config file means that when you're on the local "master" branch and do a "git pull", it will fetch it from the remote "origin", and merge the remote "refs/heads/master" branch from that remote (the same one that will be fetched into refs/remotes/origin/master by a "git fetch".

Yeah, this is all a bit complex, and it takes a while to wrap your head around it, but I have to say, once you do, the git-1.5.x layout really *is* very powerful, and it's actually very natural too (but the "very natural" part only comes after you have that "Aaahh!" moment!)

			Linus