Merge branch 'jc/request-pull-match-tagname'

"git request-pull $url dev" when the tip of "dev" branch was tagged
with "ext4-for-linus" used the contents from the tag in the output
but still asked the "dev" branch to be pulled, not the tag.

* jc/request-pull-match-tagname:
  request-pull: really favor a matching tag

Merge branch 'jk/clone-local'

"git clone --local $path" started its life as an experiment to
optionally use link/copy when cloning a repository on the disk, but
we didn't deprecate it after we made the option a no-op to always
use the optimization.

The command learns "--no-local" option to turn this off, as a more
explicit alternative over use of file:// URL.

* jk/clone-local:
  clone: allow --no-local to turn off local optimizations
  docs/clone: mention that --local may be ignored

Merge branch 'jc/bundle-complete-notice'

Running "git bundle verify" on a bundle that records a complete
history said "it requires these 0 commits".

* jc/bundle-complete-notice:
  tweak "bundle verify" of a complete history

Kick off post 1.7.11 cycle

I haven't decided what to call this one, 1.7.12, 1.8.0, or even 2.0.
Given that summer is a relatively slow season, I suspect 1.7.12 is
the most likely outcome, but we will see.

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

docs: always define git-relative-html-prefix attribute

Commit fe77b41 introduced a new attribute to let the linkgit macro
create cross-directory HTML references from the technical/ and howto/
subdirectories back to the main documentation. We define that attribute
to "../" on the command-line when building inside those subdirectories,
and otherwise leave it unset under the assumption that it would default
to being blank.  Instead, asciidoc omits the link entirely, leading to
broken documentation. Fix this by defining git-relative-html-prefix to
blank in asciidoc.conf (and an instance on the command-line, when
present, will override it).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: fold MISC_H into LIB_H

We keep a list of most of the header files in LIB_H, but
some are split out into MISC_H. The original point
of LIB_H was that it would force recompilation of C files
when any of the library headers changed. It was
over-encompassing, since not all C files included all of the
library headers; this made it simple to maintain, but meant
that we sometimes recompiled when it was not necessary.

Over time, some new headers were omitted from LIB_H, and
rules were added to the Makefile for a few specific targets
to explicitly depend on them. This avoided some unnecessary
recompilation at the cost of having to maintain the
dependency list of those targets manually (e.g., d349a03).

Later, we needed a complete list of headers from which we
should extract strings to localized. Thus 1b8b2e4 introduced
MISC_H to mention all header files not included in LIB_H,
and the concatenation of the two lists is fed to xgettext.
Headers mentioned as dependencies must also be manually
added to MISC_H to receive the benefits of localization.

Having to update multiple locations manually is a pain and
has led to errors. For example, see "git log -Swt-status.h
Makefile" for some back-and-forth between the two locations.
Or the fact that column.h was never added to MISC_H, and
therefore was not localized (which is fixed by this patch).
Moreover, the benefits of keeping these few headers out of
LIB_H is not that great, for two reasons:

  1. The better way to do this is by auto-computing the
     dependencies, which is more accurate and less work to
     maintain. If your compiler supports it, we turn on
     computed header dependencies by default these days. So
     these manual dependencies are used only for people who
     do not have gcc at all (which increases the chance of
     them becoming stale, as many developers will never even
     use them).

  2. Even if you do not have gcc, the manual header
     dependencies do not help all that much.  They obviously
     cannot help with an initial compilation (since their
     purpose is to avoid unnecessary recompilation when a
     header changes), which means they are only useful when
     building a new version of git in the working tree that
     held an existing build (e.g., after checkout or during a
     bisection). But since a change of a header in LIB_H
     will force recompilation, and given that the vast
     majority of headers are in LIB_H, most version changes
     will result in a full rebuild anyway.

Let's just fold MISC_H into LIB_H and get rid of these
manual rules. The worst case is some extra compilation, but
even that is unlikely to matter due to the reasons above.

The one exception is that we should keep common-cmds.h
separate. Because it is generated, the computed dependencies
do not handle it properly, and we must keep separate
individual dependencies on it. Let's therefore rename MISC_H
to GENERATED_H to make it more clear what should go in it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: sort LIB_H list

This was mostly sorted already, but put things like
"cache-tree.h" after "cache.h", even though "-" comes before
"." (at least in the C locale). This will make it easier to
keep the list sorted later by piping it through "sort".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: respect $GIT_DIR

