delta/git.git/contrib, branch ls/github

Merge branch 'jk/url-insteadof-config' into maint

2017-06-05T00:03:15+00:00

The interaction of "url.*.insteadOf" and custom URL scheme's
whitelisting is now documented better.

* jk/url-insteadof-config:
  docs/config: mention protocol implications of url.insteadOf

Merge branch 'tg/stash-push-fixup' into maint

2017-06-04T01:21:08+00:00

The shell completion script (in contrib/) learned "git stash" has
a new "push" subcommand.

* tg/stash-push-fixup:
  completion: add git stash push

docs/config: mention protocol implications of url.insteadOf

2017-06-01T01:07:10+00:00

If a URL rewrite switches the protocol to something
nonstandard (like "persistent-https" for "https"), the user
may be bitten by the fact that the default protocol
restrictions are different between the two. Let's drop a
note in insteadOf that points the user in the right
direction.

It would be nice if we could make this work out of the box,
but we can't without knowing the security implications of
the user's rewrite. Only the documentation for a particular
remote helper can advise one way or the other. Since we do
include the persistent-https helper in contrib/ (and since
it was the helper in the real-world case that inspired that
patch), let's also drop a note there.

Suggested-by: Elliott Cable 
Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

completion: add git stash push

2017-05-17T03:15:56+00:00

When introducing git stash push in f5727e26e4 ("stash: introduce push
verb", 2017-02-19), I forgot to add it to the completion code. Add it
now.

Signed-off-by: Thomas Gummerer 
Reviewed-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

completion: mark bash script as LF-only

2017-05-10T04:32:51+00:00

Without this change, the completion script does not work, as Bash expects
its scripts to have line feeds as end-of-line markers (this is
particularly prominent in quoted multi-line strings, where carriage
returns would slip into the strings as verbatim characters otherwise).

This change is required to let t9902-completion pass when Git's source
code is checked out with `core.autocrlf = true`.

Signed-off-by: Johannes Schindelin 
Reviewed-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

git-new-workdir: mark script as LF-only

2017-05-10T04:32:50+00:00

Bash does not handle scripts with CR/LF line endings correctly, therefore
they *have* to be forced to LF-only line endings.

Funnily enough, this fixes t3000-ls-files-others and
t1021-rerere-in-workdir when git.git was checked out with
core.autocrlf=true, as these test still use git-new-workdir (once `git
worktree` is no longer marked as experimental, both scripts probably
want to be ported to using that command instead).

Signed-off-by: Johannes Schindelin 
Reviewed-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

Merge branch 'jk/complete-checkout-sans-dwim-remote'

2017-05-01T05:14:41+00:00

Completion for "git checkout " that auto-creates the branch
out of a remote tracking branch can now be disabled, as this
completion often gets in the way when completing to checkout an
existing local branch that happens to share the same prefix with
bunch of remote tracking branches.

* jk/complete-checkout-sans-dwim-remote:
  completion: optionally disable checkout DWIM

completion: optionally disable checkout DWIM

2017-04-24T00:46:31+00:00

When we complete branch names for "git checkout", we also
complete remote branch names that could trigger the DWIM
behavior. Depending on your workflow and project, this can
be either convenient or annoying.

For instance, my clone of gitster.git contains 74 local
"jk/*" branches, but origin contains another 147. When I
want to checkout a local branch but can't quite remember the
name, tab completion shows me 251 entries. And worse, for a
topic that has been picked up for pu, the upstream branch
name is likely to be similar to mine, leading to a high
probability that I pick the wrong one and accidentally
create a new branch.

This patch adds a way for the user to tell the completion
code not to include DWIM suggestions for checkout. This can
already be done by typing:

  git checkout --no-guess jk/

but that's rather cumbersome. The downside, of course, is
that you no longer get completion support when you _do_ want
to invoke the DWIM behavior. But depending on your workflow,
that may not be a big loss (for instance, in git.git I am
much more likely to want to detach, so I'd type "git
checkout origin/jk/" anyway).

Signed-off-by: Jeff King 
Reviewed-by: SZEDER Gábor 
Signed-off-by: Junio C Hamano

completion: expand "push --delete " for refs on that

2017-04-24T00:30:59+00:00

Change the completion of "push --delete  " to complete
refs on that , not all refs.

Before this cloning git.git and doing "git push --delete origin
p" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".

Now p will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.

The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.

Signed-off-by: Ævar Arnfjörð Bjarmason 
Reviewed-by: SZEDER Gábor 
Test-code-by: SZEDER Gábor 
Signed-off-by: Junio C Hamano

Merge branch 'jc/bs-t-is-not-a-tab-for-sed'

2017-04-17T06:29:29+00:00

Code cleanup.

* jc/bs-t-is-not-a-tab-for-sed:
  contrib/git-resurrect.sh: do not write \t for HT in sed scripts