* maint:
  GIT 1.5.4.4
  ident.c: reword error message when the user name cannot be determined
  Fix dcommit, rebase when rewriteRoot is in use
  Really make the LF after reset in fast-import optional

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

The "config --global" suggested in the message is a valid one-shot fix,
and hopefully one-shot across machines that NFS mounts the home directories.

This knowledge can hopefully be reused when you are forced to use git on
Windows, but the fix based on GECOS would not be applicable, so
it is not such a useful hint to mention the exact reason why the
name cannot be determined.
Signed-off-by: NSanti Béjar <sbejar@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the rewriteRoot setting is used with git-svn, it causes the svn
IDs added to commit messages to bear a different URL than is actually
used to retrieve Subversion data.

It is common for Subversion repositories to be available multiple
ways: for instance, HTTP to the public, and svn+ssh to people with
commit access.  The need to switch URLs for access is fairly common as
well -- perhaps someone was just given commit access.  To switch URLs
without having to rewrite history, one can use the old url as a
rewriteRoot, and use the new one in the svn-remote url setting.

This works well for svn fetching and general git commands.

However, git-svn dcommit, rebase, and perhaps other commands do not
work in this scenario.  They scan the svn ID lines in commit messages
and attempt to match them up with url lines in [svn-remote] sections
in the git config.

This patch allows them to match rewriteRoot options, if such options
are present.
Signed-off-by: NJohn Goerzen <jgoerzen@complete.org>
Acked-by: NEric Wong <normalperson@yhbt.net>

The configuration variables for custom merge tools were documented
only in config.txt but there was no reference to the functionality in
git-mergetool.txt.
Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

cmd_from() ends with a call to read_next_command(), which is needed
when using cmd_from() from commands where from is not the last element.

With reset, however, "from" is the last command, after which the flow
returns to the main loop, which calls read_next_command() again.

Because of this, always set unread_command_buf in cmd_reset_branch(),
even if cmd_from() was successful.

Add a test case for this in t9300-fast-import.sh.
Signed-off-by: NAdeodato Simó <dato@net.com.org.es>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* aw/maint-shortlog-blank-lines:
  shortlog: take the first populated line of the description

* mh/maint-http-proxy-fix:
  Set proxy override with http_init()

* js/maint-daemon:
  daemon: ensure that base-path is an existing directory
  daemon: send more error messages to the syslog

* js/maint-cvsexport:
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Conflicts:

	t/t9200-git-cvsexportcommit.sh

* jc/maint-log-merge-left-right:
  Fix "git log --merge --left-right"

* ew/maint-svn-cert-fileprovider:
  git-svn: Don't prompt for client cert password everytime.

* maint:
  unquote_c_style: fix off-by-one.
  test-lib: fix TERM to dumb for test repeatability
  config.txt: refer to --upload-pack and --receive-pack instead of --exec
  git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

The logic to countermand suppression of Cc to the signers with a more
explicit --signed-off-by option done in 65648283 (git-send-email:
Generalize auto-cc recipient mechanism) suffers from a double-negation
error.

A --signed-off-cc option, when false, should actively suppress CC: to be
generated out of S-o-b lines, and it should refrain from suppressing when
it is true.

It also fixes "(sob) Adding cc:" status output; earlier it included the
line terminator LF inside '%s', which was totally bogus.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* js/reflog-delete:
  t3903-stash.sh: Add tests for new stash commands drop and pop
  git-reflog.txt: Document new commands --updateref and --rewrite
  t3903-stash.sh: Add missing '&&' to body of testcase
  git-stash: add new 'pop' subcommand
  git-stash: add new 'drop' subcommand
  git-reflog: add option --updateref to write the last reflog sha1 into the ref
  refs.c: make close_ref() and commit_ref() non-static
  git-reflog: add option --rewrite to update reflog entries while expiring
  reflog-delete: parse standard reflog options
  builtin-reflog.c: fix typo that accesses an unset variable
  Teach "git reflog" a subcommand to delete single entries

* dc/format-pretty:
  log/show/whatchanged: introduce format.pretty configuration
  specify explicit "--pretty=medium" with `git log/show/whatchanged`
  whatchanged documentation: share description of --pretty with others

* cb/mergetool:
  Add a very basic test script for git mergetool
  Teach git mergetool to use custom commands defined at config time
  Changed an internal variable of mergetool to support custom commands
  Tidy up git mergetool's backup file behaviour

The optional endp parameter to unquote_c_style() was supposed to point at
a location past the closing double quote, but it was going one beyond it.

git-fast-import used this function heavily and the bug caused it to
misparse the input stream, especially when parsing a rename command:

	R "filename that needs quoting" rename-target-name

Because the function erroneously ate the whitespace after the closing dq,
this triggered "Missing space after source" error when it shouldn't.

