summaryrefslogtreecommitdiff
path: root/contrib/completion
Commit message (Collapse)AuthorAgeFilesLines
* git-send-email: add --transfer-encoding optionpb/send-email-tePaolo Bonzini2014-11-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'oc/mergetools-beyondcompare'Junio C Hamano2014-10-291-1/+1
|\ | | | | | | | | * oc/mergetools-beyondcompare: mergetool: rename bc3 to bc
| * mergetool: rename bc3 to bcoc/mergetools-beyondcompareJunio C Hamano2014-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | Beyond Compare version 4 works the same way as version 3, so rename the existing "bc3" adaptor to just "bc", while keeping "bc3" as a backward compatible wrapper. Noticed-by: Olivier Croquette <ocroquette@free.fr> Helped-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jk/prompt-stash-could-be-packed' into maintJunio C Hamano2014-09-191-1/+2
| |\ | | | | | | | | | | | | * jk/prompt-stash-could-be-packed: git-prompt: do not look for refs/stash in $GIT_DIR
* | \ Merge branch 'js/completion-hide-not-a-repo'Junio C Hamano2014-10-211-1/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some internal error messages leaked out of the bash completion when typing "git cmd <TAB>" and the machinery tried to complete refnames. * js/completion-hide-not-a-repo: completion: silence "fatal: Not a git repository" error
| * | | completion: silence "fatal: Not a git repository" errorjs/completion-hide-not-a-repoJohn Szakmeister2014-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible that a user is trying to run a git command and fail to realize that they are not in a git repository or working tree. When trying to complete an operation, __git_refs would fall to a degenerate case and attempt to use "git for-each-ref", which would emit the error. Hide this error message coming from "git for-each-ref". Signed-off-by: John Szakmeister <john@szakmeister.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/completion-no-chdir'Junio C Hamano2014-10-161-11/+7
|\ \ \ \ | |/ / / |/| | | | | | | | | | | * jc/completion-no-chdir: completion: use "git -C $there" instead of (cd $there && git ...)
| * | | completion: use "git -C $there" instead of (cd $there && git ...)jc/completion-no-chdirJunio C Hamano2014-10-091-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have had "git -C $there" to first go to a different directory and run a Git command without changing the arguments for quite some time. Use it instead of (cd $there && git ...) in the completion script. This allows us to lose the work-around for misfeatures of modern interactive-minded shells that make "cd" unusable in scripts (e.g. end users' $CDPATH taking us to unexpected places in any POSIX shell, and chpwd functions spewing unwanted output in zsh). Based on Øystein Walle's idea, which was raised during the discussion on the solution by Brandon Turner for a problem zsh users had with RVM which mucks with chpwd_functions in users' environments (https://github.com/wayneeseguin/rvm/issues/3076). As $root variable, which is used to direct where to chdir to, is set to "." based on if $2 to __git_index_files is set (not if it is empty), the only caller of the function is fixed not to pass the optional $2 when it does not want us to switch to a different directory. Otherwise we would end up doing "git -C '' command...", which would not work. Maybe we would want "git -C '' command..." to mean "do not chdir anywhere", but that is a spearate topic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | completion: add --show-signature for log and showda/completion-show-signatureDavid Aguilar2014-10-071-0/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'tb/complete-diff-ignore-blank-lines'Junio C Hamano2014-09-191-2/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | * tb/complete-diff-ignore-blank-lines: completion: Add --ignore-blank-lines for diff
| * | | | completion: Add --ignore-blank-lines for difftb/complete-diff-ignore-blank-linesThomas Braun2014-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/prompt-stash-could-be-packed'Junio C Hamano2014-09-091-1/+2
|\ \ \ \ \ | |_|_|/ / |/| | | / | | |_|/ | |/| | | | | | | | | | | | | | The prompt script checked $GIT_DIR/ref/stash file to see if there is a stash, which was a no-no. * jk/prompt-stash-could-be-packed: git-prompt: do not look for refs/stash in $GIT_DIR
| * | | git-prompt: do not look for refs/stash in $GIT_DIRjk/prompt-stash-could-be-packedJeff King2014-08-251-1/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since dd0b72c (bash prompt: use bash builtins to check stash state, 2011-04-01), git-prompt checks whether we have a stash by looking for $GIT_DIR/refs/stash. Generally external programs should never do this, because they would miss packed-refs. That commit claims that packed-refs does not pack refs/stash, but that is not quite true. It does pack the ref, but due to a bug, fails to prune the ref. When we fix that bug, we would want to be doing the right thing here. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/more-push-completion'Junio C Hamano2014-07-301-1/+27
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * jk/more-push-completion: completion: complete `git push --force-with-lease=` completion: add some missing options to `git push` completion: complete "unstuck" `git push --recurse-submodules`
| * | | completion: complete `git push --force-with-lease=`jk/more-push-completionJohn Keeping2014-07-221-1/+21
| | | | | | | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | completion: add some missing options to `git push`John Keeping2014-07-221-0/+1
| | | | | | | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | completion: complete "unstuck" `git push --recurse-submodules`John Keeping2014-07-221-0/+5
| |/ / | | | | | | | | | | | | | | | | | | | | | Since the argument to `--recurse-submodules` is mandatory, it does not need to be stuck to the option with `=`. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'sp/complete-ext-alias'Junio C Hamano2014-06-251-0/+10
|\ \ \ | |/ / |/| | | | | | | | * sp/complete-ext-alias: completion: handle '!f() { ... }; f' and "!sh -c '...' -" aliases
| * | completion: handle '!f() { ... }; f' and "!sh -c '...' -" aliasessp/complete-ext-aliasSteffen Prohaska2014-06-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '!f() { ... }; f' and "!sh -c '....' -" are recommended patterns for declaring more complex aliases (see git wiki [1]). This commit teaches the completion to handle them. When determining which completion to use for an alias, an opening brace or single quote is now skipped, and the search for a git command is continued. For example, the aliases '!f() { git commit ... }' or "!sh -c 'git commit ...'" now trigger commit completion. Previously, the search stopped on the opening brace or quote, and the completion tried it to determine how to complete, which obviously was useless. The null command ':' is now skipped, so that it can be used as a workaround to declare the desired completion style. For example, the aliases !f() { : git commit ; if ... } f !sh -c ': git commit; if ...' - now trigger commit completion. Shell function declarations now work with or without space before the parens, i.e. '!f() ...' and '!f () ...' both work. [1] https://git.wiki.kernel.org/index.php/Aliases Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | completion: add missing options for git-mergejk/complete-merge-pullJohn Keeping2014-05-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The options added to __git_merge_options are those that git-pull passes to git-merge, since that variable is used by both commands. Those added directly in _git_merge() are specific to git-merge and are not passed thru from git-pull. Reported-by: Haralan Dobrev <hkdobrev@gmail.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | completion: add a note that merge options are sharedJohn Keeping2014-05-271-0/+1
|/ / | | | | | | | | | | | | | | This should avoid future confusion after a subsequent patch has added some options to __git_merge_options and some directly in _git_merge(). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'Junio C Hamano2014-05-191-17/+39
|\ \ | | | | | | | | | | | | * rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
| * | git-prompt.sh: don't assume the shell expands the value of PS1rh/prompt-pcmode-avoid-eval-on-refnameRichard Hansen2014-05-191-17/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 'fc/prompt-zsh-read-from-file'Junio C Hamano2014-05-131-8/+8
|\ \ \ | | | | | | | | | | | | | | | | * fc/prompt-zsh-read-from-file: contrib: completion: fix 'eread()' namespace
| * | | contrib: completion: fix 'eread()' namespacefc/prompt-zsh-read-from-fileFelipe Contreras2014-05-131-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise it might collide with a function of the same name in the user's environment. Suggested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'Junio C Hamano2014-05-021-2/+32
|\ \ \ \ | | |/ / | |/| | | | | | | | | | * rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't put unsanitized branch names in $PS1
| * | | git-prompt.sh: don't put unsanitized branch names in $PS1Richard Hansen2014-04-221-2/+32
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both bash and zsh subject the value of PS1 to parameter expansion, command substitution, and arithmetic expansion. Rather than include the raw, unescaped branch name in PS1 when running in two- or three-argument mode, construct PS1 to reference a variable that holds the branch name. Because the shells do not recursively expand, this avoids arbitrary code execution by specially-crafted branch names such as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'. Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'fc/complete-aliased-push'Junio C Hamano2014-04-182-0/+2
|\ \ \ | |_|/ |/| | | | | | | | * fc/complete-aliased-push: completion: fix completing args of aliased "push", "fetch", etc.
| * | completion: fix completing args of aliased "push", "fetch", etc.fc/complete-aliased-pushFelipe Contreras2014-04-092-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some commands need the first word to determine the actual action that is being executed, however, the command is wrong when we use an alias, for example 'alias.p=push', if we try to complete 'git p origin ', the result would be wrong because __git_complete_remote_or_refspec() doesn't know where it came from. So let's override words[1], so the alias 'p' is override by the actual command, 'push'. Reported-by: Aymeric Beaumet <aymeric.beaumet@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | prompt: fix missing file errors in zshFelipe Contreras2014-04-141-7/+14
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | zsh seems to have a bug while redirecting the stderr of the 'read' command: % read foo 2>/dev/null <foo zsh: no such file or directory: foo Which causes errors to be displayed when certain files are missing. Let's add a convenience function to manually check if the file is readable before calling "read". Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ss/completion-rec-sub-fetch-push'Junio C Hamano2014-03-141-1/+18
|\ \ | | | | | | | | | | | | * ss/completion-rec-sub-fetch-push: completion: teach --recurse-submodules to fetch, pull and push
| * | completion: teach --recurse-submodules to fetch, pull and pushss/completion-rec-sub-fetch-pushSup Yut Sum2014-02-111-1/+18
| | | | | | | | | | | | | | | Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/complete-merge-base'Junio C Hamano2014-01-271-1/+7
|\ \ \ | |/ / |/| | | | | | | | | | | * jk/complete-merge-base: completion: handle --[no-]fork-point options to git-rebase completion: complete merge-base options
| * | completion: handle --[no-]fork-point options to git-rebasejk/complete-merge-baseJohn Keeping2014-01-131-1/+1
| | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | completion: complete merge-base optionsJohn Keeping2014-01-131-0/+6
| | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'rr/completion-format-coverletter'Junio C Hamano2014-01-131-0/+1
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | The bash/zsh completion code did not know about format.coverLetter among many format.* configuration variables. * rr/completion-format-coverletter: completion: complete format.coverLetter
| * | completion: complete format.coverLetterrr/completion-format-coverletterRamkumar Ramachandra2014-01-071-0/+1
| | | | | | | | | | | | | | | Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | completion: fix remote.pushdefaultrr/completion-branch-configRamkumar Ramachandra2014-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When attempting to complete $ git config remote.push<TAB> 'pushdefault' doesn't come up. This is because "$cur" is matched with "remote.*" and a list of remotes are completed. Add 'pushdefault' as a candidate for completion too, using __gitcomp_nl_append (). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | completion: fix branch.autosetup(merge|rebase)Ramkumar Ramachandra2014-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When attempting to complete $ git config branch.auto<TAB> 'autosetupmerge' and 'autosetuprebase' don't come up. This is because "$cur" is matched with "branch.*" and a list of branches are completed. Add 'autosetupmerge', 'autosetuprebase' as candidates for completion too, using __gitcomp_nl_append (). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | completion: introduce __gitcomp_nl_append ()Ramkumar Ramachandra2014-01-062-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are situations where multiple classes of completions possible. For example branch.<TAB> should try to complete branch.master. branch.autosetupmerge branch.autosetuprebase The first candidate has the suffix ".", and the second/ third candidates have the suffix " ". To facilitate completions of this kind, create a variation of __gitcomp_nl () that appends to the existing list of completion candidates, COMPREPLY. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | zsh completion: find matching custom bash completionRamkumar Ramachandra2014-01-061-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | If zsh completion is being read from a location that is different from system-wide default, it is likely that the user is trying to use a custom version, perhaps closer to the bleeding edge, installed in her own directory. We will more likely to find the matching bash completion script in the same directory than in those system default places. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jn/scripts-updates'Junio C Hamano2013-12-122-4/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jn/scripts-updates: remove #!interpreter line from shell libraries test: replace shebangs with descriptions in shell libraries test: make FILEMODE a lazy prereq contrib: remove git-p4import mark contributed hooks executable mark perl test scripts executable mark Windows build scripts executable
| * | remove #!interpreter line from shell librariesjn/scripts-updatesJonathan Nieder2013-11-262-4/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a shell snippet meant to be sourced by other shell scripts, an opening #! line does more harm than good. The harm: - When the shell library is sourced, the interpreter and options from the #! line are not used. Specifying a particular shell can confuse the reader into thinking it is safe for the shell library to rely on idiosyncrasies of that shell. - Using #! instead of a plain comment drops a helpful visual clue that this is a shell library and not a self-contained script. - Tools such as lintian can use a #! line to tell when an installation script has failed by forgetting to set a script executable. This check does not work if shell libraries also start with a #! line. The good: - Text editors notice the #! line and use it for syntax highlighting if you try to edit the installed scripts (without ".sh" suffix) in place. The use of the #! for file type detection is not needed because Git's shell libraries are meant to be edited in source form (with ".sh" suffix). Replace the opening #! lines with comments. This involves tweaking the test harness's valgrind support to find shell libraries by looking for "# " in the first line instead of "#!" (see v1.7.6-rc3~7, 2011-06-17). Suggested by Russ Allbery through lintian. Thanks to Jeff King and Clemens Buchacher for further analysis. Tested by searching for non-executable scripts with #! line: find . -name .git -prune -o -type f -not -executable | while read file do read line <"$file" case $line in '#!'*) echo "$file" ;; esac done The only remaining scripts found are templates for shell scripts (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests (t/t4034/perl/{pre,post}). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | peek-remote: remove deprecated alias of ls-remoteJohn Keeping2013-11-121-1/+0
| | | | | | | | | | | | | | | | This has been deprecated since commit 87194d2 (Deprecate peek-remote, 2007-11-24), included in version 1.5.4. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | lost-found: remove deprecated commandJohn Keeping2013-11-121-1/+0
| | | | | | | | | | | | | | | | "git lost-found" has been deprecated since commit fc8b5f0 (Deprecate git-lost-found, 2007-11-08), included in version 1.5.4. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | tar-tree: remove deprecated commandJohn Keeping2013-11-121-1/+0
| | | | | | | | | | | | | | | | | | | | "git tar-tree" has been a thin wrapper around "git archive" since commit fd88d9c (Remove upload-tar and make git-tar-tree a thin wrapper to git-archive, 2006-09-24), which also made it print a message indicating that git-tar-tree is deprecated. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | repo-config: remove deprecated alias for "git config"John Keeping2013-11-121-1/+0
|/ | | | | | | | | The release notes for Git 1.5.4 say that "git repo-config" will be removed in the next feature release. Since Git 2.0 is nearly here, remove it. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sg/prompt-svn-remote-fix'Junio C Hamano2013-10-281-1/+1
|\ | | | | | | | | | | | | Bash portability fix. * sg/prompt-svn-remote-fix: bash prompt: don't use '+=' operator in show upstream code path
| * bash prompt: don't use '+=' operator in show upstream code pathsg/prompt-svn-remote-fixSZEDER Gábor2013-10-151-1/+1
| | | | | | | | | | | | | | | | The '+=' operator is not supported by old Bash versions (3.0) we still care about. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-prompt.sh: optionally show upstream branch namejc/prompt-upstreamJulien Carsique2013-10-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | When working with multiple remotes, it is common to switch the upstream from a remote to another. Doing so, the prompt may not be the expected one. Providing an option to display tracking information sounds useful. Add a "name" option to GIT_PS1_SHOWUPSTREAM which will show the upstream abbrev name. This option is ignored if "verbose" is false. Signed-off-by: Julien Carsique <julien.carsique@gmail.com> Improved-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>