pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses

Normally parse_pathspec() is used on command line arguments where it
can do fancy thing like parsing magic on each argument or adding magic
for all pathspecs based on --*-pathspecs options.

There's another use of parse_pathspec(), where pathspec is needed, but
the input is known to be pure paths. In this case we usually don't
want --*-pathspecs to interfere. And we definitely do not want to
parse magic in these paths, regardless of --literal-pathspecs.

Add new flag PATHSPEC_LITERAL_PATH for this purpose. When it's set,
--*-pathspecs are ignored, no magic is parsed. And if the caller
allows PATHSPEC_LITERAL (i.e. the next calls can take literal magic),
then PATHSPEC_LITERAL will be set.

This fixes cases where git chokes when GIT_*_PATHSPECS are set because
parse_pathspec() indicates it won't take any magic. But
GIT_*_PATHSPECS add them anyway. These are

   export GIT_LITERAL_PATHSPECS=1
   git blame -- something
   git log --follow something
   git log --merge

"git ls-files --with-tree=path" (aka parse_pathspec() in
overlay_tree_on_cache()) is safe because the input is empty, and
producing one pathspec due to PATHSPEC_PREFER_CWD does not take any
magic into account.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git 1.8.5-rc2

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "upload-pack: send non-HEAD symbolic refs"

This reverts commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c; there
may be unbounded number of symbolic refs in the repository, but the
capability header line in the on-wire protocol has a rather low
length limit.
branch: fix --verbose output column alignment

Commit f2e0873 (branch: report invalid tracking branch as gone) removed
an early return from fill_tracking_info() in the path taken when 'git
branch -v' lists a branch in sync with its upstream. This resulted in an
unconditionally added space in front of the subject line:

    $ git branch -v
    * master f5eb3da  commit pushed to upstream
      topic  f935eb6 unpublished topic

Instead, only add the trailing space if a decoration have been added.

To catch this kind of whitespace breakage in the tests, be a bit less
smart when filtering the output through sed.

Signed-off-by: Torstein Hegge <hegge@resisty.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jx/branch-vv-always-compare-with-upstream'

Hot-fix for a regression.

* jx/branch-vv-always-compare-with-upstream:
  branch: fix --verbose output column alignment
Merge branch 'maint'

Hotfix for recent regression while talking to upload-pack
in a repository with many symbolic refs.

* maint:
  Revert "upload-pack: send non-HEAD symbolic refs"
Merge branch 'nd/literal-pathspecs'

Fixes a regression on 'master' since v1.8.4.

* nd/literal-pathspecs:
  pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses
RelNotes: spelling & grammar fixes

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mb/relnotes-1.8.5-fix'

* mb/relnotes-1.8.5-fix:
  RelNotes: spelling & grammar fixes
Git 1.8.4.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.8.4.4
Git 1.8.5-rc3

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email: Added the ability to query the number of smtp password questions

With this patch "git-send-mail" ask a configurable number of questions to
input the smtp password. Without this patch we have only one trial.

Signed-off-by: Silvio F <silvio.fricke@gmail.com>
git-credential: Add Flag to credential to mark as interactive

This patch comes from this mail-thread:
http://www.spinics.net/lists/git/msg220410.html

On Tue, Nov 12, 2013 at 09:57:39AM -0800, Junio C Hamano wrote:

> > With this patch "git-send-mail" ask a configurable number of questions to
> > input the smtp password. Without this patch we have only one trial.
>
> I wonder if Git::credential (or even the underlying lower level
> credential_fill() in the helper API) should give hints to the caller
> if calling it again may yield a different result.  An interactive
> prompt may allow the user to mistype the password and then a later
> call may return a correct one, but the .netrc helper will read from
> the file and will return a fixed result, so there is no use calling
> credential_fill() again.  And in the latter case, you do not want to
> loop $askpasswordcount times.

It would be pretty easy to add an "interactive=true" flag to the
credential response (patch below). Credential readers are supposed to
ignore elements that they don't understand. So storage helpers which are
told "we got a password interactively" can choose to use that
information if they want, but current implementations will fall back to
ignoring it. Similarly, users of "git credential fill" can use it, but
it won't hurt existing readers.

> I also have to wonder if this logic belongs to git-send-email.
> Specifically, I wonder if we can place the looping logic in
> Git::credential, so that other users of the library can take
> advantage of it?

A very early draft of the credential code added looping, but I cut it
out (I think before it even made it to the list). I don't recall the
exact reason, but it was probably a combination of:

  1. It's awkward to do at the credential layer in C, because you need
     input from the calling code on whether the credential worked or
     not. The perl Git::credential can take a callback, though, which
     means the credential code owns the outer loop, and it would be
     pretty easy to just loop on trying.

  2. We already have a retry mechanism; it is called "shell history". :)

The second one is only somewhat tongue in cheek. If we were an
interactive program, retrying would be essential. But fetch and push
tend to be very easy to simply re-run, as they perform only a single
action that either works or does not. So I have not really seen anyone
make a request for the feature.

I guess "send-email" does not (always) fall under the same category
because the user may have put work into a cover letter, or filling
interactive fields. So I have no objection to adding it there, but I do
agree we might as well put it in Git::credential.

Tested-by: Silvio F. <silvio.fricke@gmail.com>
WIP: test interactive flag

Signed-off-by: Silvio F <silvio.fricke@gmail.com>