An earlier commit 61b80509 (sending errors to stdout under $PAGER,
2008-02-16) avoided losing the error messages that are sent to the
standard error when $PAGER is in effect by dup2'ing fd 2 to the pager.
his way, showing a tag object that points to a bad object:

    $ git show tag-foo

would give the error message to the pager.  However, it was not quite
right if the user did:

    $ git show 2>error.log tag-foo

i.e. use the pager but store the errors in a separate file.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When a tag points at a bad or nonexistent object, we should diagnose the
breakage and exit.  An earlier commit 4f3dcc27 (Fix 'git show' on signed
tag of signed tag of commit, 2008-07-01) lost this check and made it
segfault instead; not good.

This fixes it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The logic to mark all objects that are reachable from tips of refs were
implemented as a set of recursive functions.  In a repository with a deep
enough history, this can easily eat up all the available stack space.

Restructure the code to require less stackspace by using an object array
to keep track of the objects that still need to be processed.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Especially on Windows where an opened file cannot be replaced, make
sure pack-objects always close packs it is about to replace. Even on
non Windows systems, this could save potential bad results if ever
objects were to be read from the new pack file using offset from the old
index.

This should fix t5303 on Windows.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Tested-by: Johannes Sixt <j6t@kdbg.org> (MinGW)
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It appears that a reference to an anchor defined as [[anchor-name]] from
another place using <<anchor-name>> syntax, when the anchor name contains
a string "-with-" in its name, triggers these warnings from Python
interpreter.

  asciidoc -b docbook -d book user-manual.txt
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6

There currently is no reference to "Finding comments with given content",
but for consistency and for futureproofing, the anchor is also updated as
the other ones that are actually used and trigger these warnings.
Signed-off-by: NJunio C Hamano <junio@pobox.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn.  If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated.  This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.

To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history.  If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: NDeskin Miller <deskinm@umich.edu>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

According to the message of commit 0fe7c1de,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order.  However, this command reversed the order of its
arguments, resulting in confusing diffs.  A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments.  Test case included.
Signed-off-by: NMatt McCutchen <matt@mattmccutchen.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The user may put some effort into writing an annotated tag
message. When the tagging process later fails (which can
happen fairly easily, since it may be dependent on gpg being
correctly configured and used), there is no record left on
disk of the tag message.

Instead, let's keep the TAG_EDITMSG file around until we are
sure the tag has been created successfully. If we die
because of an error, the user can recover their text from
that file. Leaving the file in place causes no conflicts;
it will be silently overwritten by the next annotated tag
creation.

This matches the behavior of COMMIT_EDITMSG, which stays
around in case of error.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The 'grep' feature was marked in the comments as having project
specific config, but it lacked 'sub' key required for it to work.
Kind-of-Noticed-by: NMatt Kraai <kraai@ftbfs.org>
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

memcpy() may only be used for disjoint memory areas, but when invoked
from cmd_fetch_pack(), we have my_args == &args.  (The argument cannot
be removed entirely because transport.c invokes with its own
variable.)
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jk/maint-commit-v-strip:
  commit: Fix stripping of patch in verbose mode.

In a corner case of large files whose lines do not match uniquely, the
loop to eliminate a line that matches multiple locations adjacent to a run
of lines that do not uniquely match wasted too much cycles.  Fix this by
giving up early after scanning 100 lines in both direction.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* bc/maint-keep-pack:
  repack: only unpack-unreachable if we are deleting redundant packs
  t7700: test that 'repack -a' packs alternate packed objects
  pack-objects: extend --local to mean ignore non-local loose objects too
  sha1_file.c: split has_loose_object() into local and non-local counterparts
  t7700: demonstrate mishandling of loose objects in an alternate ODB
  builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
  repack: do not fall back to incremental repacking with [-a|-A]
  repack: don't repack local objects in packs with .keep file
  pack-objects: new option --honor-pack-keep
  packed_git: convert pack_local flag into a bitfield and add pack_keep
  t7700: demonstrate mishandling of objects in packs with a .keep file

* js/mingw-rename-fix:
  compat/mingw.c: Teach mingw_rename() to replace read-only files

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* st/maint-tag:
  tag: Add more tests about mixing incompatible modes and options
  tag: Check that options are only allowed in the appropriate mode

* mk/maint-cg-push:
  git push: Interpret $GIT_DIR/branches in a Cogito compatible way

