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

When performing a non-interactive rebase, sometimes
"git rebase --continue" will fail if an unmodified file is
touched in the working directory:

    You must edit all merge conflicts and then
    mark them as resolved using git add

This is caused by "git diff-files" reporting a difference
between the index and the filesystem:

    :100644 100644 d00491...... 000000...... M	file

The fix is to run "git update-index --refresh" before
"git diff-files" as is done in git-rebase--interactive.
Signed-off-by: NDavid D. Kilzer <ddkilzer@kilzer.net>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The behavior of "git ls-files -t" is very misleading (see
http://thread.gmane.org/gmane.comp.version-control.git/126516 and
http://thread.gmane.org/gmane.comp.version-control.git/144394/focus=144397
for examples of mislead users) and badly documented, hence we point the
users to superior alternatives.

The feature is marked as "semi-obsolete" but not "scheduled for removal"
since it's a plumbing command, scripts might use it, and Git testsuite
already uses it to test the state of the index.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

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

If $HOME is unset (as in some automated build situations),
currently

	git config --path path.home "~"
	git config --path --get path.home

segfaults.  Error out with

	Failed to expand user dir in: '~/'

instead.
Reported-by: NJulien Cristau <jcristau@debian.org>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

From api-parse-options.txt:

  `description` is a short string to describe the effect of the option.
  It shall begin with a lower-case letter and a full stop (`.`) shall be
  omitted at the end.

It also makes it less confusing if the argument is 'no.' or 'no'.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The message is especially confusing when "git fetch" is ran from "git
pull", for users not aware of "git fetch". The new message makes it clear
that "fetch" means "fetch new revisions", and gives hint on the solution.

We don't add a advice.* configuration option since this message doesn't
appear in normal use, and shouldn't disturb advanced users.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The manpage was added in 1ed6f2c5 (Documentation: gitrevisions,
2010-07-05), but since it does not have a corresponding git command,
it needs an exception for check-docs.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Acked-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

8b1fa778 (Allow passing of configuration parameters in the command
line, 2010-03-26) forgot the closing ']' for the -c option.

While we're there, also rewrap.  Instead of folding the last two lines
together, try to highlight that COMMAND is required by starting a line
with it.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Mention the effects of the receive.deny* family of options for the
"remote rejected" case.  While there, also split up the explanation
into an easier-to-parse list format.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This option was introduced by 747ca245 (receive-pack:
receive.denyDeleteCurrent, 2009-02-08) but never documented.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The NULL sentinel argument to the execl*() family of calls must be
cast to (char *), as otherwise:

- platforms where NULL is just 0 (not (void *)) would pass an int

- (admittedly esoteric) platforms where NULL is (void *)0 and (void *)
  and (char *) have different memory layouts would pass the wrong kind
  of pointer
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Without additional configuration steps, the documentation build on Cygwin
fails because the XML catalog is missing required rewrites for certain
docbook resources.

This patch documents the required configuration.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

One test case checked the stdout and stderr of 'git add' by constructing a
single 'expect' file that contained both streams. But when the command
runs, the order of stdout and stderr output is unpredictable because it
depends on how the streams are buffered. At least on Windows, the buffering
is different from what the test case expected. Hence, check the two output
texts separately.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Acked-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On systems with an echo which defaults to the XSI-conformant behavior
(Solaris, or others using Ksh), echo will interpret certain backslashed
characters as control sequences.  This can cause a problem for interactive
rebase when it is used to rebase commits whose commit "subject" (the first
line) contains any of these backslashed sequences.  In this case, echo will
substitute the control sequence for the backslashed characters and either
the rebased commit message will differ from the original, or the rebase
process will fail.  Neither is desirable.

So work around this issue by replacing the echo statements used to print
out portions of the commit message, with printf.

Also, add a test to test for this breakage.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Acked-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On some systems, the chrome browser is named google-chrome.  We add
support for this case.
Signed-off-by: NNathan W. Panike <nathan.panike@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.7.1:
  request-pull.txt: Document -p option
  Check size of path buffer before writing into it

* maint-1.7.0:
  request-pull.txt: Document -p option
  Check size of path buffer before writing into it

* maint-1.6.6:
  request-pull.txt: Document -p option
  Check size of path buffer before writing into it
  rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option

* maint-1.6.5:
  request-pull.txt: Document -p option
  Check size of path buffer before writing into it
  rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option

Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.6.4:
  Check size of path buffer before writing into it
  rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option

This prevents a buffer overrun that could otherwise be triggered by
creating a file called '.git' with contents

  gitdir: (something really long)
Signed-off-by: NGreg Brockman <gdb@mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On Arch Linux, the executable for the Apache HTTP server keeps
the 'httpd' name and is not named 'apache2'. The path to the
server modules also contains 'httpd' rather than 'apache2'.
Remove some of these assumptions and add the httpd name in where
it may be required. Finally, make some slight style adjustments
to the code we are touching to make it fit the style of the rest
of the script.
Signed-off-by: NDan McGee <dpmcgee@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

We were passing the non-existent GIT_EXEC_DIR through instead of the real
GIT_EXEC_PATH. In addition, these weren't being passed at all for CGI (non
mod_perl) execution so get them included there as well.
Signed-off-by: NDan McGee <dpmcgee@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

'CustomLog' is provided by mod_log_config so we need to include the module
in our generated config. This was added in d94775e1.
Signed-off-by: NDan McGee <dpmcgee@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

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

These two tests weren't about how "git reflog show <branch>" exits when
there is no reflog, but were about "checkout" and "branch" create or not
create reflog when creating a new <branch>.  Update the tests to check
what we are interested in, using "git rev-parse --verify".

Also lose tests based on "test -f .git/logs/refs/heads/<branch>" from
nearby, to avoid exposing this particular implementation detail
unnecessarily.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

The correct advice should have been taken from c289c315 (t/t7006: ignore
return status of shell's unset builtin, 2010-06-02).  A real-life issue
we experienced was with "unset", not with "export" (exporting an
unset variable may have similar portability issues, though).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The '!()' notation is interpreted as a pattern-list on Ksh.  The Ksh man
page describe it as follows:

   !(pattern-list)
      Matches anything except one of the given patterns.

Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list.  If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These two lines use the negation '!' operator to negate the result of a
simple command.  Since these commands do not contain any pipes or other
complexities, the test_must_fail function can be used and is preferred
since it will additionally detect termination due to a signal.

This was noticed because the second use of '!' does not include a space
between the '!' and the opening parens.  Ksh interprets this as follows:

   !(pattern-list)
      Matches anything except one of the given patterns.

Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list.  If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  t/README: clarify test_must_fail description
  Check size of path buffer before writing into it

Conflicts:
	t/README

Some have found the wording of the description to be somewhat ambiguous
with respect to when it is desirable to use test_must_fail instead of
"! <git-command>".  Tweak the wording somewhat to hopefully clarify that
it is _because_ test_must_fail can detect segmentation fault that it is
desirable to use it instead of "! <git-command>".
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This prevents a buffer overrun that could otherwise be triggered by
creating a file called '.git' with contents

  gitdir: (something really long)
Signed-off-by: NGreg Brockman <gdb@mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>