merge-file has the same syntax as RCS merge, but supports only the
"-L" option.

For good measure, a test is added, which is quite minimal, though.

[jc: further fix for compliation errors included.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: with minimum squelching of compiler warning under "-pedantic"
 compilation options.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Just make it take over blame's place.  Documentation and command
have all stopped mentioning "git-pickaxe".  The built-in synonym
is left in the command table, so you can still say "git pickaxe",
but it probably is a good idea to retire it as well.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This replaces git-branch.sh with builtin-branch.c

The changes is basically a patch from Kristian Hgsberg, updated
to apply onto current 'next'
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This replaces the shell script git-cherry with a version written in C.

The behaviour of the new version differs from the original in two
points: it has no long help any more, and it is handling the (optional)
third parameter a bit differently.  Basically, it does the equivalent
of

   ours=`git-rev-list $ours ^$limit ^$upstream`

instead of

   ours=`git-rev-list $ours ^$limit`
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Both the git-prune manpage and everday.txt say that git-prune should also prune
unpacked objects that are also found in packs, by running git prune-packed.

Junio thought this was "a regression when prune was rewritten as a built-in."

So modify prune to call prune-packed again.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Currently it does what git-blame does, but only faster.

More importantly, its internal structure is designed to support
content movement (aka cut-and-paste) more easily by allowing
more than one paths to be taken from the same commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-zip-tree can be safely removed because it was never part of a formal
release.  This patch makes 'git-archive --format=zip' the one and only git
ZIP file creation command.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This also adds some very rudimentary support for the notion of packed
refs.  HOWEVER! At this point it isn't used to actually look up a ref
yet, only for listing them (ie "for_each_ref()" and friends see the
packed refs, but none of the other single-ref lookup routines).

Note how we keep two separate lists: one for the loose refs, and one for
the packed refs we read. That's so that we can easily keep the two apart,
and read only one set or the other (and still always make sure that the
loose refs take precedence).

[ From this, it's not actually obvious why we'd keep the two separate
  lists, but it's important to have the packed refs on their own list
  later on, when I add support for looking up a single loose one.

  For that case, we will want to read _just_ the packed refs in case the
  single-ref lookup fails, yet we may end up needing the other list at
  some point in the future, so keeping them separated is important ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds a new command, git-for-each-ref.  You can have it iterate
over refs and have it output various aspects of the objects they
refer to.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It's kind of like "git peek-remote", but works only locally (and thus
avoids the whole overhead of git_connect()) and has some extra
verification features.

For example, it allows you to filter the results, and to choose whether
you want the tag dereferencing or not. You can also use it to just test
whether a particular ref exists.

For example:

	git show-ref master

will show all references called "master", whether tags or heads or
anything else, and regardless of how deep in the reference naming
hierarchy they are (so it would show "refs/heads/master" but also
"refs/remote/other-repo/master").

When using the "--verify" flag, the command requires an exact ref path:

	git show-ref --verify refs/heads/master

will only match the exact branch called "master".

If nothing matches, show-ref will return an error code of 1, and in the
case of verification, it will show an error message.

For scripting, you can ask it to be quiet with the "--quiet" flag, which
allows you to do things like

	git-show-ref --quiet --verify -- "refs/heads/$headname" ||
		echo "$headname is not a valid branch"

to check whether a particular branch exists or not (notice how we don't
actually want to show any results, and we want to use the full refname for
it in order to not trigger the problem with ambiguous partial matches).

To show only tags, or only proper branch heads, use "--tags" and/or
"--heads" respectively (using both means that it shows tags _and_ heads,
but not other random references under the refs/ subdirectory).

To do automatic tag object dereferencing, use the "-d" or "--dereference"
flag, so you can do

	git show-ref --tags --dereference

to get a listing of all tags together with what they dereference.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Notably on GNU/Hurd, as reported by Gerrit Pape.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This command implements the git archive protocol on the server
side. This command is not intended to be used by the end user.
Underlying git-archive command line options are sent over the
protocol from "git-archive --remote=...", just like upload-tar
currently does with "git-tar-tree=...".

As for "git-archive" command implementation, this new command
does not execute any existing "git-{tar,zip}-tree" but rely
on the archive API defined by "git-archive" patch. Hence we
get 2 good points:

 - "git-archive" and "git-upload-archive" share all option
   parsing code.

 - All kind of git-upload-{tar,zip} can be deprecated.
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.

Instead of directly calling git-{tar,zip}-tree command, it defines
a very simple API, that archiver should implement and register in
"git-archive.c". This API is made up by 2 functions whose prototype
is defined in "archive.h" file.

 - The first one is used to parse 'extra' parameters which have
   signification only for the specific archiver. That would allow
   different archive backends to have different kind of options.

 - The second one is used to ask to an archive backend to build
   the archive given some already resolved parameters.

The main reason for making this API is to avoid using
git-{tar,zip}-tree commands, hence making them useless. Maybe it's
time for them to die ?

It also implements remote operations by defining a very simple
protocol: it first sends the name of the specific uploader followed
the repository name (git-upload-tar git://example.org/repo.git).
Then it sends options. It's done by sending a sequence of one
argument per packet, with prefix "argument ", followed by a flush.

The remote protocol is implemented in "git-archive.c" for client
side and is triggered by "--remote=<repo>" option. For example,
to fetch a TAR archive in a remote repo, you can issue:

$ git archive --format=tar --remote=git://xxx/yyy/zzz.git HEAD

We choose to not make a new command "git-fetch-archive" for example,
avoind one more GIT command which should be nice for users (less
commands to remember, keeps existing --remote option).
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Acked-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This creates a new git-runstatus which should do roughly the same thing
as the run_status function from git-commit.sh. Except for color support,
the main focus has been to keep the output identical, so that it can be
verified as correct and then used as a C platform for other improvements to
the status printing code.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In the Windows world ZIP files are better supported than tar files.
Windows even includes built-in support for ZIP files nowadays.

git-zip-tree is similar to git-tar-tree; it creates ZIP files out of
git trees.  It stores the commit ID (if available) in a ZIP file comment
which can be extracted by unzip.

There's still quite some room for improvement: this initial version
supports no symlinks, calls write() way too often (three times per file)
and there is no unit test.

[jc: with a minor typefix to avoid void* arithmetic]
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Convert git-verify-pack to a builtin command.  Also rename ac to argc
and av to argv for consistancy.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This cleans up the build procedure for built-in commands by:

 - generating mostly redundant definition of BUILT_INS from
   BUILTIN_OBJS in the Makefile,
 - renaming a few files to make the above possible, and
 - sorting the built-in command table in git.c.

It might be a good idea to binary search (or perfect hash) the built-in
command table, but that can be done later when somebody feels like.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The cmd_usage() routine was causing warning messages due to a NULL
format parameter being passed in three out of four calls. This is a
problem if you want to compile with -Werror. A simple solution is to
simply remove the GNU __attribute__ format pragma from the cmd_usage()
declaration in the header file. The function interface was somewhat
muddled anyway, so re-write the code to finesse the problem.

[jc: this incidentally revealed that t9100 test assumed that the output
 from "git help" to be fixed in stone, but this patch lower-cases
 "Usage" to "usage".  Update the test not to rely on "git help" output.]
Signed-off-by: NRamsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The header builtin.h was, incorrectly, redefining PATH_MAX which
causes a header order dependency in builtin-write-tree.c.  The fix
is to simply include <limits.h> directly to obtain the correct
definition of PATH_MAX.
Signed-off-by: NRamsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This also moves add_file_to_index() to read-cache.c. Oh, and while
touching builtin-add.c, it also removes a duplicate git_config() call.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This actually removes the objects to be pruned, unless you specify "-n"
(at which point it will just tell you which files it would prune).

This doesn't do the pack-file pruning that the shell-script used to do,
but if somebody really wants to, they could add it easily enough. I wonder
how useful it is, though, considering that "git repack -a -d" is just a
lot more efficient and generates a better end result.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
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>

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