As discussed on the mailing list, the documentation used here was
not quite accurate.  Improve upon it.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If fast-import is being used to update an existing branch of
a repository, the user may not want to lose commits if another
process updates the same ref at the same time.  For example, the
user might be using fast-import to make just one or two commits
against a live branch.

We now perform a fast-forward check during the ref updating process.
If updating a branch would cause commits in that branch to be lost,
we skip over it and display the new SHA1 to standard error.

This new default behavior can be overridden with `--force`, like
git-push and git-fetch.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Since some frontends may be working with source material where
the dates are only readily available as RFC 2822 strings, it is
more friendly if fast-import exposes Git's parse_date() function
to handle the conversion.  This way the frontend doesn't need
to perform the parsing itself.

The new --date-format option to fast-import can be used by a
frontend to select which format it will supply date strings in.
The default is the standard `raw` Git format, which fast-import
has always supported.  Format rfc2822 can be used to activate the
parse_date() function instead.

Because fast-import could also be useful for creating new, current
commits, the format `now` is also supported to generate the current
system timestamp.  The implementation of `now` is a trivial call
to datestamp(), but is actually a whole whopping 3 lines so that
fast-import can verify the frontend really meant `now`.

As part of this change I have added validation of the `raw` date
format.  Prior to this change fast-import would accept anything
in a `committer` command, even if it was seriously malformed.
Now fast-import requires the '> ' near the end of the string and
verifies the timestamp is formatted properly.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Corrected a couple of header markup lines which were shorter than the
actual header, and made the `data` commands two formats into a named
list, which matches how we document the two formats of the `M` command
within a commit.

Also tried to simplify the language about our decimal integer format;
Linus pointed out I was probably being too specific at the cost of
reduced readability.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Andy Parkins and Linus Torvalds both noticed that the description
of the timezone was incorrect.  Its not expressed in minutes.
Its more like "hhmm", where "hh" is the number of hours and "mm"
is the number of minutes shifted from GMT/UTC.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The --branch-log option and its associated code hasn't been used in
several months, as its not really very useful for debugging fast-import
or a frontend.  I don't plan on supporting it in this state long-term,
so I'm killing it now before it gets distributed to a wider audience.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This is a first pass at the manpage for git-fast-import.

I have tried to cover the input format in extreme detail, creating a
reference which is more detailed than the BNF grammar appearing in
the header of fast-import.c.  I have also covered some details about
gfi's performance and memory utilization, as well as the average
learning curve required to create a gfi frontend application (as it
is far lower than it might appear on first glance).

The documentation still lacks real example input streams, which may
turn out to be difficult to format in asciidoc due to the blank lines
which carry meaning within the format.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

Signed-off-by: NTom Prince <tom.prince@ualberta.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Love it or hate it, some people actually still program in Tcl.  Some
of those programs are meant for interfacing with Git.  Programs such as
gitk and git-gui.  It may be useful to have Tcl-safe output available
from for-each-ref, just like shell, Perl and Python already enjoy.

Thanks to Sergey Vlasov for pointing out the horrible flaws in the
first and second version of this patch, and steering me in the right
direction for Tcl value quoting.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

  * The description of valid colour specifications was rather
    incomplete, so fix it so that it actually describes colour specs as
    accepted by color_parse().

  * The list of colour items allowed in color.diff.BLAH was missing the
    `commit' and `whitespace' entries.
Signed-off-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Signed-off-by: NBill Lear <rael@zopyra.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I did this:

  $ git tag -s test-sign
  gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available
  gpg: signing failed: secret key not available
  failed to sign the tag with GPG.

The problem is that I have used the comment field in my key's UID
definition.

  $ gpg --list-keys andy
  pub   1024D/4F712F6D 2003-08-14
  uid                  Andy Parkins (Google) <andyparkins@gmail.com>

So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>";
obviously it's not going to be found.

There shouldn't be a requirement that I use the same form of my name in
my git repository and my gpg key - I might want to be formal (Andrew) in
my gpg key and informal (Andy) in the repository.  Further I might have
multiple keys in my keyring, and might want to use one that doesn't
match up with the address I use in commit messages.

This patch adds a configuration entry "user.signingkey" which, if
present, will be passed to the "-u" switch for gpg, allowing the tag
signing key to be overridden.  If the entry is not present, the fallback
is the original method, which means existing behaviour will continue
untouched.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Document the recommended way to prime a repository with tons of
references with 'pack-refs --all -prune'.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

This introduces the config item remote.<name>.uploadpack to override the
default value (which is "git-upload-pack").
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This allows transfer.unpackLimit to specify what these two
configuration variables want to set.

