File mode changes should be handled similarly to changes of content.
That is, if the file mode changed in only one branch, keep the changed
version, and if both branch changed to different mode, mark it as a
conflict.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The wording of the interactive help text from git-add--interactive.perl is
clearer.  Just duplicate that text here.
Signed-off-by: NVineet Kumar <vineet@doorstop.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Prior to commit 83201998 (Rewrite builtin-fetch option parsing to use
parse_options().), we understood '-n' as a short option to mean "don't
fetch tags from the remote". This patch reinstates behaviour similar,
but not identical to the pre commit 83201998 times.

Back then, -n always overrode --tags, so if both --tags and -n was
given on command-line, no tags were fetched regardless of argument
ordering. Now we use a "last entry wins" strategy, so '-n --tags'
means "fetch tags".

Since it's patently absurd to say both --tags and --no-tags, this
shouldn't matter in practice.
Spotted-by: NArtem Zolochevskiy <azol@altlinux.org>
Reported-by: NDmitry V. Levin <ldv@altlinux.org>
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

commit-tree fails when specifying a remote name (via -r option) and
one of the parent branch has a name. Prefixing with "$remote/" fix it.
Signed-off-by: NMarc-Andre Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) didn't set project info correctly
when current page URL is in pathinfo form.

This resulted in broken links such like:

  http://www.example.com/w/ARRAY(0x85a5318)?a=shortlog;pg=1

if the 'pathinfo' feature was used, or

  http://www.example.com/w/?a=shortlog;pg=1

if it wasn't, instead of correct:

  http://www.example.com/w/project.git?a=shortlog;pg=1

This was caused by the fact that href() always replays params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature couldn't deal with $params{'project'}
being arrayref.

Setting $params{'project'} is moved before replaying params; this
ensures that 'project' parameter is processed correctly.
Noticed-by: NPeter Oberndorfer <kumbayo84@arcor.de>
Noticed-by: NWincent Colaiuta <win@wincent.com>
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Just let the user know that a revision argument is missing instead of
a perl error. This error message mimic the "init" error message, but
could be improved.
Signed-off-by: NMarc-Andre Lureau <marcandre.lureau@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Solaris' /usr/bin/tr doesn't seem to like multiple character
ranges in brackets (it simply prints "Bad string").

Instead, let's just enumerate the transformation we want.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The construct

	sh -c "$0 \"$@\"" <editor> <file>

does not pick up quotes in <editor>, so you cannot give path to the
editor that has a shell IFS whitespace in it, and also give it initial
set of parameters and flags.  Replace $0 with <editor> to fix this issue.

This fixes

	git config core.editor '"c:/Program Files/What/Ever.exe"'

In other words, you can specify an editor with spaces in its path using a
config containing something like this:

	[core]
		editor = \"c:/Program Files/Darn/Spaces.exe\"

NOTE: we cannot just replace the $0 with \"$0\", because we still want
this to work:

	[core]
		editor = emacs -nw
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously, --abort would end by git resetting to ORIG_HEAD, but some
commands, such as git reset --hard (which happened in git rebase --skip,
but could just as well be typed by the user), would have already modified
ORIG_HEAD.

Just use the orig-head we store in $dotest instead.

[jc: cherry-picked from 48411d and 4947cf9c on 'master']
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* kb/maint-filter-branch-disappear:
  filter-branch: handle "disappearing tree" case correctly in subdir filter

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

We might eventually be loosening this rule, but there is a longstanding
restriction that the users currently need to be aware of.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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 subdirectory filter had a bug to notice that the commit in question
did not have anything in the path-limited part of the tree.  $commit:$path
does not name an empty tree when $path does not appear in $commit.

This should fix it.  The additional test in t7003 is originally from Kevin
Ballard but with fixups.
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>

* 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.

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>

* '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>

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>

Back in 18f7c51c we switched git-ls-remote/git-peek-remote to
use the transport backend, rather than do everything itself.

As part of that switch we started to produce a non-zero exit
status if no refs were received from the remote peer, which
happens when the remote peer has no commits pushed to it yet.
(E.g. "git --git-dir=foo.git init; git ls-remote foo.git")
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A merge is not necessarily with a remote branch, it can be with any
commit.

Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having

 git merge --no-commit --no-ff <branch>

actually commit the merge.  Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options.  However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that

 git merge --squash --no-ff <branch>

fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge.  The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.

The unexpected behavior was reported by John Goerzen through
 http://bing.sdebian.org/468568Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.

The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.

Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:

    test_expect_success 'reject bogus request' '
        do something &&
        do something else &&
        ! git command
    '

but a non-zero exit could come from the "git command" segfaulting.

A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail").  The above example should be written as:

    test_expect_success 'reject bogus request' '
        do something &&
        do something else &&
        test_must_fail git command
    '
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Fix typo in 'test -z "url"' when checking whether a submodule url is
empty. "url" should be "$url".
Signed-off-by: NPing Yin <pkufranky@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

511707d4 (use only the $PATH for exec'ing git commands) made it a
requirement to call setup_path() to include the git exec-dir in PATH
before spawning any other git commands. git-receive-pack was not yet
adapted to do this and therefore fails to spawn git-unpack-objects if that
is not in the standard PATH.
Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-status used the buffer name to find git-status buffers, and that
can fail if the buffer has another name, for example when multiple
working directories is tracked.
Signed-off-by: NRémi Vanicat <vanicat@debian.org>
Acked-by: NAlexandre Julliard <julliard@winehq.org>
Tested-by: NXavier Maillard <xma@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Paper bag fix info dialog when no files are staged at commit