I got tired of having to configure gitweb for every repository
I work on.  I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.

Updates from the original patch:

Added Apache/mod_perl2 compatibility if Dennis Stosberg's gitweb
has been applied, too: <20060621130708.Gcbc6e5c@leonov.stosberg.net>

General cleanups in shell code usage.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This cleans up the use of safe_strncpy() even more.  Since it has the
same semantics as strlcpy() use this name instead.  Also move the
definition from inside path.c to its own file compat/strlcpy.c, and use
it conditionally at compile time, since some platforms already has
strlcpy().  It's included in the same way as compat/setenv.c.
Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Before this patch, -DDEFAULT_GIT_TEMPLATE_DIR was passed on compilation
command line to all and every .c file compiled. In fact the macro
is used by only one .c file, and unused by all other .c files.
Remove -DDEFAULT_GIT_TEMPLATE_DIR where unused. Follow the example of
exec_cmd.o. Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
Signed-off-by: NYakov Lerner <iler.ml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The program is not used by git-clone since git-fetch-pack was extended
to allow its caller do what git-clone-pack alone did, and git-clone was
updated to use it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This creates a simple specialized object allocator for basic
objects.

This avoids wasting space with malloc overhead (metadata and
extra alignment), since the specialized allocator knows the
alignment, and that objects, once allocated, are never freed.

It also allows us to track some basic statistics about object
allocations. For example, for the mozilla import, it shows
object usage as follows:

     blobs:   627629 (14710 kB)
     trees:  1119035 (34969 kB)
   commits:   196423  (8440 kB)
      tags:     1336    (46 kB)

and the simpler allocator shaves off about 2.5% off the memory
footprint off a "git-rev-list --all --objects", and is a bit
faster too.

[ Side note: this concludes the series of "save memory in object storage".
  The thing is, there simply isn't much more to be saved on the objects.

  Doing "git-rev-list --all --objects" on the mozilla archive has a final
  total RSS of 131498 pages for me: that's about 513MB. Of that, the
  object overhead is now just 56MB, the rest is going somewhere else (put
  another way: the fact that this patch shaves off 2.5% of the total
  memory overhead, considering that objects are now not much more than 10%
  of the total shows how big the wasted space really was: this makes
  object allocations much more memory- and time-efficient).

  I haven't looked at where the rest is, but I suspect the bulk of it is
  just the pack-file loading. It may be that we should pack the tree
  objects separately from the blob objects: for git-rev-list --objects, we
  don't actually ever need to even look at the blobs, but since trees and
  blobs are interspersed in the pack-file, we end up not being dense in
  the tree accesses, so we end up looking at more pages than we strictly
  need to.

  So with a 535MB pack-file, it's entirely possible - even likely - that
  most of the remaining RSS is just the mmap of the pack-file itself. We
  don't need to map in _all_ of it, but we do end up mapping a fair
  amount. ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: with a bit of constness tightening]
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This shrinks "struct object" to the absolutely minimal size possible.
It now contains /only/ the object flags and the SHA1 hash name of the
object.

The "refs" field, which is really needed only for fsck, is maintained in
a separate hashed lookup-table, allowing all normal users to totally
ignore it.

This helps memory usage, although not as much as I hoped: it looks like
the allocation overhead of malloc (and the alignment constraints in
particular) means that while the structure size shrinks, the actual
allocation overhead mostly does not.

[ That said: memory usage is actually down, but not as much as it should
  be: I suspect just one of the object types actually ended up shrinking
  its effective allocation size.

  To get to the next level, we probably need specialized allocators that
  don't pad the allocation more than necessary. ]

The separation makes for some code cleanup, though, and makes the ref
tracking that fsck wants a clearly separate thing.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-tar-tree adds an extended pax header to archives if its first
parameter points to a commit.  It confuses older tars and isn't
very useful in the case of git anyway, so stop doing it.

Idea: Junio, implementation: Junio.  I just wrote it up. :-)
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Detect changed prefix and/or changed build flags in the middle
of the build (or between 'make' and 'make install'), and if change
is detected, make sure all objects are compiled with same build
flags and same prefix, thus avoiding inconsistent/broken build.

[jc: removed otherwise unnecessary Makefile target to test the
 change this patch introduces. ]
Signed-off-by: NYakov Lerner <iler.ml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

By being an internal command git-get-commit-id can make use of
struct ustar_header and other stuff and stops wasting precious
disk space.

Note: I recycled one of the two "tar-tree" entries instead of
splitting that cleanup into a separate patch.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

The framework to create lockfiles that are removed at exit is
first used to reliably write the index file, but it is
applicable to other things, so stop calling it "cache_file".

This also rewords a few remaining error message that called the
index file "cache file".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This ifdef's out more functions that are not used while !USE_MULTI
in http code.  Also the dependency of http related objects on http.h
header file was missing in the Makefile.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise, if make is suspended, or killed with prejudice, or if the
system crashes, you could be left with an up-to-date, yet corrupt,
generated file.

I left off the `clean' addition, because I believe "make clean" should
not remove wildcard patterns like "*+", on the off-chance that someone
uses names like that for files they care about.  Besides, in practice,
those temporary files are left behind so rarely that they're not a bother,
and they're removed again as part of the next build.

[jc: sign-off?]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

As both DESTDIR and the prefix are supposed to be absolute pathnames
they can simply be concatenated without an extra / (like in the main Makefile).
The extra slash may even break installation on Windows.

[jc: adjusted an earlier workaround for this problem in the dist-doc
 target in the main Makefile as well. ]
Signed-off-by: NMartin Waitz <tali@admingilde.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Moving "git-cmd" commands out of the path and into a special
git exec path, should include the builtins.

[jc: fixed the case where bindir == gitexecdir - ln -f fails
 with a complaint that src and dst are the same, likewise for
 the fallback cp.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For systems which lack inet_ntop(), this adds compat/inet_ntop.c,
and related build constant, NO_INET_NTOP. Older Cygwin(s) lack
inet_ntop().
Signed-off-by: NYakov Lerner <iler.ml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes tar-tree a built-in.  As an added bonus, you can now
say:

	git tar-tree --remote=remote-repository <ent> [<base>]

This does not work with git-daemon yet, but should work with
localhost and git over ssh transports.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes semantics very subtly, because it adds a new atomicity
guarantee.

In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.

This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.

So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.

This is only an issue with "-f", of course.

I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).

The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

c3c8835f broke the default template
location which is in builtin-init-db.o, by not supplying the
compilation-time constant to the right build commands.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Basically this just renames init-db.c to builtin-init-db.c and makes
some strings const.
Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Importing a quilt patch series into git is not very difficult
but parsing the patch descriptions and all of the other
minutia take a bit of effort to get right, so this automates it.

Since git and quilt complement each other it makes sense
to make it easy to go back and forth between the two.

If a patch is encountered that it cannot derive the author
from the user is asked.
Signed-off-by: NJunio C Hamano <junkio@cox.net>