We would probably want to deprecate the two separate variables,
as I do not see much point in specifying them independently.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes git-fetch over git native protocol to automatically
decide to keep the downloaded pack if the fetch results in more
than 100 objects, just like receive-pack invoked by git-push
does.  This logic is disabled when --keep is explicitly given
from the command line, so that a very small clone still keeps
the downloaded pack as before.

The 100 threshold can be adjusted with fetch.unpacklimit
configuration.  We might want to introduce transfer.unpacklimit
to consolidate the two unpacklimit variables, which will be a
topic for the next patch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Just some option name disambiguation.  This is the counter part to
commit d23842fd which made a similar change for push and send-pack.

--exec continues to work.
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We used to get the following confusing error message:

    $ git commit --amend -a -m foo
    Option -m cannot be combined with -c/-C/-F

This is because --amend cannot be combined with -c/-C/-F, which makes
sense, because they try to handle the same log message in different ways.
So update the documentation to reflect this.
Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Contrary to variable values, in subsection names parsing character
escape codes (besides literal escaping of " as \", and \ as \\)
is not performed; subsection name cannot contain newlines.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Noticed by Franck Bui-Huu.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A short-hand "-g" for "git log --walk-reflogs" and "git
show-branch --reflog" makes it easier to access the reflog
info.

[jc: added -g to show-branch for symmetry]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Separate part of Documentation/config.txt which deals with git config file
syntax into "Syntax" subsection, and expand it.  Add information about
subsections, boolean values, escaping and escape sequences in string
values, and continuing variable value on the next line.

Add also proxy settings to config file example to show example of
partially enclosed in double quotes string value.

Parts based on comments by Junio C Hamano, Johannes Schindelin,
config.c, and the smb.conf(5) man page.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-prune is not safe when run uncontrolled in parallel while
other git operations are creating new objects.  To avoid
mistakes, do not run git-prune by default from git-gc.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This reverts commit 9b088c4e.

Protecting 'mature' objects does not make it any safer.  We should
admit that git-prune is inherently unsafe when run in parallel with
other operations without involving unwarranted locking overhead,
and with the latest git, even rebase and reset would not immediately
create crufts anyway.

Marco Candrian noticed that one cat-file example refers to a
blob object that is never used in the example sequence.

The bug is interesting in that the output from the botched
sample command is consistent with the incorrect blob object
name ;-).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This option gives grace period to objects that are unreachable
from the refs from getting pruned.

The default value is 24 hours and may be changed using
gc.prunegrace.
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now, "git log --abbrev-commit --pretty=o --walk-reflogs HEAD" is
reasonably pleasant to use.
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>

We do not copy this file from elsewhere anymore.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.

You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>.  <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').

Here is a sample output (with --list option):

  $ git show-branch --reflog=10 --list jc/show-reflog
    [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
    [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
    [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
    [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use

This shows what I did more cleanly:

  $ git show-branch --reflog=10 jc/show-reflog
  ! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
   ! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    ! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
     ! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
      ! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
       ! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
        ! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
         ! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
          ! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
           ! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
  ----------
  +          [jc/show-reflog@{0}] show-branch --reflog: show the reflog
    +        [jc/show-reflog@{2}] show-branch --reflog: show the reflog
   +++       [jc/show-reflog@{1}] show-branch --reflog: show the reflog
  +++++      [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
       +     [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
        +    [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
         +   [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
           + [jc/show-reflog@{9}] show-branch --reflog: use updated rea
           + [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
           + [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
           + [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
  ++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM

At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).

I first saved them with "format-patch -4", and then did a reset
at @{8}.  At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent).  I did not like the
log message, so I amended again at @{5}.

Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it).  Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For now it's just to get a more descriptive name.  Later we might update the
push protocol to run more than one program on the other end.  Moreover this
matches better the corresponding config option remote.<name>. receivepack.

--exec continues to work
Signed-off-by: NUwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Having to specify git push --exec=... is annoying if you cannot have
git-receivepack in your PATH on the remote side (or don't want to).

This introduces the config item remote.<name>.receivepack to override
the default value (which is "git-receive-pack").
Signed-off-by: NUwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

add all supported options to Documentation/git-....txt and the usage strings.
Signed-off-by: NUwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds two new classes (pure-helpers and "Interacting with
Others") to the command list in the main manual page.  The
latter class is primarily about foreign SCM interface and is
placed before low-level (plumbing) commands.

Also it promotes a handful commands to mainporcelain category
while demoting some others.
Signed-off-by: NJunio C Hamano <junkio@cox.net>