In "common" man pages there is luckily no "NAME" anywhere except at
beginning of documents. If there is another "NAME", sed could
mis-select it and lead to common-cmds.h corruption. So better nail it
at beginning of line, which would reduce corruption chance.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* mv/fast-export:
  fast-export: use an unsorted string list for extra_refs
  Add new testcase to show fast-export does not always exports all tags

An earlier commit 916d081b (Nicer error messages in case saving an object
to db goes wrong, 2006-11-09) confused EACCES with EPERM, the latter of
which is an unlikely error from mkstemp().
Signed-off-by: NSam Vilain <sam@vilain.net>

This avoids the following misleading error message:

error: unable to create temporary sha1 filename ./objects/15: File exists

mkstemp can fail for many reasons, one of which, ENOENT, can occur if
the directory for the temp file doesn't exist. create_tmpfile tried to
handle this case by always trying to mkdir the directory, even if it
already existed. This caused errno to be clobbered, so one cannot tell
why mkstemp really failed, and it truncated the buffer to just the
directory name, resulting in the strange error message shown above.

Note that in both occasions that I've seen this failure, it has not been
due to a missing directory, or bad permissions, but some other, unknown
mkstemp failure mode that did not occur when I ran git again. This code
could perhaps be made more robust by retrying mkstemp, in case it was a
transient failure.
Signed-off-by: NJoey Hess <joey@kitenet.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

I think it's unnecessary to warn that the checkout has been forced due to an
unborn current branch if -f has been explicitly passed.  For one project, I am
using git-new-workdir to create workdirs from a bare repository whose HEAD is
set to an unborn branch, and this warning started to irritate me.
Signed-off-by: NMatt McCutchen <matt@mattmccutchen.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The completion script for 'git revert' currently offers options and
filenames.  However, 'git revert' doesn't take any filenames from the
command line, but a single commit.  Therefore, it's more sane to offer
refs instead.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 5a625b07 (bash: remove fetch, push, pull dashed form leftovers,
2008-10-03) did that already, but there were still some git-cmd left
here and there.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* pw/maint-p4:
  git-p4: fix keyword-expansion regex

This text:

     my $dir = $File::Find::dir;
     return if ($dir !~ m,$options->{dirpat}$,);

was improperly converted to:

     my $dir = $File$dir !~ m,$options->{dirpat}$,);

by the keyword identifier expansion code.  Add a \n
to make sure the regex doesn't go across end-of-line
boundaries.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NSimon Hausmann <simon@lst.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NRalf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* mm/maint-sort-config-doc:
  config.txt: alphabetize configuration sections

I figured the sections might as well be in some order, so I chose alphabetical
but with "core" at the beginning.  This should help people add new variables
in the right places.
Signed-off-by: NMatt McCutchen <matt@mattmccutchen.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The original intention of 72909bef (Add diff-option --ext-diff, 2007-06-30)
was to optionally allow the use of external diff viewer in "git log"
family (while keeping them disabled by default).  It exposed the "allow
external diff" bit to the UI, but forgot to adjust the "git diff" codepath
that was set up to always allow use of the external diff viewer.

Noticed by Nazri Ramliy; tests by René Scharfe squashed in.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The list extra_refs contains tags and the objects referenced by them,
so that they can be handled at the end.  When a tag references a
commit, that commit is added to the list using the same name.

Also, the function handle_tags_and_duplicates() relies on the order
the items were added to extra_refs, so clearly we do not want to
use a sorted list here.

Noticed by Miklos Vajna.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Documentation for -n implies that -x is normally
used, however this is no longer true.
Signed-off-by: NBryan Drewery <bryan@shatow.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On POSIX, rename() can replace files that are not writable. On Windows,
however, read-only files cannot be replaced without additional efforts:
We have to make the destination writable first.

Since the situations where the destination is read-only are rare, we do not
make the destination writable on every invocation, but only if the first
try to rename a file failed with an "access denied" error.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: NStefan Naewe <stefan.naewe@atlas-elektronik.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Originally --with-tree=<tree> was designed for the sole purpose of
checking if a given pathspec makes sense as a parameter to git-commit
using it in conjunction with --error-unmatch.  It had logic to avoid
showing the same entry (one came from the original index, another from the
overlayed tree) twice so that it works with -c (i.e. "show-cached"), but
otherwise it was not designed to work with the flags such as -m, -d, etc.

This teaches the same logic to cover the codepath for -m and -d.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>