The __gitdir() helper function finds out the path of the git
repository by running 'git rev-parse --git-dir'.  However, it has a
shortcut first to avoid the overhead of running a git command in a
subshell when the current directory is at the top of the work tree,
i.e. when it contains a '.git' subdirectory.

If the 'GIT_DIR' environment variable is set then it specifies the
path to the git repository, and the autodetection of the '.git'
directory is not necessary.  However, $GIT_DIR is only taken into
acocunt by 'git rev-parse --git-dir', and the check for the '.git'
subdirectory is performed first, so it wins over the path given in
$GIT_DIR.

There are several completion (helper) functions that depend on
__gitdir(), and when the above case triggers the completion script
will do weird things, like offering refs, aliases, or stashes from a
different repository, or displaying wrong or broken prompt, etc.

So check first whether $GIT_DIR is set, and only proceed with checking
the '.git' directory in the current directory if it isn't.  'git
rev-parse' would also check whether the path in $GIT_DIR is a proper
'.git' directory, i.e. 'HEAD', 'refs/', and 'objects/' are present and
accessible, but we don't have to be that thorough for the bash prompt.
And we've lived with an equally permissive check for '.git' in the
current working directory for years anyway.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

show: fix "range implies walking"

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

Demonstrate git-show is broken with ranges

The logic of git-show has remained largely unchanged since around
5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start
a revision walker with no_walk=1, look at its pending objects and
handle them one-by-one.  For commits, this means stuffing them into a
new queue all alone, and running the walker.

Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came
along and set no_walk=0 whenever the user specifies a range.  Which
appears to work fine, until you actually prod it hard enough, as the
preceding commit shows: UNINTERESTING commits will be marked as such,
but not walked further to propagate the marks.

Demonstrate this with the main tests of this patch: 'showing a range
walks (Y shape)'.  The Y shape of history ensures that propagating the
UNINTERESTING marks is necessary to correctly exclude the main1
commit.  The only example I could find actually requires that the
negative revisions are listed later, and in this scenario a dotted
range actually works.  However, it is easy to find examples in git.git
where a dotted range is wrong, e.g.

  $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l
  1297
  $ git rev-list v1.7.0..v1.7.1 | wc -l
  702

While there, also test a few other things that are not covered so far:
the -N way of triggering a range (added in 5853cae, DWIM 'git show -5'
to 'git show --do-walk -5', 2010-06-01), and the interactions of tags,
commits and ranges.

Pointed out by Dr_Memory on #git.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remove the impression of unexpectedness when access is denied

If a server accessed through ssh is denying access git will currently
issue the message

"fatal: The remote end hung up unexpectedly"

as the last line. This sounds as if something really ugly just happened.
Since this is a quite typical situation in which users regularly get
we do not say that if it happens at the beginning when reading the
remote heads.

If its in the very first beginning of reading the remote heads it is
very likely an authentication error or a missing repository.

If it happens later during reading the remote heads we still indicate
that it happened during this initial contact phase.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rt/trans'

git-gui: de.po: translate "remote" as "extern"

According to the translation in git-core, we
translate "remote" as "extern".

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

git-gui: de.po: translate "bare" as "bloß"

According to the translation in git-core, we
translate "bare" as "bloß".

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

git-gui: de.po: consistently add untranslated hook names within braces

The user might not really know what hook is
actually meant if it's translated. To avoid such
a confusion we should consistently write it untranslated
within braces after.

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

git-commit-tree(1): update synopsis

Even with many new kinds of options, the command still takes the
single <tree> as the first argument.

Probably we would want to update the command to allow it to take
<tree>-ish at the end for consistency.

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

Documentation: spelling fixes

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

verify_filename(): ask the caller to chose the kind of diagnosis

verify_filename() can be called in two different contexts. Either we
just tried to interpret a string as an object name, and it fails, so
we try looking for a working tree file (i.e. we finished looking at
revs that come earlier on the command line, and the next argument
must be a pathname), or we _know_ that we are looking for a
pathname, and shouldn't even try interpreting the string as an
object name.

For example, with this change, we get:

  $ git log COPYING HEAD:inexistant
  fatal: HEAD:inexistant: no such path in the working tree.
  Use '-- <path>...' to specify paths that do not exist locally.
  $ git log HEAD:inexistant
  fatal: Path 'inexistant' does not exist in 'HEAD'

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_name: do not trigger detailed diagnosis for file arguments

