From: Daniel Barkalow Date: Fri, 23 Sep 2005 21:07:37 GMT Subject: Re: Please undo "Use git-merge instead of git-resolve in Message-ID: In-Reply-To: <20050923095742.GC10255@pasky.or.cz> On Fri, 23 Sep 2005, Petr Baudis wrote: > Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter > where Junio C Hamano told me that... > > Petr Baudis writes: > > > > > * cg-fetch can do with symlinked object database > > > > Do you mean ".git/object" in the repository you are fetching > > into is a symlink to somewhere, or something else? > > Yes, exactly that. You get it by doing cg-clone -l /local/path. O(1) > cloning, but it has its downsides and dangers which I tried to describe > in the cg-clone documentation. That's actually how I use git, and it works for me. (To be precise, I have: ~/git/project.git/{objects,refs,info} and I have ~/working/git/current-work/, with .git/{objects,refs,info} symlinks to the above. git fetch works fine, with the exception that remotes aren't shared between working trees. > > > * cg-fetch won't do useless fetches when we are already > > > up-to-date > > > > Care to explain? Perhaps you are talking about rsync transport > > (in which case I would not be surprised)? > > Just that if the reference pointer did not change, you don't try to pull > any objects. Speeds things up somewhat, and now it should always work > (well, cg-fetch has -f which makes it always try objects as well, in > case something went wrong anyway). I assume you mean with rsync? The current git-http-fetch won't try any objects if the ref didn't change (or, for that matter, if we have a different ref that's the same), and the old one would make a local check for the objects before trying to downlaod anything. -Daniel *This .sig left intentionally blank*