git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org
Subject: Re: basics... when reading docs doesn't help
Date: Fri, 30 Mar 2007 11:48:54 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0703301126390.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.60.0703301855480.4757@poirot.grange>



On Fri, 30 Mar 2007, Guennadi Liakhovetski wrote:
> 
> Installed 1.5.0.6 and its output of "git count-objects" is
> 
> 180932 objects, 1112656 kilobytes

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.

> git gc removed everything (uh?) and then

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

> linux-2.6$ du -ks .git
> 183040  .git
> 
> cool...

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.

> > > Unpacking 12452 objects
> > >  100% (12452/12452) done
> > > * refs/heads/origin: does not fast forward to branch 'master' of 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc;
> > >   not updating.
> > 
> > Sounds like either Paul re-based his tree, or you did some work on your 
> > "origin" branch..
> 
> It must be the former then:-) Did I have a chance to re-synchronize 
> locally to be able to pull normally again or was the only way to re-clone?

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

  reply	other threads:[~2007-03-30 18:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-29 20:50 basics... when reading docs doesn't help Guennadi Liakhovetski
2007-03-29 21:16 ` J. Bruce Fields
2007-03-29 21:26   ` Junio C Hamano
2007-03-29 21:46     ` J. Bruce Fields
2007-03-29 22:13       ` Guennadi Liakhovetski
2007-03-29 22:35         ` Linus Torvalds
2007-03-30 18:16           ` Guennadi Liakhovetski
2007-03-30 18:48             ` Linus Torvalds [this message]
2007-03-30 19:49               ` Guennadi Liakhovetski
2007-03-30 20:06                 ` Linus Torvalds
2007-03-30 20:23                 ` Theodore Tso
2007-03-30 20:39                 ` Junio C Hamano
2007-03-30 21:11                   ` Guennadi Liakhovetski
2007-03-30  2:43         ` Theodore Tso
2007-03-30 14:49           ` J. Bruce Fields
2007-03-30 18:02         ` Andreas Herrmann
2007-03-30 18:24           ` Guennadi Liakhovetski
2007-03-29 22:27   ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0703301126390.6730@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).