diagnose_invalid_sha1_path() is meant to be called to diagnose a
misspelt <treeish>:<pathname> when <pathname> does not exist in
<treeish>.  However, the code may call it if <treeish>:<pathname> is
invalid (which triggers another call with only_to_die == 1), but for
another reason. This happens when calling e.g.

  git log existing-file HEAD:existing-file

because existing-file is a path and not a revision, the code
verifies that the arguments that follow to be paths.  This leads to
an incorrect message like "existing-file does not exist in HEAD",
even though the path exists in HEAD.

Check that the search for <pathname> in <treeish> fails before
triggering the diagnosis.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_name.c: indentation fix

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

Git 1.7.11

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

Sync with 1.7.10.5

Git 1.7.10.5

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

Do not autosquash in case of an implied interactive rebase

The option to autosquash is only used in case of an interactive rebase.
When merges are preserved, rebase uses an interactive rebase internally,
but in this case autosquash should still be disabled.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/maint-fast-export-mark-error' into maint

"git fast-export" did not give a readable error message when the same
mark erroneously appeared twice in the --import-marks input.

perl/Makefile: move "mkdir -p" to module installation loop for maintainability

In the NO_PERL_MAKEMAKER=YesPlease fallback case, make the directory
that will contain each module when installing it (simulating "install
-D") instead of hardcoding "Git/SVN/Memoize is the deepest level".
This should make this codepath which is not used often on development
machines a little easier to maintain.

Requested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://github.com/git-l10n/git-po

Updated Italian translations.

* git://github.com/git-l10n/git-po:
  l10n: it.po: translate 212 new messages

Merge branch 'as/diff-shortstat-ignore-binary'

# By Alexander Strasser
* as/diff-shortstat-ignore-binary:
  diff: Only count lines in show_shortstats

diff: Only count lines in show_shortstats

Do not mix byte and line counts. Binary files have byte counts;
skip them when accumulating line insertions/deletions.

The regression was introduced in e18872b.

Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

do not run pager with diff --no-index --quiet

There is no point in running a pager when --quiet is given,
since we are producing no output. The regular diff code path
handles this already, because --quiet implies --exit-code,
and we check for --exit-code when deciding not to run the
pager.

However, the "quiet implies exit-code" logic is done in
diff_setup_done, and the no-index code path sets up its
pager before running diff_setup_done, and misses this case.

We can fix this by reordering our initialization.
Currently we do:

  1. read command line arguments into diff_options

  2. Set pager if EXIT_CODE not requested

  3. always set EXIT_CODE, since we are emulating
     traditional diff

  4. call diff_setup_done

We can fix the problem by moving pager initialization (step
2) after step 4. But step 3 must come after step 2 (since we
want to know whether the _user_ requested --exit-code, not
whether we turned it on unconditionally). So we must move
both.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix pager.diff with diff --no-index

git-diff does not rely on the git wrapper to setup its
pager; instead, it sets it up on its own after seeing
whether --quiet or --exit-code has been specified.  After
diff_no_index was split off from cmd_diff, commit b3fde6c
(git diff --no-index: default to page like other diff
frontends, 2008-05-26) duplicated the one-liner from
cmd_diff to turn on the pager.

Later, commit 8f0359f (Allow pager of diff command be
enabled/disabled, 2008-07-21) taught the the version in
cmd_diff to respect the pager.diff config, but the version
in diff_no_index was left behind. This meant that

  git -c pager.diff=0 diff a b

would not use a pager, but

  git -c pager.diff=0 diff --no-index a b

would.  Let's fix it by factoring out a common function.

While we're there, let's update the antiquated comment,
which claims that the pager interferes with propagating the
exit code; this has not been the case since ea27a18 (spawn
pager via run_command interface, 2008-07-22).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perl/Makefile: install Git::SVN::* when NO_PERL_MAKEMAKER=yes, too

v1.7.11-rc1~12^2~2 (2012-05-27) and friends split some git-svn code
into separate modules but did not update the fallback rules to install
them when NO_PERL_MAKEMAKER is set.  Add the appropriate rules so
users without MakeMaker can use git-svn again.

Affected modules: Git::SVN::Prompt, Git::SVN::Fetcher,
Git::SVN::Editor, Git::SVN::Ra, Git::SVN::Memoize::YAML.

Reported-by: Adam Roben <adam@roben.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmali.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perl/Makefile.PL: warn about duplicate module list in perl/Makefile

Adding or removing a module requires modifying both files to support
builds with and without MakeMaker.  Add a comment to remind patch
authors and reviewers at the crucial moment.

Longer term, it would be nicer to maintain a single list, perhaps in a
separate file used by both build systems.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin.h: remove unused cmd_<foo> declarations

These were left in builtin.h after they were converted into
stand-alone programs or removed after experiments finished.

Signed-off-by: Luka Perkov <lists@lukaperkov.net>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-cherry-pick.txt: clarify the use of revision range notation

When given a set of commits, cherry-pick will apply the changes for
all of them. Specifying a simple range will also work as expected.

This can lead the user to think that

    git cherry-pick A B..C

may apply A and then B..C, but that is not what happens.

Instead the revs are given to a single invocation of rev-list, which
will consider A and C as positive revs and B as a negative one.  The
commit A will not be used if it is an ancestor of B.

Add a note about this and add an example with this particular
syntax, which has shown up on the list a few times.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: --no-walk is no-op if range is specified

The existing description can be misleading and cause the reader to
think that --no-walk will do something if they specify a range in the
command line instead of a set of revs.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7400: avoid path mangling issues

A recently introduced test uses an absolute path. But when run on Windows
using the MSYS bash, such a path is mangled into a Windows style path when
it is passed to 'git config'. The subsequent 'test' then compares the
mangled path to the unmangled version and reports a failure.

A path beginning with two slashes denotes a network directory
(//server/share path) and is not mangled. Use that trick to side-step the
issue. Just in case that 'git submodule init' regresses in such a way that
it accesses the URL, use a path name that is unlikely to exist on POSIX
systems, and that cannot be a server name on Windows.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Do not use bare 0 to mean (point-min)

Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Use with-current-buffer where appropriate

In git-blame-filter and git-blame-create-overlay we want to save
(along with the values of point and mark) the current-buffer in scope
when calling the functions.  The idiom

    (save-excursion
      (set-buffer buf)
      ...)

will correctly restore the correct buffer, but will not save the
values of point and mark in buf (only in the buffer current when the
save-excursion call is executed).  The intention of these functions is
to save the current buffer from the calling scope and the values of
point and mark in the buffer they are modifying.  The correct idiom
for this is

    (with-current-buffer buf
      (save-excursion
        ...))

Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Do not use goto-line in lisp code

goto-line is a user-level command, instead use the lisp-level
construct recommended in Emacs documentation.

Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

status: better advices when splitting a commit (during rebase -i)

Add new informative help messages at the output of 'git status' when
the user is splitting a commit. The code figures this state by
comparing the contents of the following files in the .git/ directory:
  - HEAD
  - ORIG_HEAD
  - rebase-merge/amend
  - rebase-merge/orig-head

Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

status: don't suggest "git rm" or "git add" if not appropriate

The display of the advice '(use git add/rm [...])' (when there are
unmerged files) after running 'git status' is now depending of the
mark, whether it's 'both deleted', 'deleted by us/them' or others. For
instance, when there is just one file that's marked as 'both deleted',
'git status' shows '(use git rm [...])' and if there are two files,
one as 'both deleted' and the other as 'added by them', the advice is
'(use git add/rm [...])'.

The previous tests in t7512-status-help.sh are updated.

Test about the case of only 'both deleted' is added in
t7060-wtstatus.sh

Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7512-status-help.sh: better advices for git status

The following tests include several cases in which the user needs to
run 'git status' to know his current situation, whether there're
conflicts or he's in rebase/bisect/am/cherry-pick progress.

One of the test is about the set of the advice.statushints config key
to 'false' in .git/config.

Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wt-status.*: better advices for git status added

This patch provides new informative help messages in the display of
'git status' (at the top) during conflicts, rebase, am, bisect or
cherry-pick process.

The new messages are not shown when using options such as -s or
--porcelain. The messages about the current situation of the user are
always displayed but the advices on what the user needs to do in order
to resume a rebase/bisect/am/commit after resolving conflicts can be
hidden by setting advice.statushints to 'false' in the config file.

Thus, information about the updated advice.statushints key are added
in Documentation/config.txt.

Also, the test t7060-wt-status.sh is now working with the new help
messages. Tests about suggestions of "git rm" are also added.

Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: it.po: translate 212 new messages

Signed-off-by: Marco Paolone <marcopaolone@gmail.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

rebase -i: teach "--exec <cmd>"

During an interactive rebase session, it is sometimes desirable to
run tests on each commit in the resulting history.  This can be done
by adding "exec <test command>" when editing the insn sheet, but the
command used for testing is often the same for all resulting commits.

By passing "--exec <cmd>" from the command line, automatically add
these "exec" lines after each commit in the final history.  To work
well with the --autosquash option, these are added at the end of
each run of "fixup" and "squash".

Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revision: ignore side parents while running simplify-merges

The simplify_merges() function needs to look at all history chain to
find the closest ancestor that is relevant after the simplification,
but after --first-parent traversal, side parents haven't been marked
for relevance (they are irrelevant by definition due to the nature
of first-parent-only traversal) nor culled from the parents list of
resulting commits.

We cannot simply remove these side parents from the parents list, as
the output phase still wants to see the parents.  Instead, teach
simplify_one() and its callees to ignore the later parents.

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

git: Wrong parsing of ssh urls with IPv6 literals ignores port

If we encounter an address part shaped like "[HOST]:PORT", we skip the opening
bracket and replace the closing one with a NUL.  The variable host then points
to HOST and we've cut off the PORT part.  Thus, when we go looking for it using
host a bit later, we can't find it.  Start at end instead, which either points
to the colon, if present, or is equal to host.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rj/gitweb-test-sans-date-parser'

Regression fix to t9501 introduced at 0f3ddd4

* rj/gitweb-test-sans-date-parser:
  gitweb: Skip 'modification times' tests when no date parser available

Merge branch 'fc/git-complete-helper-fix'

* fc/git-complete-helper-fix:
  completion: put main git and gitk completion functions back into git namespace

archive: ustar header checksum is computed unsigned

POSIX.1 (pax) is pretty clear on this:

  The chksum field shall be the ISO/IEC 646:1991 standard IRV
  representation of the octal value of the simple sum of all octets
  in the header logical record. Each octet in the header shall be
  treated as an unsigned value. These values shall be added to an
  unsigned integer, initialized to zero, the precision of which is
  not less than 17 bits. When calculating the checksum, the chksum
  field is treated as if it were all <space> characters.

so is GNU:

  http://www.gnu.org/software/tar/manual/html_node/Checksumming.html

Found by 7zip folks and reported by Rafał Mużyło.

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

completion: remove credential helpers from porcelain commands

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: put main git and gitk completion functions back into git namespace

Commit 7f02f3d7 (completion: rename internal helpers _git and _gitk,
2012-05-19) renamed said functions to _main_git() and _main_gitk(),
respectively.  By convention the name of our git-completion-specific
functions start with '_git' or '__git' prefix, so rename those
functions once again to put them back into our "namespace".  Use the
two underscore prefix, because _git_main() could be mistaken for the
completion function of the (not yet existing) 'git main' command.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Skip 'modification times' tests when no date parser available

The If-Modified-Since support in Gitweb is conditional on the
availability of a date parser from either the HTTP::Date or
Time::ParseDate modules. If a suitable parser is not available,
then the corresponding 'modification times' tests should be skipped.

Introduce the DATE_PARSER test prerequisite and use it to skip
all of the dependent tests.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: Replace 'perl' by $PERL_PATH

GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a
few tests already actually use this variable when perl is needed. The
other test just call 'perl' and it might happen that the wrong perl
interpreter is used.

This becomes problematic on Windows, when the perl interpreter that is
compiled and installed on the Windows system is used, because this perl
interpreter might introduce some unexpected LF->CRLF conversions.

This patch makes sure that $PERL_PATH is used everywhere in the test suite
and that the correct perl interpreter is used.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.11-rc3

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

Merge git://github.com/git-l10n/git-po

Updates to German, Vietnamese and simplified Chinese translation.

* git://github.com/git-l10n/git-po:
  l10n: de.po: translate 27 new messages
  l10n: Update  po/vi.po to v1.7.11.rc2.2.gb694fbb
  l10n: zh_CN.po: translate 27 new messages
  l10n: Update git.pot (27 new, 1 removed messages)

Merge git://github.com/ralfth/git-po-de

By Ralf Thielow
via Ralf Thielow
* github.com/ralfth/git-po-de:
  l10n: de.po: translate 27 new messages

Merge branch 'mm/api-credentials-doc'

* mm/api-credentials-doc:
  api-credential.txt: document that helpers field is filled-in automatically

Merge branch 'jc/fmt-merge-msg-people'

Tone down the lines that credit people involved and make them
comments, so that integrators who edit their merge messages can
still make use of the information, but lazy ones will not leave
the unverified guesses placed on the "via" line.

* jc/fmt-merge-msg-people:
  fmt-merge-msg: make attribution into comment lines

api-credential.txt: document that helpers field is filled-in automatically

It was unclear whether the field was to be specified by the user of the
API.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/maint-fast-export-mark-error'

* js/maint-fast-export-mark-error:
  fast-export: report SHA-1 instead of gibberish when marks exist already

fast-export: report SHA-1 instead of gibberish when marks exist already

Cc: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: de.po: translate 27 new messages

Translate 27 new messages came from git.pot update
in 7256fd7 (l10n: Update git.pot (27 new, 1 removed messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>

update-index: allow overwriting existing submodule index entries

In commit e01105 Linus introduced gitlinks to update-index. He explains
that he thinks it is not the right thing to replace a gitlink with
something else.

That commit is from the very first beginnings of submodule support.
Since then we have gotten a lot closer to being able to remove a
submodule without losing its history. This check prevents such a use
case, so I think this assumption has changed.

Additionally in the git add codepath we do not have such a check, so for
consistency reasons I think removing this check is the correct thing to
do.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: use YAML format for mergeinfo cache when possible

Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every "git svn fetch".

These caches use the 'nstore' format from the perl core module
Storable, which can be read and written quickly and was designed for
transfer over the wire (the 'n' stands for 'network').  This format is
endianness-independent and independent of floating-point
representation.

Unfortunately the format is *not* independent of the perl version ---
new perl versions will write files that very old perl cannot read.
Worse, the format is not independent of the size of a perl integer.
So if you toggle perl's use64bitint compile-time option, then using
'git svn fetch' on your old repositories produces errors like this:

Byte order is not compatible at ../../lib/Storable.pm (autosplit
into ../../lib/auto/Storable/_retrieve.al) line 380, at
/usr/share/perl/5.12/Memoize/Storable.pm line 21

That is, upgrading perl to a version that uses use64bitint for the
first time makes git-svn suddenly refuse to fetch in existing
repositories.  Removing .git/svn/.caches lets git-svn recover.

It's time to switch to a platform independent serializer backend with
better compatibility guarantees.  This patch uses YAML::Any.

Other choices were considered:

 - thawing data from Data::Dumper involves "eval".  Doing that without
   creating a security risk is fussy.

 - the JSON API works on scalars in memory and doesn't provide a
   standard way to serialize straight to disk.

YAML::Any is reasonably fast and has a pleasant API.  In most
backends, LoadFile() reads the entire file into a scalar anyway and
converts it as a second step, but having an interface that allows the
deserialization to happen on the fly without a temporary is still a
comfort.

YAML::Any is not a core perl module, so we take care to use it when
and only when it is available.  Installations without that module
should fall back to using Storable with all its quirks, keeping their
cache files in

.git/svn/.caches/*.db

Installations with YAML peacefully coexist by keeping a separate set
of cache files in

.git/svn/.caches/*.yaml.

In most cases, switching between is a one-time thing, so it doesn't
seem worth the complication to migrate existing caches.

The upshot: after this patch, as long as YAML::Any is installed you
can move your git repository between machines with different perl
installations and "git svn fetch" will work fine.  If you do not have
YAML::Any, the behavior is unchanged (and in particular does not get
any worse).

Reported-by: Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>
Reported-by: Bdale Garbee <bdale@gag.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn: make Git::SVN::RA a separate file

This slices off another 600 or so lines from the frighteningly long
git-svn.perl script.

The Git::SVN::Ra interface is similar enough to SVN::Ra that it is
probably safe to ignore most of its implementation on first reading.
(Documenting or moving functions that do not fit that pattern is left
as an exercise to the interested reader.)

[ew: rebased and fixed conflict against
 commit c26ddce86d7215b4d9687bd4c6b5dd43a3fabf31
 (git-svn: platform auth providers are working only on 1.6.15 or newer)]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn: make Git::SVN::Editor a separate file

This makes the git-svn script shorter and less scary for beginners to
read through for the first time.  Take the opportunity to explain the
purpose and basic interface of the Git::SVN::Editor class while at it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-blame.el: use mapc instead of mapcar

Using mapcar here is a waste of memory because the mapped result
is not used.

Noticed by emacs ("Warning: `mapcar' called for effect").

[jn: split from a larger patch, with new description]

Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: warn people about duplicated function

The __gitdir function is duplicated between completion and prompt
scripts, and these definitions should not diverge; otherwise one of
them can be subtly broken depending on the order the user's shell
dot-sources them.

Leave a note to people who may want to touch one copy to make sure
they update the other one in sync.  Hopefully this line would also
appear in the context of the patch to allow reviewers to notice a
patch that attempts to update only one of them.

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

l10n: Update  po/vi.po to v1.7.11.rc2.2.gb694fbb

 * Translated 28 strings.

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

revision: note the lack of free() in simplify_merges()

Among the three similar-looking loops that walk singly linked
commit_list, the first one is only peeking and the same list is
later used for real work.  Leave a comment not to mistakenly
free its elements there.

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

revision: "simplify" options imply topo-order sort

The code internally runs sort_in_topo_order() already; it is more clear
to spell it out in the option parsing phase, instead of adding a special
case in simplify_merges() function.

Merge branch 'mm/api-credentials-doc'

Finishing touches...

* mm/api-credentials-doc:
  docs: fix cross-directory linkgit references

docs: fix cross-directory linkgit references

Most of our documentation is in a single directory, so using
linkgit:git-config[1] just generates a relative link in the
same directory. However, this is not the case with the API
documentation in technical/*, which need to refer to
git-config from the parent directory.

We can fix this by passing a special prefix attribute when building
in a subdirectory, and respecting that prefix in our linkgit
definitions.

We only have to modify the html linkgit definition.  For
manpages, we can ignore this for two reasons:

  1. we do not generate actual links to the file in
     manpages, but instead just give the name and section of
     the linked manpage

  2. we do not currently build manpages for subdirectories,
     only html

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: document a couple of options

Document git commit '--branch' and '--no-post-rewrite'.  Mention that
'-z' can also be spelt as '--null'.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN.po: translate 27 new messages

Translate 19 new and 8 fuzzy messages which are marked by shell gettext
wrappers, and ignored by previous 'git.pot' updates.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: Update git.pot (27 new, 1 removed messages)

Extract messages marked by shell gettext wrappers which are ignored
before. See:

 * http://thread.gmane.org/gmane.comp.version-control.git/199112

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

rerere: remove i18n legos in result message

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

notes-merge: remove i18n legos in merge result message

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reflog: remove i18n legos in pruning message

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Remove i18n legos in notifying new branch tracking setup

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

exclude: do strcmp as much as possible before fnmatch

this also avoids calling fnmatch() if the non-wildcard prefix is
longer than basename

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir.c: get rid of the wildcard symbol set in no_wildcard()

Elsewhere in this file is_glob_special() is also used to check for
wildcards, which is defined in ctype. Make no_wildcard() also use this
function (indirectly via simple_length())

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1304: improve setfacl prerequisite setup

t1304 first runs setfacl as an experiment to see whether the
filesystem supports ACLs, and skips the remaining tests if
it does not. However, our setfacl run did not exercise the
ACLs very well, and some filesystems may support our initial
setfacl, but not the rest of the test.

In particular, some versions of ecryptfs will erroneously
apply the umask on top of an inherited directory ACL,
causing our tests to fail. Let's be more careful and make
sure both that we can read back the user ACL we set, and
that the inherited ACL is propagated correctly. The latter
catches the ecryptfs bug, but may also catch other bugs
(e.g., an implementation which does not handle inherited
ACLs at all).

Since we're making the setup more complex, let's move it
into its own test. This will hide the output for us unless
the user wants to run "-v" to see it (and we don't need to
bother printing anything about setfacl failing; the
remaining tests will properly print "skip" due to the
missing prerequisite).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.11-rc2

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

Merge branch 'mm/api-credentials-doc'

* mm/api-credentials-doc:
  api-credentials.txt: add "see also" section
  api-credentials.txt: mention credential.helper explicitly
  api-credentials.txt: show the big picture first
  doc: fix xref link from api docs to manual pages

Merge branch 'rr/maint-t3510-cascade-fix'

* rr/maint-t3510-cascade-fix:
  t3510 (cherry-pick-sequence): add missing '&&'

Merge branch 'jc/svn-auth-providers-unusable-at-1.6.12'

Regression fix for people with libsvn between 1.6.12 and 1.6.15, on
which we tried to use the non-working platform auth providers.

* jc/svn-auth-providers-unusable-at-1.6.12:
  git-svn: platform auth providers are working only on 1.6.15 or newer

Merge branch 'cr/persistent-https'

A remote helper that acts as a proxy and caches ssl session for the
https:// transport is added to the contrib/ area.

By Colby Ranger
* cr/persistent-https:
  Add persistent-https to contrib

fmt-merge-msg: make attribution into comment lines

The submaintainer credit is not something you can compute purely by
looking at the history and its shape, especially in the presense of
fast-forward merges, and this observation makes the information on
the "via" line unreliable.  Let's leave the final determination of
credits up to whoever is making the merge and show them as comments.

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

help: use HTML as the default help format on Windows

When 'git help $cmd' is run without a format option (e.g. -w), the
'man' format is always used. On some platforms, however, manual page
viewers are not often available.

Introduce DEFAULT_HELP_FORMAT make variable in order to allow the
default format configurable at compile time, and set it to HTML when
compiling on Windows (but not Cygwin).

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar

Currently git submodule init and git submodule sync fail with an error
if the superproject origin URL is of the form foo but succeed if the
superproject origin URL is of the form ./foo or ./foo/bar or foo/bar.

This change makes handling of the foo case behave like the handling
of the ./foo case and also ensures that superfluous leading and
embedded ./'s are removed from the resulting derived URLs.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: fix sync handling of some relative superproject origin URLs

When the origin URL of the superproject is itself relative, git submodule sync
configures the remote.origin.url configuration property of the submodule
with a path that is relative to the work tree of the superproject
rather than the work tree of the submodule.

To fix this an 'up_path' that navigates from the work tree of the submodule
to the work tree of the superproject needs to be prepended to the URL
otherwise calculated.

Correct handling of superproject origin URLs like foo, ./foo and ./foo/bar is
left to a subsequent patch since an additional change is required to handle
these cases.

The documentation of resolve_relative_url() is expanded to give a more thorough
description of the function's objective.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir.c: make excluded() file scope static

Now there no longer is external callers of this interface, so we can
make it static.

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

unpack-trees.c: use path_excluded() in check_ok_to_remove()

This function is responsible for determining if a path that is not
tracked is ignored and allow "checkout" to overwrite it as needed.
It used excluded() without checking if higher level directory in the
path is ignored; correct it to use path_excluded() for this check.

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

 * There are uses of lower-level interface excluded_from_list() in
   the codepath for narrow-checkout hack; they are supposed to be
   already checking each level as they descend, and are not touched
   with this patch.

builtin/add.c: use path_excluded()

This only happens in --ignore-missing --dry-run codepath which
presumably nobody should care, but is for completeness.

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

path_excluded(): update API to less cache-entry centric

It was stupid of me to make the API too much cache-entry specific;
the caller may want to check arbitrary pathname without having a
corresponding cache-entry to see if a path is ignored.

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

Merge git://github.com/git-l10n/git-po

German and Chinese translation updates.

By Ralf Thielow (4) and others
via Jiang Xin (1) and Tran Ngoc Quan (1)
* git://github.com/git-l10n/git-po:
  l10n: Update translation for Vietnamese
  l10n: de.po: add additional newline
  l10n: de.po: translate 2 new, 3 fuzzy messages
  l10n: de.po: translate 41 new messages
  l10n: de.po: translate 265 new messages
  l10n: zh_CN.po: translate 2 new, 3 fuzzy messages
  l10n: Update git.pot (5 new, 3 removed messages)

pager: drop "wait for output to run less" hack

Commit 35ce862 (pager: Work around window resizing bug in
'less', 2007-01-24) causes git's pager sub-process to wait
to receive input after forking but before exec-ing the
pager. To handle this, run-command had to grow a "pre-exec
callback" feature. Unfortunately, this feature does not work
at all on Windows (where we do not fork), and interacts
poorly with run-command's parent notification system. Its
use should be discouraged.

The bug in less was fixed in version 406, which was released
in June 2007. It is probably safe at this point to remove
our workaround. That lets us rip out the preexec_cb feature
entirely.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>