mergetools/p4merge: swap LOCAL and REMOTE

Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.

This change makes use of P4Merge consistent with its built-in help, its
reference documentation, and Perforce itself. But most importantly, it
makes merge results clearer. P4Merge is not totally symmetrical between
left and right; despite changing a few text labels from "theirs/ours" to
"left/right" when invoked manually, it still retains its original
Perforce "theirs/ours" viewpoint.

Most obviously, in the result pane P4Merge shows changes that are common
to both branches in green. This is on the basis of the current branch
being green, as it is when invoked from Perforce; it means that lines in
the result are blue if and only if they are being changed by the merge,
making the resulting diff clearer.

Note that P4Merge now shows "ours" on the right for both diff and merge,
unlike other diff/mergetools, which always have REMOTE on the right.
But observe that REMOTE is the working tree (ie "ours") for a diff,
while it's another branch (ie "theirs") for a merge.

Ours and theirs are reversed for a rebase - see "git help rebase".
However, this does produce the desired "show the results of this commit"
effect in P4Merge - changes that remain in the rebased commit (in your
branch, but not in the new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so this is next best.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:

   p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"

Commit 0a0ec7bd changed this to:

   p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"

to avoid the problem of being unable to save in some circumstances with
similar inputs.

Unfortunately this approach produces much worse results on differing
inputs. P4Merge really regards the blank file as the base, and once you
have just a couple of differences between the two branches you end up
with one a massive full-file conflict. The 3-way diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
useful view.

The original approach appears to have invoked special 2-way merge
behaviour in P4Merge that occurs only if the base filename is "" or
equal to the left input.  You get a good visual comparison, and it does
not auto-resolve differences. (Normally if one branch matched the base,
it would autoresolve to the other branch).

But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base==left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.

So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. This is the same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.

Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files.  As with the other merges using this
technique, we assume the user will inspect the result before saving.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge-one-file: revise merge error reporting

Commit 718135e improved the merge error reporting for the resolve
strategy's merge conflict and permission conflict cases, but led to a
malformed "ERROR:  in myfile.c" message in the case of a file added
differently.

This commit reverts that change, and uses an alternative approach without
this flaw.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
shell doc: emphasize purpose and security model

The original git-shell(1) manpage emphasized that the shell supports
only git transport commands.  As the shell gained features, that
emphasis and focus in the manual has been lost.  Bring it back by
splitting the manpage into a few short sections and fleshing out each:

 - SYNOPSIS, describing how the shell gets used in practice
 - DESCRIPTION, which gives an overview of the purpose and guarantees
   provided by this restricted shell
 - COMMANDS, listing supported commands and restrictions on the
   arguments they accept
 - INTERACTIVE USE, describing the interactive mode

Also add a "see also" section with related reading.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
shell: new no-interactive-login command to print a custom message

If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, attempts to use 'ssh' in produce a
message intended for the administrator:

	$ ssh git@myserver
	fatal: Interactive git shell is not enabled.
	hint: ~/git-shell-commands should exist and have read and execute access.
	$

That is helpful for the new admin who is wondering "What? Why isn't
the git-shell I just set up working?", but once the site setup is
complete, it would be better to give the user a friendly hint that she
is on the right track, like GitHub does.

	Hi <username>! You've successfully authenticated, but
	GitHub does not provide shell access.

An appropriate greeting might even include more complex dynamic
information, like gitolite's list of repositories the user has access
to.  Add support for a ~/git-shell-commands/no-interactive-login
command that generates an arbitrary greeting.  When the user tries to
log in:

 * If the file ~/git-shell-commands/no-interactive-login exists,
   run no-interactive-login to let the server say what it likes,
   then hang up.

 * Otherwise, if ~/git-shell-commands/ is present, start an
   interactive read-eval-print loop.

 * Otherwise, print the usual configuration hint and hang up.

Reported-by: Ethan Reesor <firelizzard@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup.c: check that the pathspec magic ends with ")"

The previous code did not diagnose an incorrectly spelled ":(top"
as an error.

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mg/qnx6' into pu

Still under discussion.
Not ready for inclusion.

* mg/qnx6:
  QNX: newer QNX 6.x.x is not so crippled
Merge branch 'jn/shell-disable-interactive' into pu

Expecting a reroll.
$gmane/216229

* jn/shell-disable-interactive:
  shell: new no-interactive-login command to print a custom message
  shell doc: emphasize purpose and security model
Merge branch 'mb/gitweb-highlight-link-target' into pu

Expecting a reroll.
$gmane/211935

* mb/gitweb-highlight-link-target:
  Highlight the link target line in Gitweb using CSS
Merge branch 'mb/remote-default-nn-origin' into pu

When the user does not specify what remote to interact with, we
often attempt to use 'origin'.  This can now be customized via a
configuration variable.

Expecting a reroll.
$gmane/210151

"The first remote becomes the default" bit is better done as a
separate step.

* mb/remote-default-nn-origin:
  Teach get_default_remote to respect remote.default.
  Test that plain "git fetch" uses remote.default when on a detached HEAD.
  Teach clone to set remote.default.
  Teach "git remote" about remote.default.
  Teach remote.c about the remote.default configuration setting.
  Rename remote.c's default_remote_name static variables.

Conflicts:
	builtin/remote.c
	t/t5505-remote.sh
Merge branch 'mg/unsigned-time-t' into pu

A few workarounds for systems with unsigned time_t.

* mg/unsigned-time-t:
  Fix time offset calculation in case of unsigned time_t
  date.c: fix unsigned time_t comparison
Merge branch 'hv/config-from-strbuf' into pu

Expecting a reroll.
$gmane/217163

* hv/config-from-strbuf:
  teach config parsing to read from strbuf
  config: make parsing stack struct independent from actual data source
  config: drop file pointer validity check in get_next_char()
  config: factor out config file stack management
Merge branch 'tr/line-log' into pu

* tr/line-log:
  log -L: :pattern:file syntax to find by funcname
  Implement line-history search (git log -L)
  Export rewrite_parents() for 'log -L'
  blame: introduce $ as "end of file" in -L syntax
  Refactor parse_loc

Conflicts:
	log-tree.c
Merge branch 'pc/subtree-add-before-fetch' into pu

Comments?

* pc/subtree-add-before-fetch:
  contrib/subtree: allow addition of remote branch with name not locally present
Merge branch 'gp/forbid-describe-all-match' into pu

"describe --match=<pattern> --all <commit>" ought to mean "use refs
that match <pattern> to describe <commit>; you do not have to limit
yourself to annotated tags."  But it doesn't.  Disable the
combination.

We may want to discard this if jc/describe topic turns out to be a
better idea.

* gp/forbid-describe-all-match:
  describe: make --all and --match=PATTERN mutually incompatible
Merge branch 'po/help-guides' into pu

Give more visibility to "concept guides" to help "git help" users.

Expecting a reroll.
$gmane/217384

* po/help-guides:
  help doc: include --guide option description
  help.c: add list_common_guides_help() function
  help.c: add --guide option
  help.c: use OPT_COUNTUP
  show 'git help <guide>' usage, with examples
Merge branch 'aw/setup-prefix-pathspec' into pu

Expecting a reroll.
$gmane/217618

* aw/setup-prefix-pathspec:
  setup.c: check that the pathspec magic ends with ")"
  setup.c: stop prefix_pathspec() from looping past the end of string
Merge branch 'pw/p4-symlinked-root' into pu

Expecting a reroll.
$gmane/217641

* pw/p4-symlinked-root:
  git p4: avoid expanding client paths in chdir
  git p4 test: should honor symlink in p4 client root
  git p4 test: make sure P4CONFIG relative path works
Merge branch 'kb/p4merge' into pu

* kb/p4merge:
  git-merge-one-file: revise merge error reporting
  mergetools/p4merge: create a base if none available
  mergetools/p4merge: swap LOCAL and REMOTE