Commit Graph

5 Commits

Author SHA1 Message Date
Linus Torvalds
230f13225d Create object subdirectories on demand
This makes it possible to have a "sparse" git object subdirectory
structure, something that has become much more attractive now that people
use pack-files all the time.

As a result of pack-files, a git object directory doesn't necessarily have
any individual objects lying around, and in that case it's just wasting
space to keep the empty first-level object directories around: on many
filesystems the 256 empty directories will be aboue 1MB of diskspace.

Even more importantly, after you re-pack a project that _used_ to be
unpacked, you could be left with huge directories that no longer contain
anything, but that waste space and take time to look through.

With this change, "git prune-packed" can just do an rmdir() on the
directories, and they'll get removed if empty, and re-created on demand.

This patch also tries to fix up "write_sha1_from_fd()" to use the new
common infrastructure for creating the object files, closing a hole where
we might otherwise leave half-written objects in the object database.

[jc: I unoptimized the part that really removes the fan-out directories
 to ease transition.  init-db still wastes 1MB of diskspace to hold 256
 empty fan-outs, and prune-packed rmdir()'s the grown but empty directories,
 but runs mkdir() immediately after that -- reducing the saving from 150KB
 to 146KB.  These parts will be re-introduced when everybody has the
 on-demand capability.]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08 15:54:01 -07:00
Junio C Hamano
8098a178b2 Add git-symbolic-ref
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs".  By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.

The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.

Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-10-01 23:19:33 -07:00
Junio C Hamano
e2f5f6ef67 Do not require clean tree when reverting and cherry-picking.
My stupidity deserved to be yelled at by Linus ... there is no reason
to require the working tree to be clean when merging -- the only
requirements are index to match HEAD commit and the paths involved in
merge are up to date in the working tree.  Revert and cherry-pick are
just specialized forms of merge, and the requirements should be the
same.

Remove the 'general purpose routine to make sure tree is clean' from
git-sh-setup, to prevent me from getting tempted again.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-26 18:04:17 -07:00
Junio C Hamano
365527adbf Fix CDPATH problem.
CDPATH has two problems:

 * It takes scripts to unexpected places (somebody had
   CDPATH=..:../..:$HOME and the "cd" in git-clone.sh:get_repo_base
   took him to $HOME/.git when he said "clone foo bar" to clone a
   repository in "foo" which had "foo/.git").  CDPATH mechanism does
   not implicitly give "." at the beginning of CDPATH, which is
   the most irritating part.

 * The extra echo when it does its thing confuses scripts further.

Most of our scripts that use "cd" includes git-sh-setup so the problem
is primarily fixed there.  git-clone starts without a repository, and
it needs its own fix.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-12 22:52:51 -07:00
Junio C Hamano
215a7ad1ef Big tool rename.
As promised, this is the "big tool rename" patch.  The primary differences
since 0.99.6 are:

  (1) git-*-script are no more.  The commands installed do not
      have any such suffix so users do not have to remember if
      something is implemented as a shell script or not.

  (2) Many command names with 'cache' in them are renamed with
      'index' if that is what they mean.

There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support  is expected to be removed in the near
future.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07 17:45:20 -07:00