Carried from remote-hg.
The problem reportedly happened after doing a push that fails, the abort
causes the state of remote-hg to go bad, this happens because
remote-hg's marks are not stored, but 'git fast-export' marks are.
Ensure that the marks are _always_ stored.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not needed since we use xrange ourselves.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
No functional changes. Typos, unused variables, redundant operations,
and white-spaces.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fc/remote-hg:
remote-hg: strip extra newline
remote-hg: use marks instead of inlined files
remote-hg: small performance improvement
remote-hg: allow refs with spaces
remote-hg: don't update bookmarks unnecessarily
remote-hg: add support for schemes extension
remote-hg: improve email sanitation
remote-hg: add custom local tag write code
remote-hg: write tags in the appropriate branch
remote-hg: custom method to write tags
remote-hg: add support for tag objects
remote-hg: add branch_tip() helper
remote-hg: properly mark branches up-to-date
remote-hg: use python urlparse
remote-hg: safer bookmark pushing
remote-helpers: avoid has_key
The shell syntax "export X=Y" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell syntax "export X=Y A=B" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not just randomly synchronize the revisions with no checks at
all.
I don't have any evidence that there's anything wrong with the
current code, which Bazaar seems to use, but for different purposes.
Let's use the logic Bazaar UI uses to avoid surprises.
Also, add a non-ff check.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a rebase stops (e.g. interrupted by a merge conflict), it could
be useful to know how far a rebase has progressed and how many
commits in total this rebase will apply. Teach the __git_ps1()
command to display the number of commits so far applied and the
total number of commits to be applied, like this:
((3ec0a6a...)|REBASE 2/5)
In the example above the rebase has stopped at the second commit due to
a merge conflict and there are a total number of five commits to be
applied by this rebase.
This information can be already obtained from the following files which are
being generated during the rebase:
GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh)
GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh)
GIT_DIR/.git/rebase-apply/next (git-am.sh)
GIT_DIR/.git/rebase-apply/last (git-am.sh)
but "rebase -i" does not leave necessary clues.
Implement this feature by doing these three things:
1) Modify git-rebase--interactive.sh to also create
GIT_DIR/.git/rebase-merge/msgnum
GIT_DIR/.git/rebase-merge/end
files for the number of commits so far applied and the total
number of commits to be applied.
2) Modify git-prompt.sh to read and display info from the above
files.
3) Update test t9903-bash-prompt.sh to reflect changes introduced
by this patch.
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove one of two consecutive, identical blocks for "git commit -c".
This was caused by a mechanical mismerge at d931e2fb25 (Merge
branch 'mp/complete-paths', 2013-02-08). The side branch wanted to
add this block at fea16b47 but the same fix was done independently
at 685397585 already.
Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no functional change since mercurial commit operation strips
that anyway, but that's no excuse for us not to do the right thing. So
let's be explicit about it.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So that we can find already exported ones. We can never be 100% sure
that we already exported such data, due to mercurial design, it at least
sometimes we should detect them, and so should give us some performance
boost.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Load previous manifest first as Mercurial does; for caching reasons.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So that we can use shortened URLs, for example 'bb:://felipec/repo'
(Bitbucket).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no point in calling the tag method for such simple action. Not
that we care much about the hg-git compat mode, it's mostly just for
comparison testing purposes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The one from mercurial is meant for users, on top of the latest tip.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Idea from gitifyhg, the backwards compatibility is how Mercurial used to
do it.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's simpler, and we don't need to depend on certain Mercurial versions.
Also, now we don't update the URL if 'file://' is not present.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is possible that the remote has changed the bookmarks, so let's fetch
them before we make any assumptions, just the way mercurial does.
Probably doesn't make a difference, but better be safe than sorry.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is deprecated.
[fc: do the same in remote-bzr]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We signal presense of untracked files by adding a per-cent sign '%'
to the prompt. But because '%' is used as an escape character to
introduce prompt customization in zsh (just like bash prompt uses
'\' to escape '\u', '\h', etc.), we need to say '%%' to get a
literal per-cent.
Helped-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In addition to a user visible change to offer more options to cherry-pick,
generally cleans up and simplifies the code.
* fc/completion:
completion: small optimization
completion: inline __gitcomp_1 to its sole callsite
completion: get rid of compgen
completion: add __gitcomp_nl tests
completion: add new __gitcompadd helper
completion: get rid of empty COMPREPLY assignments
completion: trivial test improvement
completion: add more cherry-pick options
git fast-import expects an extra newline after the commit message data,
but we are adding it only on hg-git compat mode, which is why the
bidirectionality tests pass.
We should add it unconditionally.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the current transport-helper code, refs without namespaced refspecs don't
work correctly, so let's always use them.
Some people reported issues with 'git clone --mirror', and this fixes them, as
well as possibly others.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
No need to calculate a new $c with a space if we are not going to do
anything it with it.
There should be no functional changes, except that a word "foo " with no
suffixes can't be matched. But $cur cannot have a space at the end
anyway. So it's safe.
Based on the code from SZEDER Gábor.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no point in calling a separate function that is only used
in one place. Especially considering that there's no need to call
compgen, and we traverse the words ourselves both in __gitcompadd,
and __gitcomp_1.
Let's squash the functions together, and traverse only once.
This improves performance. For N number of words:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.005s
new: 0.001s
== 100 ==
original: 0.009s
new: 0.006s
== 1000 ==
original: 0.027s
new: 0.019s
== 10000 ==
original: 0.163s
new: 0.151s
== 100000 ==
original: 1.555s
new: 1.497s
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The functionality we use from compgen is not much, we can do the same
manually, with drastic improvements in speed, especially when dealing
with only a few words.
This patch also has the sideffect that brekage reported by Jeroen Meijer
and SZEDER Gábor gets fixed because we no longer expand the resulting
words.
Here are some numbers filtering N amount of words:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.002s
new: 0.000s
== 100 ==
original: 0.003s
new: 0.002s
== 1000 ==
original: 0.012s
new: 0.011s
== 10000 ==
original: 0.056s
new: 0.066s
== 100000 ==
original: 2.669s
new: 0.622s
If the results are not narrowed:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.002s
new: 0.001s
== 100 ==
original: 0.004s
new: 0.004s
== 1000 ==
original: 0.020s
new: 0.015s
== 10000 ==
original: 0.101s
new: 0.355s
== 100000 ==
original: 2.850s
new: 31.941s
So, unless 'git checkout <tab>' usually gives you more than 10000
results, you'll get an improvement :)
Other possible solutions perform better after 1000 words, but worst if
less than that:
COMPREPLY=($(awk -v cur="$3" -v pre="$2" -v suf="$4"
'$0 ~ cur { print pre$0suf }' <<< "$1" ))
COMPREPLY=($(printf -- "$2%s$4\n" $1 | grep "^$2$3"))
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems (i.e. zsh) to override
__gitcompadd, and do something different instead.
Also, this allows further optimizations down the line.
There should be no functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the shell script more portable:
- Split export X=Y into 2 lines
- Use printf instead of echo -e
Use UTF-8 code points which are not decomposed by the filesystem:
Code points like "á" will be decomposed by Mac OS X.
bzr is unable to find the file "á" on disk.
Use code points from unicode which can not be decomposed.
In other words, the precompsed form use the same bytes as decomposed.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Correct common spelling mistakes in comments and tests
kwset: fix spelling in comments
precompose-utf8: fix spelling of "want" in error message
compat/nedmalloc: fix spelling in comments
compat/regex: fix spelling and grammar in comments
obstack: fix spelling of similar
contrib/subtree: fix spelling of accidentally
git-remote-mediawiki: spelling fixes
doc: various spelling fixes
fast-export: fix argument name in error messages
Documentation: distinguish between ref and offset deltas in pack-format
i18n: make the translation of -u advice in one go
Noticed with Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these were found using Lucas De Marchi's codespell tool.
Others were pointed out by Eric Sunshine.
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no functional reason for those, the only purpose they are
supposed to serve is to say "we don't provide any words here", but
even for that it's not used consistently.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The hg_log() test helper uses the "--graph" parameter that is
implemented by the GraphLog extension. If the extension is not activated
by the user, the parameter is not available. Activate the extension in
setup().
Also changes the way we grep the output in hg_log(). The pipe operator
can hide the return code of hg command. As a matter of fact, if log
fails because it doesn't know about "--graph", it doesn't report any
failure and let's you think everything worked.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mercurial allows absolute file paths, and Git doesn't like that.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The problem reportedly happened after doing a push that fails, the abort
causes the state of remote-hg to go bad, this happens because
remote-hg's marks are not stored, but 'git fast-export' marks are.
Ensure that the marks are _always_ stored.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If set to true acts as hg's clone/pull --insecure option.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cloning or pushing fails, we don't want to show a stack-trace.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ideally we shouldn't do this, as it's not recommended in mercurial
documentation, but there's no other way to push multiple bookmarks (on
the same branch), which would be the behavior most similar to git.
At the same time, add a configuration option for the people that don't
want to risk creating new remote heads.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mercurial emits messages like "searching for changes", "no changes
found", etc. meant for the use of its own UI layer, which break the pipe
between transport helper and remote helper.
Since there's no way to silence Mercurial, let's redirect to standard
error.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set the maximum number of splits to make when dividing the diff stat
lines based on space characters.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revision_history() is deprecated and doesn't do what we want (revno
instead of dotted_revno?).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous patches didn't deal with all the scenarios.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fc/remote-helpers-test-updates:
remote-hg: fix hg-git test-case
remote-bzr: remove stale check code for tests
remote-helpers: fix the run of all tests
remote-bzr: avoid echo -n
Using grep "devel\s\+3:" to find at least one whitspace is not
portable on all grep versions; not all grep versions understand "\s"
as a "whitespace".
Use a literal TAB followed by SPACE.
The + as a qualifier for "one or more" is not a basic regular
expression; use egrep instead of grep.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They have no content, there's nothing we can do with them.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently, that's the only way it's possible.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow re-add of a deleted file in the same commit.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git does not handle directories, renaming a directory is renaming every
files in this directory.
[fc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was some lingering code that shouldn't have been there in the
first place.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fastimport plugin was only required in the early stage of
development.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need to check for duplicate test numbers, we don't have them,
and either way test-lint-duplicates doesn't work in this situation.
Also, while we are on it, enable test-lint-shell-syntax to check for sh
errors.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's not portable, as reported by test-lint.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prompt string generator did not notice when we are in a middle
of a "git revert" session.
* rr/prompt-revert-head:
bash: teach __git_ps1 about REVERT_HEAD
* da/downcase-u-in-usage:
contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
contrib/examples/git-remote.perl: use a lowercase "usage:" string
tests: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
Documentation/user-manual.txt: use a lowercase "usage:" string
templates/hooks--update.sample: use a lowercase "usage:" string
contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
contrib/examples: use a lowercase "usage:" string
contrib/fast-import/import-zips.py: use spaces instead of tabs
contrib/fast-import/import-zips.py: fix broken error message
contrib/fast-import: use a lowercase "usage:" string
contrib/credential: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsexportcommit: use a lowercase "usage:" string
git-archimport: use a lowercase "usage:" string
git-merge-one-file: use a lowercase "usage:" string
git-relink: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
git-sh-setup: use a lowercase "usage:" string
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
* jl/submodule-deinit:
submodule: add 'deinit' command
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
* tz/credential-authinfo:
Add contrib/credentials/netrc with GPG support
* da/downcase-u-in-usage:
contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
contrib/examples/git-remote.perl: use a lowercase "usage:" string
tests: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
Documentation/user-manual.txt: use a lowercase "usage:" string
templates/hooks--update.sample: use a lowercase "usage:" string
contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
contrib/examples: use a lowercase "usage:" string
contrib/fast-import/import-zips.py: use spaces instead of tabs
contrib/fast-import/import-zips.py: fix broken error message
contrib/fast-import: use a lowercase "usage:" string
contrib/credential: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsexportcommit: use a lowercase "usage:" string
git-archimport: use a lowercase "usage:" string
git-merge-one-file: use a lowercase "usage:" string
git-relink: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
git-sh-setup: use a lowercase "usage:" string
A recent change added functions whose entire standard error stream
is redirected to /dev/null using a construct that is valid POSIX.1
but is not widely used:
funcname () {
cd "$1" && run some command "$2"
} 2>/dev/null
Even though this file is "git-completion.bash", zsh completion
support dot-sources it (instead of asking bash to grok it like tcsh
completion does), and zsh does not implement this redirection
correctly.
With zsh, trying to complete an inexistant directory gave this:
git add no-such-dir/__git_ls_files_helper💿2: no such file or directory: no-such-dir/
Also these functions use "cd" to first go somewhere else before
running a command, but the location the caller wants them to go that
is given as an argument to them should not be affected by CDPATH
variable the users may have set for their interactive session.
To fix both of these, wrap the body of the function in a subshell,
unset CDPATH at the beginning of the subshell, and redirect the
standard error stream of the subshell to /dev/null.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit fea16b47b6 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new git-completion.zsh script.
As a result, users of git-completion.zsh trying to complete "git add
fo<tab>" get an error:
git add fo__gitcomp_file:8: command not found: compgen
This patch adds the redefinition and removes the error.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).
Help those users by providing a 'deinit' command. This removes the
whole submodule.<name> section from .git/config (either for the given
submodule(s) or for all those which have been initialized if '.' is used)
together with their work tree. Fail if the current work tree contains
modifications (unless forced), but don't complain when either the work
tree is already removed or no settings are found in .git/config.
Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On WinXP, the windows credential helper doesn't work at all (due to missing
Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used
by wincred is incompatible with native Windows tools (such as the control
panel applet or 'cmdkey.exe /generic'). These Windows tools only set the
TargetName, UserName and CredentialBlob members of the CREDENTIAL
structure (where CredentialBlob is the UTF-16-encoded password).
Remove the unnecessary packing / unpacking of the password, along with the
related API definitions, for compatibility with Windows XP.
Don't use CREDENTIAL_ATTRIBUTEs to identify credentials for compatibility
with Windows credential manager tools. Parse the protocol, username, host
and path fields from the credential's target name instead.
Credentials created with an old wincred version will have mangled or empty
passwords after this change.
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
The windows credential helper currently only accepts LF on stdin, but bash
and cmd.exe both send CRLF. This prevents interactive use in the console.
Change the stdin parser to optionally accept CRLF.
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
This credential helper supports multiple files, returning the first one
that matches. It checks file permissions and owner. For *.gpg files,
it will run GPG to decrypt the file.
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the usage string consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the usage string consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Follow the conventional Python style by using 4-space indents
instead of hard tabs.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'sys' module is not imported but all of the bits
we want from it are. Adjust the script to not fail
when run on old Python versions and fix the inconsistent
use of tabs.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the usage string consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the usage string consistent with Git.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
* mp/diff-algo-config:
diff: Introduce --diff-algorithm command line option
config: Introduce diff.algorithm variable
git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Allows skipping the untracked check GIT_PS1_SHOWUNTRACKEDFILES
asks for the git-prompt (in contrib/) per repository.
* mw/bash-prompt-show-untracked-config:
t9903: add extra tests for bash.showDirtyState
t9903: add tests for bash.showUntrackedFiles
shell prompt: add bash.showUntrackedFiles option
contrib/subtree updates, but here are only the ones that looked
ready. The remainder of the patches will have another day.
* dg/subtree-fixes:
contrib/subtree: make the manual directory if needed
contrib/subtree: honor DESTDIR
contrib/subtree: fix synopsis
contrib/subtree: better error handling for 'subtree add'
contrib/subtree: use %B for split subject/body
contrib/subtree: remove test number comments
Add a config option 'bash.showUntrackedFiles' which allows enabling
the prompt showing untracked files on a per-repository basis. This is
useful for some repositories where the 'git ls-files ...' command may
take a long time.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This needs to be done in two places: __git_config_get_set_variables to
allow clever completion of "git config --local --get foo<tab>", and
_git_config to allow "git config --loc<tab>" to complete to --local.
While we're there, change the order of options in the code to match
git-config.txt.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "complete with known paths only" update to completion scripts
returns directory names without trailing slash to compensate the
addition of '/' done by bash that reads from our completion result.
tcsh completion code that reads from our internal completion result
does not add '/', so let it ask our complletion code to keep the '/'
at the end.
* mk/tcsh-complete-only-known-paths:
completion: handle path completion and colon for tcsh script
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
* mp/complete-paths:
git-completion.bash: add support for path completion
This makes the Makefile simpler, while providing more features, and more
consistency (the exact same rules with the exact same configuration as
Git official commands are applied with the new version).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* jc/do-not-let-random-file-interfere-with-completion-tests:
t9902: protect test from stray build artifacts
Before install git-subtree documentation, make sure the manpage
directory exists.
Signed-off-by: Jesper L. Nielsen <lyager@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git-subtree's Makefile to honor DESTDIR.
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix the documentation of add to show that a repository can be
specified along with a commit.
Suggested by Yann Dirson <dirson@bertin.fr>.
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check refspecs for validity before passing them on to other commands.
This lets us generate more helpful error messages.
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Delete the comments indicating test numbers as it causes maintenance
headaches. t*.sh -i will help us find any broken tests and these
numbers are not helping us anyway.
Signed-off-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prepare remote-helper test written in Python to be run with Python3.
* jk/remote-helpers-in-python-3:
git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
git-remote-testpy: fix path hashing on Python 3
git-remote-testpy: call print as a function
git-remote-testpy: don't do unbuffered text I/O
git-remote-testpy: hash bytes explicitly
svn-fe: allow svnrdump_sim.py to run with Python 3
git_remote_helpers: use 2to3 if building with Python 3
git_remote_helpers: force rebuild if python version changes
git_remote_helpers: fix input when running under Python 3
git_remote_helpers: allow building with Python 3
Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.
* bc/fix-array-syntax-for-3.0-in-completion-bash:
git-completion.bash: replace zsh notation that breaks bash 3.X
Recent enhancements to git-completion.bash provide intelligent path
completion for git commands. Such completions do not provide the
'/' at the end of directories for recent versions of bash; instead,
bash itself will add the trailing slash to directories to the result
provided by git-completion.bash. However, the completion for tcsh
uses the result of the bash completion script directly, so it either
needs to add the necessary slash itself, or needs to ask the bash
script to keep the trailing slash.
Adding the slash itself is difficult because we have to check the
each path in the output of the bash script to see if it is meant to
be a directory or something else. For example, assuming there is a
directory named 'commit' in the current directory, then, when
completing
git add commit<tab>
we would need to add a slash, but for
git help commit<tab>
we should not.
Figuring out such differences would require adding much intelligence
to the tcsh completion script. Instead, it is simpler to ask the
bash script to keep the trailing slash. This patch does this.
Also, tcsh does not handle the colon as a completion separator so we
remove it from the list of separators.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* jc/do-not-let-random-file-interfere-with-completion-tests:
t9902: protect test from stray build artifacts
Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* mk/complete-tcsh:
Prevent space after directories in tcsh completion
Fix use of an array notation that older versions of bash do not
understand.
* bc/fix-array-syntax-for-3.0-in-completion-bash:
git-completion.bash: replace zsh notation that breaks bash 3.X
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have random build artifacts in your build directory, left
behind by running "make" while on another branch, the "git help -a"
command run by __git_list_all_commands in the completion script that
is being tested does not have a way to know that they are not part
of the subcommands this build will ship. Such extra subcommands may
come from the user's $PATH. They will interfere with the tests that
expect a certain prefix to uniquely expand to a known completion.
Instrument the completion script and give it a way for us to tell
what (subset of) subcommands we are going to ship.
Also add a test to "git --help <prefix><TAB>" expansion. It needs
to show not just commands but some selected documentation pages.
Based on an idea by Jeff King.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new command "git check-ignore" for debugging .gitignore
files.
The variable names may want to get cleaned up but that can be done
in-tree.
* as/check-ignore:
clean.c, ls-files.c: respect encapsulation of exclude_list_groups
t0008: avoid brace expansion
add git-check-ignore sub-command
setup.c: document get_pathspec()
add.c: extract new die_if_path_beyond_symlink() for reuse
add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
pathspec.c: rename newly public functions for clarity
add.c: move pathspec matchers into new pathspec.c for reuse
add.c: remove unused argument from validate_pathspec()
dir.c: improve docs for match_pathspec() and match_pathspec_depth()
dir.c: provide clear_directory() for reclaiming dir_struct memory
dir.c: keep track of where patterns came from
dir.c: use a single struct exclude_list per source of excludes
Conflicts:
builtin/ls-files.c
dir.c
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x from loading the completion script and breaks test 9902. We can
easily work around this by using standard Bash array notation.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An internal ls-tree call made by completion code only to probe if
a path exists in the tree recorded in a commit object leaked error
messages when the path is not there. It is not an error at all and
should not be shown to the end user.
* ds/completion-silence-in-tree-path-probe:
git-completion.bash: silence "not a valid object" errors
Remove instructions for old vim support, which is better described
in the upstream vim documentation.
* jn/maint-trim-vim-contrib:
contrib/vim: simplify instructions for old vim support
Update tcsh command line completion so that an unwanted space is
not added to a single directory name.
* mk/complete-tcsh:
Prevent space after directories in tcsh completion
This conforms to RFC3834 and is useful in preventing eg
vacation auto-responders from replying by default
Signed-off-by: Chris Hiestand <chiestand@salk.edu>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since command line options have higher priority than config file
variables and taking previous commit into account, we need a way
how to specify myers algorithm on command line. However,
inventing `--myers` is not the right answer. We need far more
general option, and that is `--diff-algorithm`.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users or projects prefer different algorithms over others, e.g.
patience over myers or similar. However, specifying appropriate
argument every time diff is to be used is impractical. Moreover,
creating an alias doesn't play nicely with other tools based on diff
(git-show for instance). Hence, a configuration variable which is able
to set specific algorithm is needed. For now, these four values are
accepted: 'myers' (which has the same effect as not setting the config
variable at all), 'minimal', 'patience' and 'histogram'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, when changing and committing an executable file, the file
would loose its executable bit on the hg side. Likewise, symlinks ended
up as "normal" files". This was not immediately apparent on the git side
unless one did a fresh clone.
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
Suggested-by: Max Horn <max@quendi.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.
As an example:
git add <TAB>
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as follows:
* the path completion for the "git rm" and "git ls-files"
commands will suggest all cached files.
* the path completion for the "git add" command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the "git clean" command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the "git mv" command will suggest all cached
files when expanding the first argument, and all untracked and cached
files for subsequent arguments. In the latter case, empty directories
are included and ignored files are excluded.
* the path completion for the "git commit" command will suggest all
files that have been modified from the HEAD, if HEAD exists, otherwise
it will suggest all cached files.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
When using a recent Bash version, Git path completion will be the same
as builtin file completion, e.g.
git add contrib/
will suggest relative file names.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Trying to complete the command
git show master:./file
would cause a "Not a valid object name" error to be output on standard
error. Silence the error so it won't appear on the command line.
Signed-off-by: Dylan Smith <dylan.ah.smith@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rely on the upstream filetype.vim instead of duplicating its rules in
git's instructions for syntax highlighting support on pre-7.2 vim
versions.
The result is a shorter contrib/vim/README. More importantly, it lets
us punt on maintenance of the autocmd rules.
So now when we fix the upstream gitsendemail rule in light of commit
eed6ca7, new git users stuck on old vim reading contrib/vim/README can
automagically get the fix without any further changes needed to git.
Once the world has moved on to vim 7.2+ completely, we can get rid of
these instructions, but for now if they are this simple it's
effortless to keep them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New remote helper for bzr, with minimum fix squashed in.
* fc/remote-bzr:
remote-bzr: detect local repositories
remote-bzr: add support for older versions of bzr
remote-bzr: add support to push special modes
remote-bzr: add support for fecthing special modes
remote-bzr: add simple tests
remote-bzr: update working tree upon pushing
remote-bzr: add support for remote repositories
remote-bzr: add support for pushing
Add new remote-bzr transport helper
Some python scripts we ship cannot be run with older versions of the
interpreter.
* er/python-version-requirements:
Add checks to Python scripts for version dependencies.
If git-completion.bash returns a single directory as a completion,
tcsh will automatically add a space after it, which is not what the
user wants.
This commit prevents tcsh from doing this.
Also, a check is added to make sure the tcsh version used is recent
enough to allow completion to work as expected.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So we don't create a clone unnecessarily.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The optional third parameter when __git_ps1 is used in
PROMPT_COMMAND mode as format string for printf to further
customize the way the git status string is embedded in the
user's PS1 prompt.
Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update various entries in our .mailmap file.
* jk/mailmap-cleanup:
contrib: update stats/mailmap script
.mailmap: normalize emails for Linus Torvalds
.mailmap: normalize emails for Jeff King
.mailmap: fix broken entry for Martin Langhoff
.mailmap: match up some obvious names/emails
The "-c" and "-C" options take an existing commit, so let's
complete refs, just as we would for --squash or --fixup.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A 'git push' doesn't update the working directory on the remote, but
a 'bzr push' does. Teach the remote helper for bzr to update the
working tree on the bzr side upon pushing via the "export" command.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This version changes quite a few things:
1. The original parsed the mailmap file itself, and it did
it wrong (it did not understand entries with an extra
email key).
Instead, this version uses git's "%aE" and "%aN"
formats to have git perform the mapping, meaning we do
not have to read .mailmap at all, but still operate on
the current state that git sees (and it also works
properly from subdirs).
2. The original would find multiple names for an email,
but not the other way around.
This version can do either or both. If we find multiple
emails for a name, the resolution is less obvious than
the other way around. However, it can still be a
starting point for a human to investigate.
3. The original would order only by count, not by recency.
This version can do either. Combined with showing the
counts, it can be easier to decide how to resolve.
4. This version shows similar entries in a blank-delimited
stanza, which makes it more clear which options you are
picking from.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description of __git_ps1 function operating in two-arg mode was
not very clear. It said "set PROMPT_COMMAND=__git_ps1" which is not
the right usage for this mode, followed by "To customize the prompt,
do this", giving a false impression that those who do not want to
customize it can get away with no-arg form, which was incorrect.
Make it clear that this mode always takes two arguments, pre and
post, with an example.
The straight-forward one should be listed as the primary usage, and
the confusing one should be an alternate for advanced users. Swap
the order of these two.
Acked-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For bash completion, the option '-o bashdefault' is used to indicate
that when no other choices are available, file completion should be
performed. Since this option is not available in tcsh, no file
completion is ever performed. Therefore, commands like 'git add ',
'git send-email ', etc, require the user to manually type out
the file name. This can be quite annoying.
To improve the user experience we try to simulate file completion
directly in this script (although not perfectly).
The known issues with the file completion simulation are:
- Possible completions are shown with their directory prefix.
- Completions containing shell variables are not handled.
- Completions with ~ as the first character are not handled.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT_PS1_DESCRIBE_STYLE was introduced in v1.6.3.2~35. Document it in the
header comments.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New remote helper for hg.
* fc/remote-hg: (22 commits)
remote-hg: fix for older versions of python
remote-hg: fix for files with spaces
remote-hg: avoid bad refs
remote-hg: try the 'tip' if no checkout present
remote-hg: fix compatibility with older versions of hg
remote-hg: add missing config for basic tests
remote-hg: the author email can be null
remote-hg: add option to not track branches
remote-hg: add extra author test
remote-hg: add tests to compare with hg-git
remote-hg: add bidirectional tests
test-lib: avoid full path to store test results
remote-hg: add basic tests
remote-hg: fake bookmark when there's none
remote-hg: add compat for hg-git author fixes
remote-hg: add support for hg-git compat mode
remote-hg: match hg merge behavior
remote-hg: make sure the encoding is correct
remote-hg: add support to push URLs
remote-hg: add support for remote pushing
...
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream, as well as \
character. While we're there, also escape newlines, but I don't think we
can get them from MediaWiki pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise the user might get something like:
git-completion.sh:2466: command not found: compdef
If this script is loaded before compinit. The script would work either
way, but let's not be more annoying to the user.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Strictly speaking bzr doesn't need any changes to interact with remote
repositories, but it's dead slow.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As Amit Bakshi reported, older versions of python (< 2.7) don't have
subprocess.check_output, so let's use subprocess.Popen directly as
suggested.
Suggested-by: Amit Bakshi <ambakshi@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
git, the command fails with
| ... is not a git working tree
This is caused by creating submodules with '--separate-git-dir' but
still checking for a working tree by testing for a '.git' directory.
The patch fixes this by relaxing the existing detection a little bit.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Acked-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example, if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the user will be
given the choices:
maint
master
However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid. Furthermore, when
performing completion on 'git checkout mai', no choices will be
suggested. So, the user is first told that the branch name
'maint' is valid, but when trying to complete 'mai' into 'maint',
that completion is no longer valid.
The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.
The reason for this bug is that the uniq program only
works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same. Therefore
'maint' will be wrongly suggested as a valid option.
When dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.
A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
* so/prompt-command:
coloured git-prompt: paint detached HEAD marker in red
Fix up colored git-prompt
show color hints based on state of the git tree
Allow __git_ps1 to be used in PROMPT_COMMAND
Zsh's bash completion emulation is buggy, not properly maintained, and
we have some workarounds in place for different bugs that appeared in
various versions.
Since I'm the only one that has worked on that code lately[1], it might make
snese to use the code I wrote specifically for git.
The advantages are:
1) Less workarounds
* No need to hack __get_comp_words_by_ref
* No need to hack IFS or words
2) Improved features
* 'git show master' now properly adds a space at the end (IFS bug)
* 'git checkout --conflict=' now properly returns the sub-items
(missing feature)
3) Consolidated code
* It's all now in a single chunk, and it's basically the same as
git-completion.zsh
Since there's some interest in moving the zsh-specific code out of this
script, lets go ahead and warn the users that they should be using
git-completion.zsh.
[1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/bashcompinit
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems there's always issues with zsh's bash completion emulation.
I've tried to fix as many as I could[1], and most of the fixes are already
in the latest version of zsh, but still, there are issues.
There is no point going through all that pain; the emulation is easy to
achieve, and this patch works better than zsh's bash completion
emulation.
[1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=23907bb840c80eef99eabba17e086e44c9b2d3fc
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The list of all git commands is computed from the output of 'git help
-a', which already includes 'help', so there is no need to explicitly
add it once more when computing the list of porcelain commands.
Note that 'help' wasn't actually offered twice because of this,
because Bash filters duplicates from possible completion words.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Turns out fast-export throws bad 'reset' commands because of a behavior
in transport-helper that is not even needed.
Either way, better to ignore them, otherwise the user will get warnings
when we OK them.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
There's no concept of HEAD in mercurial, but let's try our best to do
something sensible.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Turns out repo.revs was introduced quite late, and it doesn't do
anything fancy for our refspec; only list all the numbers in that range.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
'hg commit' fails otherwise in some versions of mercurial because of
the missing user information. Other versions simply throw a warning and
guess though.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Some people prefer it this way.
% git config --global remote-hg.track-branches false
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
The base commands come from the tests of the hg-git project.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Base commands from hg-git tests:
https://bitbucket.org/durin42/hg-git/src
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
A GSoC project.
* fa/remote-svn:
Add a test script for remote-svn
remote-svn: add marks-file regeneration
Add a svnrdump-simulator replaying a dump file for testing
remote-svn: add incremental import
remote-svn: Activate import/export-marks for fast-import
Create a note for every imported commit containing svn metadata
vcs-svn: add fast_export_note to create notes
Allow reading svn dumps from files via file:// urls
remote-svn, vcs-svn: Enable fetching to private refs
When debug==1, start fast-import with "--stats" instead of "--quiet"
Add documentation for the 'bidi-import' capability of remote-helpers
Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
Add argv_array_detach and argv_array_free_detached
Add svndump_init_fd to allow reading dumps from arbitrary FDs
Add git-remote-testsvn to Makefile
Implement a remote helper for svn in C
Paint the marker for normal state in green and detached state
in red, instead of the other way around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The main point is to match the colors to be more close to the color
output of "git status -sb".
- the branchname is green, or in red when the HEAD is detached;
- the flags are either red or green for unstaged/staged and the
remaining flags get a different color or none at all.
Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.
Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.
Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour. It
requires the remote url to start with sim://.
Start and end revisions are evaluated. If the requested revision
doesn't exist, as it is the case with incremental imports, if no new
commit was added, it returns 1 (like svnrdump).
To allow using the same dump file for simulating multiple incremental
imports, the highest revision can be limited by setting the environment
variable SVNRMAX to that value. This simulates the situation where
higher revs don't exist yet.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Acked-by: David Michael Barr <b@rr-dav.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates with
a message on stderr an non-zero return value. This looks a little
weird, but there is no other way to know whether there is a new
revision in the svn repo.
On the start of an incremental import, the parent of the first commit
in the fast-import stream is set to the branch name to update. All
following commits specify their parent by a mark number. Previous mark
files are currently not reused.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Acked-by: David Michael Barr <b@rr-dav.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reference to update by the fast-import stream is hard-coded. When
fetching from a remote the remote-helper shall update refs in a
private namespace, i.e. a private subdir of refs/. This namespace is
defined by the 'refspec' capability, that the remote-helper advertises
as a reply to the 'capabilities' command.
Extend svndump and fast-export to allow passing the target ref.
Update svn-fe to be compatible.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Acked-by: David Michael Barr <b@rr-dav.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 25ae7cfd19.
That patch does fix expansion of weird variables in some
simple tests, but it also seems to break other things, like
expansion of refs by "git checkout".
While we're sorting out the correct solution, we are much
better with the original bug (people with metacharacters in
their completions occasionally see an error message) than
the current bug (ref completion does not work at all).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe what '=' means in the output of __git_ps1 when using
GIT_PS1_SHOWUPSTREAM, which was not previously described.
Signed-off-by: Jonathan "Duke" Leto <jonathan@leto.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As reported by Jeroen Meijer[1]; the current code doesn't deal properly
with items (tags, branches, etc.) that have ${} in them because they get
expaned by bash while using compgen.
A simple solution is to quote the items so they get expanded properly
(\$\{\}).
In order to achieve that I took bash-completion's quote() function,
which is rather simple, and renamed it to __git_quote() as per Jeff
King's suggestion.
Solves the original problem for me.
[1] http://article.gmane.org/gmane.comp.version-control.git/201596
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
t/perf: add "trash directory" to .gitignore
Add missing -z to git check-attr usage text for consistency with man page
git-jump: ignore (custom) prefix in diff mode
Documentation: indent-with-non-tab uses "equivalent tabs" not 8
completion: add --no-edit to git-commit
Matching the default file prefix b/ does not yield any results if config
option diff.noprefix or diff.mnemonicprefix is enabled.
Signed-off-by: Mischa POSLAWSKY <git@shiar.nl>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Finishing touches to the recently graduated topic to introduce
"git branch --set-upstream-to" option.
* cn/branch-set-upstream-to:
completion: complete branch name for "branch --set-upstream-to="
completion: add --set-upstream-to and --unset-upstream
