These new commands weren't added to .gitignore.  Add them so we don't
end up with copies of them in the repo.
Signed-off-by: NBrian Gernhardt <benji@silverinsanity.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Junio asked for a 'git gc' utility which users can execute on a
regular basis to perform basic repository actions such as:

 * pack-refs --prune
 * reflog expire
 * repack -a -d
 * prune
 * rerere gc

So here is a command which does exactly that.  The parameters fed
to reflog's expire subcommand can be chosen by the user by setting
configuration options in .git/config (or ~/.gitconfig), as users may
want different expiration windows for each repository but shouldn't
be bothered to remember what they are all of the time.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A script to be driven when the user says "git add --interactive"
is introduced.

When it is run, first it runs its internal 'status' command to
show the current status, and then goes into its internactive
command loop.

The command loop shows the list of subcommands available, and
gives a prompt "What now> ".  In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:

    *** Commands ***
      1: status       2: update       3: revert       4: add untracked
      5: patch        6: diff         7: quit         8: help
    What now> 1

You also could say "s" or "sta" or "status" above as long as the
choice is unique.

The main command loop has 6 subcommands (plus help and quit).

 * 'status' shows the change between HEAD and index (i.e. what
   will be committed if you say "git commit"), and between index
   and working tree files (i.e. what you could stage further
   before "git commit" using "git-add") for each path.  A sample
   output looks like this:

              staged     unstaged path
     1:       binary      nothing foo.png
     2:     +403/-35        +1/-1 git-add--interactive.perl

   It shows that foo.png has differences from HEAD (but that is
   binary so line count cannot be shown) and there is no
   difference between indexed copy and the working tree
   version (if the working tree version were also different,
   'binary' would have been shown in place of 'nothing').  The
   other file, git-add--interactive.perl, has 403 lines added
   and 35 lines deleted if you commit what is in the index, but
   working tree file has further modifications (one addition and
   one deletion).

 * 'update' shows the status information and gives prompt
   "Update>>".  When the prompt ends with double '>>', you can
   make more than one selection, concatenated with whitespace or
   comma.  Also you can say ranges.  E.g. "2-5 7,9" to choose
   2,3,4,5,7,9 from the list.  You can say '*' to choose
   everything.

   What you chose are then highlighted with '*', like this:

              staged     unstaged path
     1:       binary      nothing foo.png
   * 2:     +403/-35        +1/-1 git-add--interactive.perl

   To remove selection, prefix the input with - like this:

        Update>> -2

   After making the selection, answer with an empty line to
   stage the contents of working tree files for selected paths
   in the index.

 * 'revert' has a very similar UI to 'update', and the staged
   information for selected paths are reverted to that of the
   HEAD version.  Reverting new paths makes them untracked.

 * 'add untracked' has a very similar UI to 'update' and
   'revert', and lets you add untracked paths to the index.

 * 'patch' lets you choose one path out of 'status' like
   selection.  After choosing the path, it presents diff between
   the index and the working tree file and asks you if you want
   to stage the change of each hunk.  You can say:

        y - add the change from that hunk to index
        n - do not add the change from that hunk to index
        a - add the change from that hunk and all the rest to index
        d - do not the change from that hunk nor any of the rest to index
        j - do not decide on this hunk now, and view the next
            undecided hunk
        J - do not decide on this hunk now, and view the next hunk
        k - do not decide on this hunk now, and view the previous
            undecided hunk
        K - do not decide on this hunk now, and view the previous hunk

   After deciding the fate for all hunks, if there is any hunk
   that was chosen, the index is updated with the selected hunks.

 * 'diff' lets you review what will be committed (i.e. between
   HEAD and index).

This is still rough, but does everything except a few things I
think are needed.

 * 'patch' should be able to allow splitting a hunk into
   multiple hunks.

 * 'patch' does not adjust the line offsets @@ -k,l +m,n @@
   in the hunk header.  This does not have major problem in
   practice, but it _should_ do the adjustment.

 * It does not have any explicit support for a merge in
   progress; it may not work at all.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now that we have git-merge-file, an RCS merge lookalike, we no longer
need it. So long, merge, and thanks for all the fish!
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This frees the Porcelain-ish that comes with the core Python-free.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This renames merge-recursive written in Python to merge-recursive-old,
and makes merge-recur as a synonym to merge-recursive.  We do not remove
merge-recur yet, but we will remove merge-recur and merge-recursive-old
in a few releases down the road.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The command now issues a big deprecation warning message and runs
git-archive command with appropriate arguments.

git-tar-tree $tree_ish $base always forces $base to be the leading
directory name, so the --prefix parameter passed internally to
git-archive is a slash appended to it, i.e. "--prefix=$base/".
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>

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

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>

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>

Add generated file config.cache (default cache file, when running
./configure with -C, --config-cache option) to the list of ignored
files.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When configure is interrupted in the middle it leaves
config.mak.append behind.  Add it to .gitignore and make sure
$(MAKE) clean removes it.

Also earlier .gitignore listed config.mak.in which is a tracked
file.  Fix it.
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>

Also it is OK to omit the documentation for it at least for now.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Allow NO_SVN_TESTS to be defined to skip git-svn tests.  These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is beginning of patch series introducing installation configuration
using autoconf (and no other autotools) to git. The idea is to generate
config.mak.autogen using ./configure (generated from configure.ac by running
autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to
ordinary Makefile, and creating one's own config.mak. Local settings in
config.mak override generated settings in config.mak.autogen

This patch includes minimal configure.ac and config.mak.in, so one can set
installation directories using autoconf generated ./configure script
e.g. ./configure --prefix=/usr
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
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>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
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>

For now let's retire this and reintroduce it as part of the updated
pack-objects series from Geert when it is ready.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This was useful in diagnosing the corrupt index.aux format
problem.  But do not bother building or installing it by
default.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Retire git-unresolve and make it into "git-update-index --unresolve".
It processes all paths that follow.

During a merge, you would mark a path that is dealt with with:

	$ git update-index hello

and you would "undo" it with:

	$ git update-index --unresolve hello
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is an attempt to address the issue raised on #git channel
recently by Carl Worth.

After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch.  During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going.  However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.

With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files.  This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".

One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.

We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This splits Geert's similarity fingerprint code into main
program and fingerprinting function.  The next step would be to
try using this in pack-objects.c::try_delta() -- which would be
a good evaluation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This command removes untracked files from the working tree.  This
implementation is based on cg-clean with some simplifications.  The
documentation is included.

[jc: with trivial documentation fix, noticed by Jakub Narebski]
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

git-imap-send drops a patch series generated by git-format-patch into an
IMAP folder. This allows patch submitters to send patches through their
own mail program.

git-imap-send uses the following values from the GIT repository
configuration:

The target IMAP folder:

[imap]
         Folder = "INBOX.Drafts"

A command to open an ssh tunnel to the imap mail server.

[imap]
         Tunnel = "ssh -q user@imap.server.com /usr/bin/imapd ./Maildir
2> /dev/null"

[imap]
         Host = imap.server.com
         User = bob
         Password = pwd
         Port = 143

[jc: with suggestions by Jan-Benedict Glaw]
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Added recently added programs to the default exclude list.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds a git-rm command which provides convenience similar to
git-add, (and a bit more since it takes care of the rm as well if
given -f).

Like git-add, git-rm expands the given path names through
git-ls-files. This means it only acts on files listed in the
index. And it does act recursively on directories by default, (no -r
needed as in the case of rm itself). When it recurses, it does not
remove empty directories that are left behind.
Signed-off-by: NJunio C Hamano <junkio@cox.net>