fr: a lot of good fixups

Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
Acked-by: Jean-Noel Avila <jn.avila@free.fr>
git-gui: tolerate major version changes when comparing the git version

Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
the following error:

   No working directory ../../../<path>

   couldn't change working directory
   to "../../../<path>": no such file or
   directory

This is because "git rev-parse --show-toplevel" is only run when git gui
sees a git version of at least 1.7.0 (which is the version in which the
--show-toplevel option was introduced). But "package vsatisfies" returns
false when the major version changes, which is not what we want here.

Fix that for both places where the git version is checked using vsatisfies
by appending a '-' to the version number. This tells vsatisfies that a
change of the major version is not considered to be a problem, as long as
the new major version is larger. This is done for both the place that
caused the reported bug and another spot where the git version is tested
for another feature.

Reported-by: Chris Packham <judge.packham@gmail.com>
Reported-by: Yann Dirson <ydirson@free.fr>
Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical/api-hashmap: remove source highlighting

The highlighting was pretty, but unfortunately, the failure mode
when source-highlight is not installed was that the entire code
block disappears.

See https://bugs.debian.org/745591,
    https://bugs.launchpad.net/bugs/1316810.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'kb/fast-hashmap'

* kb/fast-hashmap:
  Documentation/technical/api-hashmap: remove source highlighting
Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  fr: a lot of good fixups
Merge branch 'jl/use-vsatisfy-correctly-for-2.0'

* jl/use-vsatisfy-correctly-for-2.0:
  git-gui: tolerate major version changes when comparing the git version
Merge branch 'lt/request-pull'

* lt/request-pull:
  request-pull: resurrect for-linus -> tags/for-linus DWIM
replace: make sure --edit results in a different object

It's a bad idea to create a replace ref for an object
that points to the original object itself.

That's why we have to check if the result from editing
the original object is a different object and error out
if it isn't.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace: refactor checking ref validity

This will be useful in a following commit when we will
want to check if the ref already exists before we let the
user edit an object.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace: die early if replace ref already exists

If a replace ref already exists for an object, it is
much better for the user if we error out before we
let the user edit the object, rather than after.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace: add tests for --edit

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace: add --edit to usage string

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: replace: describe new --edit option

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-prompt.sh: don't assume the shell expands the value of PS1

Not all shells subject the prompt string to parameter expansion.  Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.

This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
don't put unsanitized branch names in $PS1"):  zsh does not expand PS1
by default, but that commit assumed it did.  The bug resulted in
prompts containing the literal string '${__git_ps1_branch_name}'
instead of the actual branch name.

Reported-by: Caleb Thompson <caleb@calebthompson.io>
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't assume the shell expands the value of PS1
Revert "Merge branch 'fc/transport-helper-sync-error-fix'"

This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f,
reversing changes made to e42552135a2a396f37053a89f44952ea907870b2.

The author of the original topic says he broke the upcoming 2.0
release with something that relates to "synchronization crash
regression" while refusing to give further specifics, so this would
unfortunately be the safest option for the upcoming release.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib: remote-helpers: add move warnings (v2.0)

The tools are now maintained out-of-tree, and they have a regression
in v2.0. It's better to start warning the users as soon as possible.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-helpers: point at their upstream repositories

Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-helpers: give short instructions to download the latest

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "Merge branch 'jl/vcompare-makes-2.0-satisify-1.7-or-later' into next"

This reverts commit 57e5fc1cfb7e8c074f0bc9bf2be546f102c9e117, reversing
changes made to 6c8fb526c38e34e5cb3cbb033d7e585abb4b4f8e.