Thanks to Adeodato Simò for having caught this.
Signed-off-by: NPierre Habouzit <madcoder@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Dscho noticed that Term::ReadLine (used by send-email) colorized its
output for his TERM settings, inside t9001 tests.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The options --upload-pack (of git-fetch-pack) and --receive-pack (of
git-push) do the same as --exec (for both commands).  But the former options
have the more descriptive name.
Signed-off-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* ar/sgid-bsd:
  Do not use GUID on dir in git init --shared=all on FreeBSD

* cc/run-command:
  run-command: Redirect stderr to a pipe before redirecting stdout to stderr

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

Way back the perl version of shortlog would take the first populated line
of the commit body.  The builtin version mearly takes the first line.
This leads to empty shortlog entries when there is some viable text in
the commit.

Reinstate this behaviour igoring all lines with nothing but whitespace.
This is often useful when dealing with commits imported from foreign SCMs
that do not tidy up the log message of useless blank lines at the beginning.
Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It does not allow changing the bit to a non-root user.
This fixes t1301-shared-repo.sh on the platform.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

With this patch, in the 'start_command' function after forking
we now take care of stderr in the child process before stdout.

This way if 'start_command' is called with a 'child_process'
argument like this:

	.err = -1;
	.stdout_to_stderr = 1;

then stderr will be redirected to a pipe before stdout is
redirected to stderr. So we can now get the process' stdout
from the pipe (as well as its stderr).

Earlier such a call would have redirected stdout to stderr
before stderr was itself redirected, and therefore stdout
would not have followed stderr, which would not have been
very useful anyway.

Update documentation in 'api-run-command.txt' accordingly.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Acked-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

But still all branches are listed, if -r is present
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>

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>

Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently git mergetool is restricted to a set of commands defined
in the script. You can subvert the mergetool.<tool>.path to force
git mergetool to use a different command, but if you have a command
whose invocation syntax does not match one of the current tools then
you would have to write a wrapper script for it.

This patch adds two git config variable patterns which allow a more
flexible choice of merge tool.

If you run git mergetool with -t/--tool or the merge.tool config
variable set to an unrecognized tool then git mergetool will query the
mergetool.<tool>.cmd config variable. If this variable exists, then git
mergetool will treat the specified tool as a custom command and will use
a shell eval to run the command with the documented shell variables set.

mergetool.<tool>.trustExitCode can be used to indicate that the exit
code of the custom command can be used to determine the success of the
merge.
Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The variable $path changes to $MERGED so that it is more consistent
with $BASE, $LOCAL and $REMOTE for future custom command lines.
Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently a backup pre-merge file with conflict markers is sometimes
kept with a .orig extenstion and sometimes removed depending on the
particular merge tool used.

This patch makes the handling consistent across all merge tools and
configurable via a new mergetool.keepBackup config variable
Signed-off-by: NCharles Bailey <charles@hashpling.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When running log/show/whatchanged from the command line, the user may
want to use a preferred format without having to pass --pretty=<fmt>
option every time from the command line.  This teaches these three
commands to honor a new configuration variable, format.pretty.

The --pretty option given from the command line will override the
configured format.

The earlier patch fixed the in-tree callers that run these commands
for purposes other than showing the output directly to the end user
(the only other in-tree caller is "git bisect visualize", whose output
directly goes to the end user and should be affected by this patch).

Similar fixes will be needed for end-user scripts that parse the
output from these commands and expect them to be in the default pretty
format.
Signed-off-by: NDenis Cheng <crquan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The following patch will introduce a new configuration variable,
"format.pretty", from then on the pretty format without specifying
"--pretty" might not be the default "--pretty=medium", it depends on
the user's config. So all kinds of Shell/Perl/Emacs scripts that needs
the default medium pretty format must specify it explicitly.
Signed-off-by: NDenis Cheng <crquan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The documentation had its own description for --pretty and did not
include pretty-options/formats as documentation for other commands in
the "log" family did.
Signed-off-by: NDenis Cheng <crquan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

ba002f3b (builtin-fsck: move common object checking code to fsck.c) did
more than what it claimed to.  Most notably, it wrongly made an empty tree
object an error by pretending to only move code from fsck_tree() in
builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check
to barf on an empty tree.

An empty tree object is _unusual_.  Recent porcelains try reasonably hard
not to let the user create a commit that contains such a tree.  Perhaps
warning about them in git-fsck may have some merit.

HOWEVER.

Being unusual and being errorneous are two quite different things.  This
is especially true now we seem to use the same fsck_$object() code in
places other than git-fsck itself.  For example, receive-pack should not
reject unusual objects, even if it would be a good idea to tighten it to
reject incorrect ones.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl.  Falling back to po2msg.sh on such systems
is a reasonable behavior.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This reverts commit d5ef408b.

This reverts commit 28f72a0f.