Some systems define fopen as a macro based on compiler settings.
The previous technique for reverting to the system fopen function
by merely undefining fopen is inadequate in this case. Instead,
avoid defining fopen entirely when compiling this source file.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Tested-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Before this patch, there were no "git bisect run" example.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The 'git gui' has a number of options that can be specified using the
options dialog. Sometimes it is convenient to be able to specify these
from the command line, therefor document these options.
Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se>
Acked-by: NShawn O. Pearce <speace@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Before this patch in "git-add.txt" and "git-format-patch.txt", the
commands used in the examples were "git-CMD" instead of "git CMD".
This patch fixes that.

In "git-pull.txt" only the last example had the code sample in an
asciidoc "Listing Block", and in the other two files, none.
This patch fixes that by putting all code samples in listing
blocks.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Honour the setgid and umask when re-creating the objects directory
at the destination.

cpio in copy-pass mode aims to copy file permissions which causes this
problem and cannot be disabled. Be explicit by copying the directory
structure first, honouring the permissions at the destination, then copy
the files with 0444 permissions. This also avoids bugs in some versions
of cpio.
Signed-off-by: NMark Hills <mark@pogo.org.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/lstat:
  diff-files: mark an index entry we know is up-to-date as such
  write_index(): optimize ce_smudge_racily_clean_entry() calls with CE_UPTODATE

* bc/filter-branch:
  filter-branch.sh: support nearly proper tag name filtering

* lh/git-file:
  Teach GIT-VERSION-GEN about the .git file
  Teach git-submodule.sh about the .git file
  Teach resolve_gitlink_ref() about the .git file
  Add platform-independent .git "symlink"

* jk/fetch-status:
  git-fetch: always show status of non-tracking-ref fetches

* lh/branch-merged:
  Add tests for `branch --[no-]merged`
  git-branch.txt: compare --contains, --merged and --no-merged
  git-branch: add support for --merged and --no-merged

* pb/remote-mirror-config:
  Add a remote.*.mirror configuration option

Signed-off-by: NJ��rg Sommer <joerg@alea.gnuu.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When having a svn:ignore that ignores the .gitignore file the -f
option to git add must be used to avoid git complaining about adding
an ignored file and hence stop the process of creating .gitignores.
Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In recent versions GNU's git has been renamed to gnuit, document this
while talking about how to resolve the conflict.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  checkout: don't rfc2047-encode oneline on detached HEAD
  filter-branch: Documentation fix.

* maint-1.5.4:
  filter-branch: Documentation fix.

When calling pretty_print_commit, there is an implicit
assumption that passing in a non-NULL "subject" variable
for oneline or email formats means that the output is part
of a subject and therefore "subject" to rfc2047 encoding.
This is not the desired effect when reporting the movement
of detached HEAD.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It's --msg-filter, not --message-filter.
Signed-off-by: NFlorian Ragwitz <rafl@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This eliminates a special case in the show_log() function, to help
simplify the terminator semantics.  Now show_log() always prints a
newline after the log entry when use_terminator is set, even if the log
message is empty.

This change should only affect the --pretty=tformat output, since that
was the only way to trigger this special case.
Signed-off-by: NAdam Simpkins <adam@adamsimpkins.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These variables were made unnecessary by commit
3969cf7d.
Signed-off-by: NAdam Simpkins <adam@adamsimpkins.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When using git-cvsimport, the author is inferred from the cvs commit,
e.g. cvs commit logname is foobaruser, then the author field in git
results in:

Author: foobaruser <foobaruser>

Which is not perfect, but perfectly acceptable given the circumstances.

The default git-svn import however, results in:

Author: foobaruser <foobaruser@acf43c95-373e-0410-b603-e72c3f656dc1>

When using mixes of imports, from CVS and SVN into the same git
repository, you'd like to harmonise the imports to the format cvsimport
uses.
git-svn supports an experimental option --use-log-author which currently
results in the same logentry as without that option when no From: or
Signed-off-by: is found in the logentry ($email currently ends up empty,
and hence is generated again).

