Documentation/git-svn: Promote the use of --prefix in docs + examples

Currently, the git-svn defaults to using an empty prefix, which ends
up placing the SVN-tracking refs directly in refs/remotes/*. This
placement runs counter to Git's convention of placing remote-tracking
branches in refs/remotes/$remote/*.

Furthermore, combining git-svn with "regular" Git remotes run the risk
of clobbering refs under refs/remotes (e.g. if you have a git remote
called "tags" with a "v1" branch, it will overlap with the git-svn's
tracking branch for the "v1" tag from Subversion.

Even though the git-svn refs stored in refs/remotes/* are not "proper"
remote-tracking branches (since they are not covered by a proper git
remote's refspec), they clearly represent a similar concept, and would
benefit from following the same convention.

For example, if git-svn tracks Subversion branch "foo" at
refs/remotes/foo, and you create a local branch refs/heads/foo to add
some commits to be pushed back to Subversion (using "git svn dcommit),
then it is clearly unhelpful of Git to throw

  warning: refname 'foo' is ambiguous.

every time you checkout, rebase, or otherwise interact with the branch.

At this time, the user is better off using the --prefix=foo/ (the
trailing slash is important) to git svn init/clone, to cause the
SVN-tracking refs to be placed at refs/remotes/foo/* instead of
refs/remotes/*. This patch updates the documentation to encourage
use of --prefix.

This is also in preparation for changing the default value of --prefix
at some point in the future.

Cc: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn: Warn about changing default for --prefix in Git v2.0

In Git v2.0, we will change the default --prefix for init/clone from
none/empty to "origin/" (which causes SVN-tracking branches to be
placed at refs/remotes/origin/* instead of refs/remotes/*).

This patch warns users about the upcoming change, both in the git-svn
manual page, and on stderr when running init/clone in the "multi-mode"
without providing a --prefix.

Cc: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
.mailmap: switch to Thomas Rast's personal address

Normalize to my personal address, as my ETH addresses will expire
soon.  Also add my new corp account to be somewhat futureproof.

Note that despite the private address being first, Google owns the
copyright as long as I am employed there.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
mergetools/diffmerge: support DiffMerge as a git mergetool

DiffMerge is a non-free (but gratis) tool that supports OS X, Windows and Linux.

    See http://www.sourcegear.com/diffmerge/

DiffMerge includes a script `/usr/bin/diffmerge` that can be used to launch the
graphical compare tool.

This change adds mergetool support for DiffMerge and adds 'diffmerge' as an
option to the mergetool help.

Signed-off-by: Stefan Saasen <ssaasen@atlassian.com>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
mv: Fix spurious warning when moving a file in presence of submodules

In commit 0656781fa "git mv" learned to update the submodule path in the
.gitmodules file when moving a submodule in the work tree. But since that
commit update_path_in_gitmodules() gets called no matter if we moved a
submodule or a regular file, which is wrong and leads to a bogus warning
when moving a regular file in a repo containing a .gitmodules file:

    warning: Could not find section in .gitmodules where path=<filename>

Fix that by only calling update_path_in_gitmodules() when moving a
submodule. To achieve that, we introduce the special SUBMODULE_WITH_GITDIR
define to distinguish the cases where we also have to connect work tree
and git directory from those where we only need to update the .gitmodules
setting.

A test for submodules using a .git directory together with a .gitmodules
file has been added to t7001. Even though newer git versions will always
use a gitfile when cloning submodules, repositories cloned with older git
versions will still use this layout.

Reported-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
test: use unambigous leading path (/foo) for MSYS

In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
such DOS drive on MSYS platform. Use an umambigous leading path
"/foo" instead.

Also change two leading slashes (//) to three leading slashes (///),
otherwize it will be recognized as UNC name on MSYS platform.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
relative_path should honor dos-drive-prefix

Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS drive prefix
(such as "C:/windows"). ($gmane/234434)

E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
should return "C:/a/b", but returns "../../C:/a/b", which is wrong.

So make relative_path honor DOS drive prefix, and add test cases
for it in t0060.

Reported-by: Tvangeste <i.4m.l33t@yandex.ru>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Use simpler relative_path when set_git_dir

Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as git_dir may bring troubles like
$gmane/234434.

Because new relative_path is a combination of original relative_path
from path.c and original path_relative from quote.c, so in order to
restore the origin implementation, save the original relative_path
as remove_leading_path, and call it in setup.c.

Suggested-by: Karsten Blees <karsten.blees@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
http: enable keepalive on TCP sockets

This is a follow up to commit e47a8583 (enable SO_KEEPALIVE for
connected TCP sockets, 2011-12-06).

Sockets may never receive notification of some link errors,
causing "git fetch" or similar processes to hang forever.
Enabling keepalive messages allows hung processes to error out
after a few minutes/hours depending on the keepalive settings of
the system.

I noticed this problem with some non-interactive cronjobs getting
hung when talking to HTTP servers.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
howto/setup-git-server-over-http: fix unescaped '^'s

The text contains two 'grep' invocations which include the 'start
of line' regular expression character '^'. Asciidoc mis-interprets
this use of '^' as a superscript request. In order to fix this
formatting problem, use backticks (`) to quote the text of the
affected 'grep' command invocations.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
howto/revert-a-faulty-merge: fix unescaped '^'s

Several uses of the '^' operator are being interpreted by asciidoc
as requests to show the following text as a superscript. In order
to fix this problem, use backticks (`) to quote the text of the
affected git command invocations.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
path-utils test: rename mingw_path function to print_path

mingw_path was introduced in abd4284 to output a mangled path as it is
passed as an argument to main(). But the name is misleading because
mangling does not come from MinGW, but from MSYS [1]. As abd4284 does not
introduce any MSYS or MinGW specific code but just prints out argv[2] as
it is passed to main(), give the function the more generic and less
confusing name "print_path".

[1] http://www.mingw.org/wiki/Posix_path_conversion

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
git-prompt.sh: optionally show upstream branch name

When working with multiple remotes, it is common to switch the upstream
from a remote to another. Doing so, the prompt may not be the expected
one. Providing an option to display tracking information sounds useful.

Add a "name" option to GIT_PS1_SHOWUPSTREAM which will show the upstream
abbrev name. This option is ignored if "verbose" is false.

Signed-off-by: Julien Carsique <julien.carsique@gmail.com>
Improved-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Merge branch 'jk/diff-algo'

* jk/diff-algo:
  merge-recursive: fix parsing of "diff-algorithm" option
Merge branch 'jx/clean-interactive'

* jx/clean-interactive:
  path-utils test: rename mingw_path function to print_path
Merge branch 'nd/clone-local-with-colon'

* nd/clone-local-with-colon:
  clone: tighten "local paths with colons" check a bit
Merge branch 'po/remote-set-head-usage'

* po/remote-set-head-usage:
  remote set-head -h: add long options to synopsis
  remote doc: document long forms of set-head options
Merge branch 'rj/doc-formatting-fix'

* rj/doc-formatting-fix:
  howto/revert-a-faulty-merge: fix unescaped '^'s
  howto/setup-git-server-over-http: fix unescaped '^'s
Merge branch 'rt/cherry-pick-status'

* rt/cherry-pick-status:
  status: show commit sha1 in "You are currently cherry-picking" message
  status test: add missing && to <<EOF blocks
Merge branch 'sb/checkout-test-complex-path'

* sb/checkout-test-complex-path:
  checkout test: enable test with complex relative path