This patches harmonises the result with cvsimport, and makes
git-svn --use-log-author produce:

Author: foobaruser <foobaruser>
Signed-off-by: NStephen R. van den Berg <srb@cuci.nl>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  fetch-pack: brown paper bag fix

When I applied Linus's patch from the list by hand somehow I ended
up reversing the logic by mistake.  This fixes it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Most users should be using git-gc instead of directly
calling prune. For those who really do want more information
on pruning, let's point them at git-fsck, which goes into
slightly more detail on reachability.

And since we're pointing users there, let's make sure
reflogs are mentioned in git-fsck(1).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

xread() and xwrite() return ssize_t values as their native POSIX
counterparts read(2) and write(2).

To be consistent, read_in_full() and write_in_full() should also return
ssize_t values.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NRichard Quirk <richard.quirk@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As a nice side effect it also fixes t2002-checkout-cache-u.sh on FreeBSD 4,
/bin/sh of which has problems interpreting "! command" construction.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The command

  git svn clone (URL of an empty SVN repo here)

works, creates an empty git repository. I can perform the initial
commit there, but then, "git svn dcommit" says :

Use of uninitialized value in concatenation (.) or string at .../git-svn line 414.
Committing to  ...
Unable to determine upstream SVN information from HEAD history

I guess a correct management of the initial commit in git-svn would be
hard to implement, but at least, the error message can be improved.
First step is something like the patch below, and better would be for
"git svn clone" to warn that it won't be able to do much with the
cloned repo.
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

make git status act similar to git log and git diff by presenting long
output in a pager.
Signed-off-by: NBart Trojanowski <bart@jukie.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  cvsimport: always pass user data to "system" as a list
  fix reflog approxidate parsing bug
  Fix use after free() in builtin-fetch
  fetch-pack: do not stop traversing an already parsed commit
  Use "=" instead of "==" in condition as it is more portable

* maint-1.5.4:
  cvsimport: always pass user data to "system" as a list
  fix reflog approxidate parsing bug

This avoids invoking the shell. Not only is it faster, but
it prevents the possibility of interpreting our arguments in
the shell.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In get_sha1_basic, we parse a string like

  HEAD@{10 seconds ago}:path/to/file

into its constituent ref, reflog date, and path components.
We never actually munge the string itself, but instead keep
offsets into the string with their associated lengths.

When we call approxidate on the contents inside braces,
however, we pass just a string without a length. This means
that approxidate could sometimes look past the closing brace
and (erroneously) interpret the rest of the string as part
of the date.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As reported by Dave Jones:

Since master.kernel.org updated to latest, I noticed that I could crash
git-fetch by doing this..

export KERNEL=/pub/scm/linux/kernel/git/
git fetch $KERNEL/torvalds/linux-2.6 master:linus

(gdb) bt
 0  0x000000349fd6d44b in free () from /lib64/libc.so.6
 1  0x000000000048f4eb in transport_unlock_pack (transport=0x7ce530) at transport.c:811
 2  0x000000349fd31b25 in exit () from /lib64/libc.so.6
 3  0x00000000004043d8 in handle_internal_command (argc=3, argv=0x7fffea4449f0) at git.c:379
 4  0x0000000000404547 in main (argc=3, argv=0x7fffea4449f0) at git.c:443
 5  0x000000349fd1c784 in __libc_start_main () from /lib64/libc.so.6
 6  0x0000000000403ef9 in ?? ()
 7  0x00007fffea4449d8 in ?? ()
 8  0x0000000000000000 in ?? ()

I then remembered, my .bashrc has this..

export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

which is handy for showing up such bugs.

More info on this glibc feature is at http://udrepper.livejournal.com/11429.htmlSigned-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

f3ec5494 (fetch-pack: check parse_commit/object results, 2008-03-03)
broke common ancestor computation by stopping traversal when it sees
an already parsed commit.  This should fix it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>