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
Optimise the "merge-base" computation a bit, and also update its
users that do not need the full merge-base information to call a
cheaper subset.
* jc/merge-bases:
reduce_heads(): reimplement on top of remove_redundant()
merge-base: "--is-ancestor A B"
get_merge_bases_many(): walk from many tips in parallel
in_merge_bases(): use paint_down_to_common()
merge_bases_many(): split out the logic to paint history
in_merge_bases(): omit unnecessary redundant common ancestor reduction
http-push: use in_merge_bases() for fast-forward check
receive-pack: use in_merge_bases() for fast-forward check
in_merge_bases(): support only one "other" commit
All remote subcommands are spelled out words except 'rm'. 'rm', being a
popular UNIX command name, may mislead users that there are also 'ls' or
'mv'. Use 'remove' to fit with the rest of subcommands.
'rm' is still supported and used in the test suite. It's just not
widely advertised.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In early days of its life, I planned to make it possible to compute
"is a commit contained in all of these other commits?" with this
function, but it turned out that no caller needed it.
Just make it take two commit objects and add a comment to say what
these two functions do.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git difftool --dir-diff" learned to use symbolic links to prepare
temporary copy of the working tree when available.
* da/difftool-updates:
difftool: silence warning
Add Code Compare v2.80.4 as a merge / diff tool for Windows
mergetool,difftool: Document --tool-help consistently
difftool: Disable --symlinks on cygwin
difftool: Handle compare() returning -1
difftool: Wrap long lines for readability
difftool: Check all return codes from compare()
difftool: Handle finding mergetools/ in a path with spaces
difftool: Use symlinks when diffing against the worktree
difftool: Call the temp directory "git-difftool"
difftool: Move option values into a hash
difftool: Eliminate global variables
difftool: Simplify print_tool_help()
* maint-1.7.11:
Prepare for 1.7.11.6
Make the ciabot scripts completely self-configuring in the normal case.
Improved documentation for the ciabot scripts.
man: git pull -r is a short for --rebase
gitcli: describe abbreviation of long options
rev-list docs: clarify --topo-order description
Documentation/CodingGuidelines: spell out more shell guidelines
Documentation: do not mention .git/refs/* directories
tests: Introduce test_seq
With this installed in your $PATH, you can store
git-over-http passwords in your keyring by doing:
git config credential.helper gnome-keyring
The code is based in large part on the work of John Szakmeister
who wrote the helper originally for the initial, unpublished
version of the credential helper protocol.
This version will pass t0303 if you do:
GIT_TEST_CREDENTIAL_HELPER=gnome-keyring \
./t0303-credential-external.sh
Signed-off-by: Philipp A. Hartmann <pah@qo.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These changes remove all need to modify the ciabot scripts for installation.
Instead, per-project configuration can be dome via variables in a [ciabot]
section of the config file.
Also, correct for the new server address.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the Windows port of Git expects binary pipes, we need to make
sure the helper-end also sets up binary pipes.
Side-step CRLF-issue in test to make it pass.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a
dash instead of a slash. This is required for Git for Windows because
slashes in command line arguments get mangled with according to these
rules:
http://www.mingw.org/wiki/Posix_path_conversion
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lm/git-blame-el:
git-blame.el: Do not use bare 0 to mean (point-min)
git-blame.el: Use with-current-buffer where appropriate
git-blame.el: Do not use goto-line in lisp code
My account on Github is now used as wiki and issue tracking. This will be
more flexible than in-tree management of a TODO-list.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can just feed our URL straight to git-credential and it
will parse it for us, saving us some code.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When writing a credential to git-credential, we omit fields
that do not have a true value. This will skip empty or
undefined fields (which we want), but will also accidentally
skip usernames or passwords which happen to have a non-true
value (e.g., "0"). Be more careful by checking for non-zero
length.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'.
However, it is also possible to call a page Foo:Bar if 'Foo' is not a
namespace. In this case, the actual name of the page is 'Foo:Bar', in the
main namespace. Since we can't tell with only the filename, query the
wiki for a namespace 'Foo' in these cases, but deal with the case where
no such namespace is found.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some wiki, including https://git.wiki.kernel.org/ have invalid revision
numbers (i.e. the actual revision numbers are non-contiguous). Don't die
when encountering one.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Initial phases of push and pull with git-remote-mediawiki can be long on
a large wiki. Let the user know what's going on.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When notes are created to record a push, it normally doesn't exist yet.
However, when a push is interrupted and then restarted, it may happen
that a commit already has notes attached, and we want to reflect the newly
created remote revision, hence use 'git notes add -f' to override the
existing one
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The algorithm to find a path from the local revision to the remote one
was calling "git rev-list" and parsing its output N times. Run rev-list
only once, and fill a hashtable with the result to optimize the body of
the loop.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is possible to use git-remote-mediawiki on a tree with both .mw files
and other files. Before git-remote-mediawiki learnt how to export
mediafiles, such mixed trees allowed the user to maintain both the wiki
and other files for the same project in the same repository. With the
newly added support for exporting mediafiles, pushing such mixed trees
would upload unrelated files as mediafiles, which may not be desired.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/mediawiki-tests:
git-remote-mediawiki: be more defensive when requests fail
git-remote-mediawiki: more efficient 'pull' in the best case
git-remote-mediawiki: extract revision-importing loop to a function
git-remote-mediawiki: refactor loop over revision ids
git-remote-mediawiki: change return type of get_mw_pages
git-remote-mediawiki (t9363): test 'File:' import and export
git-remote-mediawiki: support for uploading file in test environment
git-remote-mediawiki (t9362): test git-remote-mediawiki with UTF8 characters
git-remote-mediawiki (t9361): test git-remote-mediawiki pull and push
git-remote-mediawiki (t9360): test git-remote-mediawiki clone
git-remote-mediawiki: test environment of git-remote-mediawiki
git-remote-mediawiki: scripts to install, delete and clear a MediaWiki
"mediawiki" remote helper (in contrib/) learned to handle file
attachments.
* mm/mediawiki-file-attachments:
git-remote-mediawiki: improve support for non-English Wikis
git-remote-mediawiki: import "File:" attachments
git-remote-mediawiki: split get_mw_pages into smaller functions
git-remote-mediawiki: send "File:" attachments to a remote wiki
git-remote-mediawiki: don't "use encoding 'utf8';"
git-remote-mediawiki: don't compute the diff when getting commit message
Expose the credential API to scripted Porcelain writers.
* mm/credential-plumbing:
git-remote-mediawiki: update comments to reflect credential support
git-remote-mediawiki: add credential support
git credential fill: output the whole 'struct credential'
add 'git credential' plumbing command
The only way to fetch new revisions from a wiki before this patch was to
query each page for new revisions. This is good when tracking a small set
of pages on a large wiki, but very inefficient when tracking many pages
on a wiki with little activity.
Implement a new strategy that queries the wiki for its last global
revision, queries each new revision, and filter out pages that are not
tracked.
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without changing the behavior, we turn the foreach loop on an array of
revisions into a loop on an array of integer. It will be easier to
implement other strategies as they will only need to produce an array of
integer instead of a more complex data-structure.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous version was returning the list of pages to be fetched, but
we are going to need an efficient membership test (i.e. is the page
$title tracked), hence exposing a hash will be more convenient.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NGUYEN Kim Thuat <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: ROUCHER IGLESIAS Javier <roucherj@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will be used for testing git-remote-mediawiki's import feature on a
wiki containing media files.
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-ascii encoding create many particular cases when used in page
content, name, and edit/commit message. Test these cases.
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch provides a set of tests for the pull and push fonctionnality
of git-remote-mediawiki. The actual tests are kept in a separate function
to allow further tests to re-run the same set of commands with different
push and pull strategies.
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to test git-remote-mediawiki, a set of functions is needed to
manage a MediaWiki: edit a page, remove a page, fetch a page, fetch all
pages on a given wiki.
A few helper function are also provided to check the content of
directories.
In addition, this patch provides Makefiles to execute tests.
See the README file for more details.
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
install_wiki.sh allows the user to install a MediaWiki instance in a
single shell command. Like "git instaweb", it configures and launches
lighttpd without requiring root priviledges. To simplify database
management, it uses SQLite, which doesn't require a running daemon, and
allows reseting the database by simply replacing a single file. This
allows install_wiki to also defines a function wiki_reset which clear all
content of the previously created wiki, which will be very useful to run
several indepenant tests on the same wiki.
Note those functionnalities are made to be used from the user command
line in the directory git/contrib/mw-to-git/t/
Signed-off-by: Simon CATHEBRAS <Simon.Cathebras@ensimag.imag.fr>
Signed-off-by: Julien KHAYAT <Julien.Khayat@ensimag.imag.fr>
Signed-off-by: Simon Perrat <simon.perrat@ensimag.imag.fr>
Signed-off-by: Charles ROUSSEL <Charles.Roussel@ensimag.imag.fr>
Signed-off-by: Guillaume SASDY <Guillaume.Sasdy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mediafiles can live in namespaces with names different from Image
and File. While at it, rework the code to make it simpler and easier
to read.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split a rather heavy-ish "git completion" script out to create a
separate "git prompting" script, to help lazy-autoloading of the
completion part while making prompting part always available.
Add the symmetrical feature to the "File:" export support in the previous
patch. Download files from the wiki as needed, and feed them into the
fast-import stream. Import both the file itself, and the corresponding
description page.
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NGUYEN Kim Thuat <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: ROUCHER IGLESIAS Javier <roucherj@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current version of the git-remote-mediawiki supports only import and
export of plain wiki pages. This patch adds the functionality to export
file attachments (i.e. the content of the File: MediaWiki namespace),
which are also exposed by MediaWiki API.
This requires a recent version of MediaWiki::API (Version 0.37 works.
Version 0.34 doesn't).
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NGUYEN Kim Thuat <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: ROUCHER IGLESIAS Javier <roucherj@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The use of this statement is generally discouraged, and is too intrusive
for us: it forces the HTTP requests made by the API to contain only valid
UTF-8 characters. This would break the upload of binary files.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While we're there, simplify the code a bit: since log --format=%s anyway
shows the subject line as a single line, no need to split to take the
first line.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous version implemented the possibility to log in a wiki, but
the username and password had to be provided as configuration variables.
We add the possibility to use the Git credential system to prompt
the password.
The support if implemented with generic functions that mimic the C API,
designed to be usable from other contexts in the future (i.e. they may
migrate to Git.pm if someone is interested).
While we're there, do a bit of refactoring in mw_connect_maybe.
Based on patch by: Javier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
eLisp fixes for a contrib/ script.
* lm/git-blame-el:
git-blame.el: Do not use bare 0 to mean (point-min)
git-blame.el: Use with-current-buffer where appropriate
git-blame.el: Do not use goto-line in lisp code
The __gitdir() helper function finds out the path of the git
repository by running 'git rev-parse --git-dir'. However, it has a
shortcut first to avoid the overhead of running a git command in a
subshell when the current directory is at the top of the work tree,
i.e. when it contains a '.git' subdirectory.
If the 'GIT_DIR' environment variable is set then it specifies the
path to the git repository, and the autodetection of the '.git'
directory is not necessary. However, $GIT_DIR is only taken into
acocunt by 'git rev-parse --git-dir', and the check for the '.git'
subdirectory is performed first, so it wins over the path given in
$GIT_DIR.
There are several completion (helper) functions that depend on
__gitdir(), and when the above case triggers the completion script
will do weird things, like offering refs, aliases, or stashes from a
different repository, or displaying wrong or broken prompt, etc.
So check first whether $GIT_DIR is set, and only proceed with checking
the '.git' directory in the current directory if it isn't. 'git
rev-parse' would also check whether the path in $GIT_DIR is a proper
'.git' directory, i.e. 'HEAD', 'refs/', and 'objects/' are present and
accessible, but we don't have to be that thorough for the bash prompt.
And we've lived with an equally permissive check for '.git' in the
current working directory for years anyway.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-blame-filter and git-blame-create-overlay we want to save
(along with the values of point and mark) the current-buffer in scope
when calling the functions. The idiom
(save-excursion
(set-buffer buf)
...)
will correctly restore the correct buffer, but will not save the
values of point and mark in buf (only in the buffer current when the
save-excursion call is executed). The intention of these functions is
to save the current buffer from the calling scope and the values of
point and mark in the buffer they are modifying. The correct idiom
for this is
(with-current-buffer buf
(save-excursion
...))
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
goto-line is a user-level command, instead use the lisp-level
construct recommended in Emacs documentation.
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7f02f3d7 (completion: rename internal helpers _git and _gitk,
2012-05-19) renamed said functions to _main_git() and _main_gitk(),
respectively. By convention the name of our git-completion-specific
functions start with '_git' or '__git' prefix, so rename those
functions once again to put them back into our "namespace". Use the
two underscore prefix, because _git_main() could be mistaken for the
completion function of the (not yet existing) 'git main' command.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using mapcar here is a waste of memory because the mapped result
is not used.
Noticed by emacs ("Warning: `mapcar' called for effect").
[jn: split from a larger patch, with new description]
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The __gitdir function is duplicated between completion and prompt
scripts, and these definitions should not diverge; otherwise one of
them can be subtly broken depending on the order the user's shell
dot-sources them.
Leave a note to people who may want to touch one copy to make sure
they update the other one in sync. Hopefully this line would also
appear in the context of the patch to allow reviewers to notice a
patch that attempts to update only one of them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote helper that acts as a proxy and caches ssl session for the
https:// transport is added to the contrib/ area.
By Colby Ranger
* cr/persistent-https:
Add persistent-https to contrib
Git over HTTPS has a high request startup latency, since the SSL
negotiation can take up to a second. In order to reduce this latency,
connections should be left open to the Git server across requests
(or invocations of the git commandline).
Reduce SSL startup latency by running a daemon job that keeps
connections open to a Git server. The daemon job
(git-remote-persistent-https--proxy) is started on the first request
through the client binary (git-remote-persistent-https) and remains
running for 24 hours after the last request, or until a new daemon
binary is placed in the PATH. The client determines the daemon's
HTTP address by communicating over a UNIX socket with the daemon.
From there, the rest of the Git protocol work is delegated to the
"git-remote-http" binary, with the environment's http_proxy set to
the daemon.
Accessing /pub/scm/linux/kernel/git/torvalds/linux repository hosted
at kernel.googlesource.com with "git ls-remote" over https:// and
persistent-https:// 5 times shows that the first request takes about
the same time (0.193s vs 0.208s---there is a slight set-up cost for
the local proxy); as expected, the other four requests are much
faster (~0.18s vs ~0.08s).
Incidentally, this also has the benefit of HTTP keep-alive working
across Git command invocations. Its common for servers to use a 5
minute keep-alive on an HTTP 1.1 connection. Git-over-HTTP commonly
uses Transfer-Encoding: chunked on replies, so keep-alive will
generally just work, even though a pack stream's length isn't known
in advance. Because the helper is an external process holding that
connection open, we also benefit from being able to reuse an
existing TCP connection to the server. The same "git ls-remote"
test against http:// vs persistent-https:// URL shows that the
former takes ~0.09s while the first request for the latter is about
0.134s with set-up cost, and subsequent requests are ~0.065s,
shaving around one RTT to the server.
Signed-off-by: Colby Ranger <cranger@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default compiler and cflags were mostly "works for me"
when I built the original version. We need to be much less
careful here than usual, because we know we are building
only on OS X. But it's only polite to at least respect the
CFLAGS and CC definitions that the user may have provided
earlier.
While we're at it, let's update our definitions and rules to
be more like the top-level Makefile; default our CFLAGS to
include -O2, and make sure we use CFLAGS and LDFLAGS when
linking.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash-completion 1.90 shipped with support to load completions
dynamically[1], which means the git completion script wouldn't be loaded
until the user types 'git <tab>'--this creates a problem to people using
__git_ps1(); that function won't be available when the shell is first
created.
For now distributions have workarounded this issue by moving the git
completion to the "compatdir"[2]; this of course is not ideal.
The solution, proposed by Kerrick Staley[3], is to split the git script
in two; the part that deals with __git_ps1() in one (i.e.
git-prompt.sh), and everything else in another (i.e.
git-completion.bash).
Another benefit of this is that zsh user that are not interested in the
bash completion can use it for their prompts, which has been tried
before[4].
The only slight issue is that __gitdir() would be duplicated, but this
is probably not a big deal.
So let's go ahead and move __git_ps1() to a new file.
While at this, I took the liberty to reformat the help text in the new
file.
[1] http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=99c4f7f25f50a7cb2fce86055bddfe389effa559
[2] http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/git&id=974380fabb8f9f412990b17063bf578d98c44a82
[3] http://mid.gmane.org/CANaWP3w9KDu57aHquRRYt8td_haSWTBKs7zUHy-xu0B61gmr9A@mail.gmail.com
[4] http://mid.gmane.org/1303824288-15591-1-git-send-email-mstormo@gmail.com
Cc: Kerrick Staley <mail@kerrickstaley.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Ville Skyttä <ville.skytta@iki.fi>
Cc: Dan McGee <dan@archlinux.org>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
No reason to have it executable. Every way this script is intended to be
used includes the 'source' command.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some people might be relying on _git and _gitk to define custom aliases,
unfortunately, commit 6b179ad (completion: add new __git_complete
helper) broke that support.
"bash: [: 1: unary operator expected"
This can be easily fixed by using __git_complete, but it's not meant to
be public.
Although _git and _gitk are probably not meant to be public, it's easy
to keep having support for them by having a wrapper to the proper
new function that is fully functional.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Would be useful to provide backwards compatibility for _git. Also, zsh
completion uses _git, and it cannot be changed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the completions, and would make it easier to define
aliases in the future.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use new __gitcomp_nl; this is the last place that uses COMPREPLY and
compgen directly outside __gitcomp* functions.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many error/warning messages had extra trailing newlines that are
unnecessary.
By Pete Wyckoff
* pw/message-cleanup:
remove blank filename in error message
remove superfluous newlines in error messages
A script written long time ago proved to be useful this week for me ;-)
with a minor tweak.
* jc/rerere-train:
contrib/rerere-train: use installed git-sh-setup
The error handling routines add a newline. Remove
the duplicate ones in error messages.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of sourcing git-sh-setup from random place that is on the $PATH,
explicitly source $(git --exec-path)/git-sh-setup. As I do not personally
have any libexec/git-core directory on my $PATH like many other people, the
script will fail without this update.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Felipe Contreras (4) and others
* fc/completion-tests:
completion: fix completion after 'git --option <TAB>'
completion: avoid trailing space for --exec-path
completion: add missing general options
completion: simplify by using $prev
completion: simplify __gitcomp_1
tests: add tests for the __gitcomp() completion helper function
tests: add initial bash completion tests
The bash completion doesn't work when certain options to git itself are
specified, e.g. 'git --no-pager <TAB>' errors out with
error: invalid key: alias.--no-pager
The main _git() completion function finds out the git command name by
looping through all the words on the command line and searching for
the first word that is not a known option for the git command.
Unfortunately the list of known git options was not updated in a long
time, and newer options are not skipped but mistaken for a git command.
Such a misrecognized "command" is then passed to __git_aliased_command(),
which in turn passes it to a 'git config' query, hence the error.
Currently the following options are misrecognized for a git command:
-c --no-pager --exec-path --html-path --man-path --info-path
--no-replace-objects --work-tree= --namespace=
To fix this we could just update the list of options to be skipped,
but the same issue will likely arise, if the git command learns a new
option in the future. Therefore, to make it more future proof against
new options, this patch changes that loop to skip all option-looking
words, i.e. words starting with a dash.
We also have to handle the '-c' option specially, because it takes a
configutation parameter in a separate word, which must be skipped,
too.
[fc: added tests]
Signed-off-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>
"--exec-path" looks to the completion script like an unambiguous
successful completion, but it is wrong to emit a SP after it as if
declaring that we are done with completion; the user could be trying
to do
git --exec-path; # print name of helper directory
or
git --exec-path=/path/to/alternative/helper/dir <subcommand>
so the most helpful thing to do is to leave out the trailing space and
leave it to the operator to type an equal sign or carriage return
according to the situation.
[fc: added tests]
Cc: Andreas Schwab <schwab@linux-m68k.org>
Reported-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a Makefile to run subtree tests. This is largely copied
from the standard test suite with irrelevant targets removed
and some paths altered to account for where subtree tests live.
Signed-off-by: David A. Greene <greened@obbligato.org>
Build git-subtree in its contrib directory and install from there.
The main Makefile no longer discovers subcommands build in the main
build area so we cannot count on it to install git-subtree. The user
should make && make install in contrib/subtree to install git-subtree.
Change the rule to install the git-subtree manpage. The main
Documentation area doesn't directly support installing documentation
from other directories so the user will have to do that from within
contrib/subtree for now.
Signed-off-by: David A. Greene <greened@obbligato.org>
Include config.make.autogen in the git-subtree contrib area to pick up
settings for prefix and other such things.
Signed-off-by: David A. Greene <greened@obbligato.org>
Remove various files that simply duplicate functionality already
provided by the main project files.
Signed-off-by: David A. Greene <greened@obbligato.org>
Set TEST_DIRECTORY to the main git test area. This allows the
git-subtree out-of-tree tests to run correctly.
Signed-off-by: David A. Greene <greened@obbligato.org>
Move git-p4 out of contrib/fast-import into the main code base,
aside other foreign SCM tools.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Certain versions of zsh seems to treat
local var=()
as a function declaration, rather than an assignment of an empty array,
although its documentation does not suggest that this should be the case.
With zsh 4.3.15 on Fedora Core 15, this causes
__git_ps1 " (%s)"
to trigger an error message:
local:2: command not found: svn_url_pattern
when GIT_PS1_SHOWUPSTREAM="auto".
Signed-off-by: Alex Merry <dev@randomguy3.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* th/git-diffall:
contrib/diffall: fix cleanup trap on Windows
contrib/diffall: eliminate duplicate while loops
contrib/diffall: eliminate use of tar
contrib/diffall: create tmp dirs without mktemp
contrib/diffall: comment actual reason for 'cdup'
Prior to this commit, the cleanup trap that removes the tmp dir
created by the script would fail on Windows. The error was silently
ignored by the script.
On Windows, a directory cannot be removed while it is the working
directory of the process (thanks to Johannes Sixt on the Git list
for this info [1]).
This commit eliminates the 'cd' into the tmp directory that caused
the error.
[1]: http://article.gmane.org/gmane.comp.version-control.git/193086
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were 3 instances of a 'while read; do' that used identical logic
to populate '/tmp/right_dir'. This commit groups them into a single loop.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'tar' utility is not available on all platforms (some only support
'gnutar'). An earlier commit created a work-around for this problem,
but a better solution is to eliminate the use of 'tar' completely.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mktemp is not available on all platforms. Instead of littering the code
with a work-around, this commit replaces mktemp with a one-line Perl
script.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment from an earlier commit did not reflect the actual reason this
operation is needed.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1)
* zj/diff-stat-dyncol:
: This breaks tests. Perhaps it is not worth using the decimal-width stuff
: for this series, at least initially.
diff --stat: add config option to limit graph width
diff --stat: enable limiting of the graph part
diff --stat: add a test for output with COLUMNS=40
diff --stat: use a maximum of 5/8 for the filename part
merge --stat: use the full terminal width
log --stat: use the full terminal width
show --stat: use the full terminal width
diff --stat: use the full terminal width
diff --stat: tests for long filenames and big change counts
Config option diff.statGraphWidth=<width> is equivalent to
--stat-graph-width=<width>, except that the config option is ignored
by format-patch.
For the graph-width limiting to be usable, it should happen
'automatically' once configured, hence the config option.
Nevertheless, graph width limiting only makes sense when used on a
wide terminal, so it should not influence the output of format-patch,
which adheres to the 80-column standard.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.9.3
CodingGuidelines: do not use 'which' in shell scripts
CodingGuidelines: Add a note about spaces after redirection
post-receive-email: match up $LOGBEGIN..$LOGEND pairs correctly
post-receive-email: remove unused variable
The 'git difftool' allows the user to view diffs using an external tool.
It runs a separate instance of the tool for each file in the diff. This
makes it tedious to review changes spanning multiple files.
The 'git-diffall' script instead prepares temporary directories with the
files to be compared and launches a single instance of the external diff
tool to view them (i.e. a directory diff).
The 'diff.tool' or 'merge.tool' configuration variable is used to specify
which external tool is used.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
prep_for_email neither is passed a fourth argument nor uses it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Document accumulated fixes since 1.7.9.2
Git 1.7.8.5
grep -P: Fix matching ^ and $
am: don't infloop for an empty input file
rebase -m: only call "notes copy" when rewritten exists and is non-empty
git-p4: remove bash-ism in t9800
git-p4: remove bash-ism in t9809
git-p4: fix submit regression with clientSpec and subdir clone
git-p4: set useClientSpec variable on initial clone
Makefile: add thread-utils.h to LIB_H
Conflicts:
RelNotes
t/t9809-git-p4-client-view.sh
When the --use-client-spec is given to clone, and the clone
path is a subset of the full tree as specified in the client,
future submits will go to the wrong place.
Factor out getClientSpec() so both clone/sync and submit can
use it. Introduce getClientRoot() that is needed for the client
spec case, and use it instead of p4Where().
Test the five possible submit behaviors (add, modify, rename,
copy, delete).
Reported-by: Laurent Charrière <lcharriere@promptu.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --use-client-spec was given, set the matching configuration
variable. This is necessary to ensure that future submits
work properly.
The alternatives of requiring the user to set it, or providing
a command-line option on every submit, are error prone.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ld/git-p4-expanded-keywords:
: Teach git-p4 to unexpand $RCS$-like keywords that are embedded in
: tracked contents in order to reduce unnecessary merge conflicts.
git-p4: add initial support for RCS keywords
RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.
This change means that when git-p4 detects a problem applying
a patch, it will check to see if keyword expansion could be
the culprit. If it is, it strips the keywords in the p4
repository so that they match what git is expecting. It then
has another go at applying the patch.
This behaviour is enabled with a new git-p4 configuration
option and is off by default.
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The style used for incrementing and decrementing variables was fairly
inconsistenty and was normalized to use x++, or ((x++)) in contexts
where the former would otherwise be interpreted as a command. This is a
bash-ism, but for obvious reasons this script is already bash-specific.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Complete <name> only for set-url. For set-branches and
set-head, complete <name> and <branch> over the network,
like e.g. git pull already does.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidlines confidently declares "We use tabs for indentation."
It would be a shame if it were caught lying.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was out-of-sync with the reality of who works on this
script. Defer (silently) to Documentation/SubmittingPatches
like all other code.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was broken since the feature was introduced initially at abcaf07 (If
the user has configured various parameters, use them., 2008-08-10).
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://bogomips.org/git-svn:
git-svn.perl: fix a false-positive in the "already exists" test
git-svn.perl: perform deletions before anything else
git-svn: Fix time zone in --localtime
git-svn: un-break "git svn rebase" when log.abbrevCommit=true
git-svn: remove redundant porcelain option to rev-list
completion: add --interactive option to git svn dcommit
* jk/diff-highlight:
diff-highlight: document some non-optimal cases
diff-highlight: match multi-line hunks
diff-highlight: refactor to prepare for multi-line hunks
diff-highlight: don't highlight whole lines
diff-highlight: make perl strict and warnings fatal
* fc/zsh-completion:
completion: simplify __gitcomp and __gitcomp_nl implementations
completion: use ls -1 instead of rolling a loop to do that ourselves
completion: work around zsh option propagation bug
see afd7f1e for more details on git svn dcommit --interactive
Signed-off-by: Frederic Heitzmann <frederic.heitzmann@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
If the argument for `__git_ps1` begins with a dash, `printf` tries to
interpret it as an option which results in an error message.
The problem is solved by adding '--' before the argument to tell
`printf` to not interpret the following argument as an option.
Adding '--' directly to the argument does not help because the argument
is enclosed by double quotes.
Signed-off-by: Christian Hammerl <info@christian-hammerl.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff-highlight script works on heuristics, so it can be
wrong. Let's document some of the wrong-ness in case
somebody feels like working on it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we only bother highlighting single-line hunks. The
rationale was that the purpose of highlighting is to point
out small changes between two similar lines that are
otherwise hard to see. However, that meant we missed similar
cases where two lines were changed together, like:
-foo(buf);
-bar(buf);
+foo(obj->buf);
+bar(obj->buf);
Each of those changes is simple, and would benefit from
highlighting (the "obj->" parts in this case).
This patch considers whole hunks at a time. For now, we
consider only the case where the hunk has the same number of
removed and added lines, and assume that the lines from each
segment correspond one-to-one. While this is just a
heuristic, in practice it seems to generate sensible
results (especially because we now omit highlighting on
completely-changed lines, so when our heuristic is wrong, we
tend to avoid highlighting at all).
Based on an original idea and implementation by Michał
Kiedrowicz.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code structure assumes that we will only look at
a pair of lines at any given time, and that the end result
should always be to output that pair. However, we want to
eventually handle multi-line hunks, which will involve
collating pairs of removed/added lines. Let's refactor the
code to return highlighted pairs instead of printing them.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a change like:
-foo
+bar
we end up highlighting the entirety of both lines (since the
whole thing is changed). But the point of diff highlighting
is to pinpoint the specific change in a pair of lines that
are mostly identical. In this case, the highlighting is just
noise, since there is nothing to pinpoint, and we are better
off doing nothing.
The implementation looks for "interesting" pairs by checking
to see whether they actually have a matching prefix or
suffix that does not simply consist of colorization and
whitespace. However, the implementation makes it easy to
plug in other heuristics, too, like:
1. Depending on the source material, the set of "boring"
characters could be tweaked to include language-specific
stuff (like braces or semicolons for C).
2. Instead of saying "an interesting line has at least one
character of prefix or suffix", we could require that
less than N percent of the line be highlighted.
The simple "ignore whitespace, and highlight if there are
any matched characters" implemented by this patch seems to
give good results on git.git. I'll leave experimentation
with other heuristics to somebody who has a dataset that
does not look good with the current code.
Based on an original idea and implementation by Michał
Kiedrowicz.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These perl features can catch bugs, and we shouldn't be
violating any of the strict rules or creating any warnings,
so let's turn them on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fc/zsh-completion:
completion: simplify __gitcomp and __gitcomp_nl implementations
completion: use ls -1 instead of rolling a loop to do that ourselves
completion: work around zsh option propagation bug
* jn/svn-fe: (36 commits)
vcs-svn: suppress a -Wtype-limits warning
vcs-svn: allow import of > 4GiB files
vcs-svn: rename check_overflow arguments for clarity
vcs-svn/svndiff.c: squelch false "unused" warning from gcc
vcs-svn: reset first_commit_done in fast_export_init
vcs-svn: do not initialize report_buffer twice
vcs-svn: avoid hangs from corrupt deltas
vcs-svn: guard against overflow when computing preimage length
vcs-svn: cap number of bytes read from sliding view
test-svn-fe: split off "test-svn-fe -d" into a separate function
vcs-svn: implement text-delta handling
vcs-svn: let deltas use data from preimage
vcs-svn: let deltas use data from postimage
vcs-svn: verify that deltas consume all inline data
vcs-svn: implement copyfrom_data delta instruction
vcs-svn: read instructions from deltas
vcs-svn: read inline data from deltas
vcs-svn: read the preimage when applying deltas
vcs-svn: parse svndiff0 window header
vcs-svn: skeleton of an svn delta parser
...
These shell functions are written in an unnecessarily verbose way;
simplify their "conditionally use $<number> after checking $# against
<number>" logic by using shell's built-in conditional substitution
facilities.
Also remove the first of the two assignments to IFS in __gitcomp_nl
that does not have any effect.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the code a great deal. In particular, it allows us to
get rid of __git_shopt, which is used only in this fuction to enable
'nullglob' in zsh.
[jn: squashed with a patch that actually gets rid of __git_shopt]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When listing commands in zsh (git <TAB><TAB>), all of them will show up,
instead of only porcelain ones.
The root cause of this is because zsh versions from 4.3.0 to present
(4.3.15) do not correctly propagate the SH_WORD_SPLIT option into the
subshell in ${foo:=$(bar)} expressions. Because of this bug, the list of
all commands was treated as a single word in __git_list_porcelain_commands
and did not match any of the patterns that would usually cause plumbing to
be excluded.
With problematic versions of zsh, after running
emulate sh
fn () {
var='one two'
for v in $var; do echo $v; done
}
x=$(fn)
: ${y=$(fn)}
printing "$x" results in two lines as expected, but printing "$y" results
in a single line because $var is expanded as a single word when evaluating
fn to compute y.
So avoid the construct, and use an explicit 'test -n "$foo" || foo=$(bar)'
instead.
[jn: clarified commit message, indentation style fix]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* va/git-p4-branch:
t9801: do not overuse test_must_fail
git-p4: Change p4 command invocation
git-p4: Add test case for complex branch import
git-p4: Search for parent commit on branch creation
* ld/git-p4-branches-and-labels:
git-p4: label import fails with multiple labels at the same changelist
git-p4: add test for p4 labels
git-p4: importing labels should cope with missing owner
git-p4: cope with labels with empty descriptions
git-p4: handle p4 branches and labels containing shell chars
* pw/p4-view-updates:
git-p4: add tests demonstrating spec overlay ambiguities
git-p4: adjust test to adhere to stricter useClientSpec
git-p4: clarify comment
git-p4: fix verbose comment typo
git-p4: only a single ... wildcard is supported
This simplifies svn-fe a great deal and fulfills a longstanding wish:
support for dumps with deltas in them, and incremental imports.
The cost is that commandline usage of the svn-fe tool becomes a little
more complicated since it no longer keeps state itself but instead reads
blobs back from fast-import in order to copy them between revisions and
apply deltas to them.
Also removes a couple of custom data structures and replaces them with
strbufs like other parts of Git.
* 'svn-fe' of git://repo.or.cz/git/jrn: (32 commits)
vcs-svn: reset first_commit_done in fast_export_init
vcs-svn: do not initialize report_buffer twice
vcs-svn: avoid hangs from corrupt deltas
vcs-svn: guard against overflow when computing preimage length
vcs-svn: cap number of bytes read from sliding view
test-svn-fe: split off "test-svn-fe -d" into a separate function
vcs-svn: implement text-delta handling
vcs-svn: let deltas use data from preimage
vcs-svn: let deltas use data from postimage
vcs-svn: verify that deltas consume all inline data
vcs-svn: implement copyfrom_data delta instruction
vcs-svn: read instructions from deltas
vcs-svn: read inline data from deltas
vcs-svn: read the preimage when applying deltas
vcs-svn: parse svndiff0 window header
vcs-svn: skeleton of an svn delta parser
vcs-svn: make buffer_read_binary API more convenient
vcs-svn: learn to maintain a sliding view of a file
Makefile: list one vcs-svn/xdiff object or header per line
vcs-svn: avoid using ls command twice
...
Conflicts:
Makefile
contrib/svn-fe/svn-fe.txt
zsh adds a backslash (foo\ ) for each item in the COMPREPLY array if IFS
doesn't contain spaces. This issue has been reported[1], but there is no
solution yet.
This wasn't a problem due to another bug[2], which was fixed in zsh
version 4.3.12. After this change, 'git checkout ma<tab>' would resolve
to 'git checkout master\ '.
Aditionally, the introduction of __gitcomp_nl in commit a31e626
(completion: optimize refs completion) in git also made the problem
apparent, as Matthieu Moy reported.
The simplest and most generic solution is to hide all the changes we do
to IFS, so that "foo \nbar " is recognized by zsh as "foo bar". This
works on versions of git before and after the introduction of
__gitcomp_nl (a31e626), and versions of zsh before and after 4.3.12.
Once zsh is fixed, we should conditionally disable this workaround to
have the same benefits as bash users.
[1] http://www.zsh.org/mla/workers/2012/msg00053.html
[2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=2e25dfb8fd38dbef0a306282ffab1d343ce3ad8d
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change p4 command invocation to avoid going through the shell. This
allows names with spaces and wildcards to work.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To find out which is its parent the commit of the new branch is compared
sequentially to each blob of the parent branch from the newest to the
oldest. The first blob which results in a zero diff is considered the
parent commit. If none is found, then the commit is applied to the top
of the parent branch.
A fast-import "checkpoint" call is required because diff-tree is only
able to work with blobs on disk. But most of these commits will not be
part of the final imported tree, making fast-import fail. To avoid this,
the temporary branches are tracked and then removed at the end of the
import process.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
Signed-off-by: Luke Diamand <luke@diamand.org>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Catch the case where a ... exists at the end, and also elsehwere.
Reported-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code was not very complete or robust. Redo it.
This new code should be useful for a few possible additions
in the future:
- support for * and %%n wildcards
- allowing ... inside paths
- representing branch specs (not just client specs)
- tracking changes to views
Mark the remaining 12 tests in t9809 as fixed.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perforce client views can map individual files,
mapping one //depot file path to one //client file path.
These mappings contain no meta/masking characters.
This patch add support for these file maps to
the currently supported '...' view mappings.
[pw: one test now suceeds]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Correct view sorting to support the Perforce order,
where client views are ordered and later views
override earlier view mappings.
[pw: one test now succeeds]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change re method in test for unsupported Client View types
(containing %% or *) anywhere in the string rather than
at the begining.
[pw: two tests now succeed]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pw/p4-docs-and-tests:
git-p4: document and test submit options
git-p4: test and document --use-client-spec
git-p4: test --keep-path
git-p4: test --max-changes
git-p4: document and test --import-local
git-p4: honor --changesfile option and test
git-p4: document and test clone --branch
git-p4: test cloning with two dirs, clarify doc
git-p4: clone does not use --git-dir
git-p4: introduce asciidoc documentation
rename git-p4 tests
Clarify there is a -M option, but no -C. These are both
configurable through variables.
Explain that the allowSubmit variable takes a comma-separated
list of branch names.
Catch earlier an invalid branch name given as an argument to
"git p4 clone".
Test option --origin, variable allowSubmit, and explicit master
branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The depot path is required, even with this option. Make sure
git-p4 fails and exits with non-zero.
Contents in the specified depot path will be rearranged according
to the client spec. Test this and add a note in the docs.
Leave an XXX suggesting that this is somewhat confusing behavior
that might be good to fix later.
Function stripRepoPath() looks at self.useClientSpec. Make sure
this is set both for command-line option --use-client-spec and
for configuration variable git-p4.useClientSpec. Test this.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an explicit list of changes is given, it makes no sense to
use @all or @3,5 or any of the other p4 revision specifiers.
Make the code notice when this happens, instead of just ignoring
--changesfile. Test it.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Complain if --git-dir is given during a clone. It has no
effect. Only --destination and --bare can change where the newly
cloned git dir will be.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add proper documentation for git-p4. Delete the old .txt
documentation from contrib/fast-import.
Cc: Frans Klaver <fransklaver@gmail.com>
Cc: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/git-prompt:
contrib: add credential helper for OS X Keychain
Makefile: OS X has /dev/tty
Makefile: linux has /dev/tty
credential: use git_prompt instead of git_getpass
prompt: use git_terminal_prompt
add generic terminal prompt function
refactor git_getpass into generic prompt function
move git_getpass to its own source file
imap-send: don't check return value of git_getpass
imap-send: avoid buffer overflow
Conflicts:
Makefile
We use the 'read' command without -r, so that it treats '\' as an
escape character, in several places. This breaks the loop reading
refnames from git-for-each-ref in __git_refs() if there are refnames
such as "foo'bar", in which case for-each-ref helpfully quotes them as
$ git update-ref "refs/remotes/test/foo'bar" HEAD
$ git for-each-ref --shell --format="ref=%(refname:short)" "refs/remotes"
ref='test/foo'\''bar'
Interpolating the \' here will read "ref='test/foo'''bar'" instead, and
eval then chokes on the unbalanced quotes.
However, since none of the read loops _want_ to have backslashes
interpolated, it's much safer to use read -r everywhere.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7c766e5 (git-p4: introduce skipSubmitEdit, 2011-12-04)
made it easier to automate submission to p4, but broke the most
common case.
Add a test for when the user really does edit and save the change
template, and fix the bug that causes the test to fail.
Also add a confirmation message when submission is cancelled.
Reported-by: Michael Horowitz <michael.horowitz@ieee.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this installed in your $PATH, you can store
git-over-http passwords in your keychain by doing:
git config credential.helper osxkeychain
The code is based in large part on the work of Jay Soffian,
who wrote the helper originally for the initial, unpublished
version of the credential helper protocol.
This version will pass t0303 if you do:
GIT_TEST_CREDENTIAL_HELPER=osxkeychain \
GIT_TEST_CREDENTIAL_HELPER_SETUP="export HOME=$HOME" \
./t0303-credential-external.sh
The "HOME" setup is unfortunately necessary. The test
scripts set HOME to the trash directory, but this causes the
keychain API to complain.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
P4 only looks at the environment variable $PWD to figure out
where it is, so chdir() has code to set that every time. But
when the clone --destination is not an absolute path, PWD will
not be absolute and P4 won't be able to find any files expected
to be in the current directory. Fix this by expanding PWD to
an absolute path.
One place this crops up is when using a P4CONFIG environment
variable to specify P4 parameters, such as P4USER or P4PORT.
Setting P4CONFIG=.p4config works for p4 invocations from the
current directory. But if the value of PWD is not absolute, it
fails.
[ update description --pw ]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Submitting patches back to p4 requires a p4 "client". This
is a mapping from server depot paths into a local directory.
The directory need not exist or be populated with files; only
the mapping on the server is required. When there is no
directory, make git-p4 automatically create it.
[ reword description --pw ]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sg/complete-refs:
completion: remove broken dead code from __git_heads() and __git_tags()
completion: fast initial completion for config 'remote.*.fetch' value
completion: improve ls-remote output filtering in __git_refs_remotes()
completion: query only refs/heads/ in __git_refs_remotes()
completion: support full refs from remote repositories
completion: improve ls-remote output filtering in __git_refs()
completion: make refs completion consistent for local and remote repos
completion: optimize refs completion
completion: document __gitcomp()
Conflicts:
contrib/completion/git-completion.bash
Add a configuration variable to skip invoking the editor in the
submit path.
The existing variable skipSubmitEditCheck continues to make sure
that the submit template was indeed modified by the editor; but,
it is not considered if skipSubmitEdit is true.
Reported-by: Loren A. Linden Levy <lindenle@gmail.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit e5b8eebc (completion: fix issue with process substitution not
working on Git for Windows, 2011-10-26) introduced a new variable in
__git_ps1_show_upstream(), but didn't declare it as local to prevent it
from leaking into the environment.
We may want to rewrite it like the following, but that can wait until the
next cycle.
while read key value
do
...
done <<-EOF
$(git config -z --get-regexp ...)
EOF
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert 97a21ca (git-p4: stop ignoring apple filetype, 2011-10-16)
and add a test case.
Reported-by: Michael Wookey <michaelwookey@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git for Windows comes with a bash that doesn't support process substitution.
It issues the following error when using git-completion.bash with
GIT_PS1_SHOWUPSTREAM set:
$ export GIT_PS1_SHOWUPSTREAM=1
sh.exe": cannot make pipe for process substitution: Function not implemented
sh.exe": cannot make pipe for process substitution: Function not implemented
sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect
Replace the process substitution with a 'here string'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
__git_heads() was introduced in 5de40f5 (Teach bash about
git-repo-config., 2006-11-27), and __git_tags() in 88e21dc (Teach bash
about completing arguments for git-tag, 2007-08-31). As their name
suggests, __git_heads() is supposed to list only branches, and
__git_tags() only tags.
Since their introduction both of these functions consist of two
distinct parts. The first part gets branches or tags, respectively,
from a local repositoty using 'git for-each-ref'. The second part
queries a remote repository given as argument using 'git ls-remote'.
These remote-querying parts are broken in both functions since their
introduction, because they list both branches and tags from the remote
repository. (The 'git ls-remote' query is not limited to list only
heads or tags, respectively, and the for loop filtering the query
results prints everything except dereferenced tags.) This breakage
could be easily fixed by passing the '--heads' or '--tags' options or
appropriate refs patterns to the 'git ls-remote' invocations.
However, that no one noticed this breakage yet is probably not a
coincidence: neither of these two functions were used to query a
remote repository, the remote-querying parts were dead code already
upon thier introduction and remained dead ever since.
Since those parts of code are broken, are and were never used, stop
the bit-rotting and remove them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refspecs for branches in a remote repository start with 'refs/heads/',
so completing those refspecs with 'git config remote.origin.fetch
<TAB>' always offers 'refs/heads/' first, because that's the unique
part of the possible refspecs. But it does so only after querying the
remote with 'git ls-remote', which can take a while when the request
goes through some slower network to a remote server.
Don't waste the user's time and offer 'refs/heads/' right away for
'git config remote.origin.fetch <TAB>'.
The reason for putting 'refs/heads/' directly into COMPREPLY instead
of using __gitcomp() is to avoid __gitcomp() adding a trailing space.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This follows suit of a previous patch for __git_refs(): use a
while-read loop and let bash's word splitting get rid of object names
from 'git ls-remote's output.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
__git_refs_remotes() is used to provide completion for refspecs to set
'remote.*.fetch' config variables for branches on the given remote.
So it's really only interested in refs under 'refs/heads/', but it
queries the remote for all its refs and then filters out all refs
outside of 'refs/heads/'.
Let 'git ls-remote' do the filtering.
Also remove the unused $cmd variable from __git_refs_remotes().
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the __git_refs() completion helper function lists refs from a
local repository, it usually lists the refs' short name, except when
it needs to provide completion for words starting with refs, because
in that case it lists full ref names, see 608efb87 (bash: complete
full refs, 2008-11-28).
Add the same functionality to the code path dealing with remote
repositories, too.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The remote-handling part of __git_refs() has a nice for loop and state
machine case statement to iterate over all words from the output of
'git ls-remote' to identify object names and ref names. Since each
line in the output of 'git ls-remote' consists of an object name and a
ref name, we can do more effective filtering by using a while-read
loop and letting bash's word splitting take care of object names.
This way the code is easier to understand and the loop will need only
half the number of iterations than before.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a local repository the __git_refs() completion helper function
lists refs under 'refs/(tags|heads|remotes)/', plus some special refs
like HEAD and ORIG_HEAD. For a remote repository, however, it lists
all refs.
Fix this inconsistency by specifying refs filter patterns for 'git
ls-remote' to only list refs under 'refs/(tags|heads|remotes)/'.
For now this makes it impossible to complete refs outside of
'refs/(tags|heads|remotes)/' in a remote repository, but a followup
patch will resurrect that.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After a unique command or option is completed, in most cases it is a
good thing to add a trailing a space, but sometimes it doesn't make
sense, e.g. when the completed word is an option taking an argument
('--option=') or a configuration section ('core.'). Therefore the
completion script uses the '-o nospace' option to prevent bash from
automatically appending a space to unique completions, and it has the
__gitcomp() function to add that trailing space only when necessary.
See 72e5e989 (bash: Add space after unique command name is completed.,
2007-02-04), 78d4d6a2 (bash: Support unique completion on git-config.,
2007-02-04), and b3391775 (bash: Support unique completion when
possible., 2007-02-04).
__gitcomp() therefore iterates over all possible completion words it
got as argument, and checks each word whether a trailing space is
necessary or not. This is ok for commands, options, etc., i.e. when
the number of words is relatively small, but can be noticeably slow
for large number of refs. However, while options might or might not
need that trailing space, refs are always handled uniformly and always
get that trailing space (or a trailing '.' for 'git config
branch.<head>.'). Since refs listed by __git_refs() & co. are
separated by newline, this allows us some optimizations with
'compgen'.
So, add a specialized variant of __gitcomp() that only deals with
possible completion words separated by a newline and uniformly appends
the trailing space to all words using 'compgen -S " "' (or any other
suffix, if specified), so no iteration over all words is needed. But
we need to fiddle with IFS, because the default IFS containing a space
would cause the added space suffix to be stripped off when compgen's
output is stored in the COMPREPLY array. Therefore we use only
newline as IFS, hence the requirement for the newline-separated
possible completion words.
Convert all callsites of __gitcomp() where it's called with refs, i.e.
when it gets the output of either __git_refs(), __git_heads(),
__git_tags(), __git_refs2(), __git_refs_remotes(), or the odd 'git
for-each-ref' somewhere in _git_config(). Also convert callsites
where it gets other uniformly handled newline separated word lists,
i.e. either remotes from __git_remotes(), names of set configuration
variables from __git_config_get_set_variables(), stashes, or commands.
Here are some timing results for dealing with 10000 refs.
Before:
$ refs="$(__git_refs ~/tmp/git/repo-with-10k-refs/)"
$ time __gitcomp "$refs"
real 0m1.134s
user 0m1.060s
sys 0m0.130s
After:
$ time __gitcomp_nl "$refs"
real 0m0.373s
user 0m0.360s
sys 0m0.020s
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I always forget which argument is which, and got tired of figuring it
out over and over again.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A common thing to grep for is the name of a symbol. This
patch teaches the completion for "git grep" to look in
a 'tags' file, if present, to complete a pattern. For
example, in git.git:
$ make tags
$ git grep get_sha1<Tab><Tab>
get_sha1 get_sha1_oneline
get_sha1_1 get_sha1_with_context
get_sha1_basic get_sha1_with_context_1
get_sha1_hex get_sha1_with_mode
get_sha1_hex_segment get_sha1_with_mode_1
get_sha1_mb
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a small script for helping your editor jump to
specific points of interest. See the README for details.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On the MediaWiki side, the author information is just the MediaWiki login
of the contributor. The import turns it into login@$wiki_name to create
the author's email address on the wiki side. But we don't want this to
include the HTTP password if it's present in the URL ...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a simple and stupid script for highlighting
differing parts of lines in a unified diff. See the README
for a discussion of the limitations.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently "apple" filetype is ignored explicitly, and the file is
not even included in the git repository. This seems wrong.
Remove this, letting it be treated like a "binary" filetype.
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4 used to simply pass strings into system() and popen(), and
relied on the shell doing the necessary expansion. This though meant
that shell metacharacters in file names would be corrupted - for
example files with $ or space in them.
Switch to using subprocess.Popen() and friends, and pass in explicit
arrays in the places where it matters. This then avoids needing shell
expansion.
Add trivial helper functions for some common perforce operations. Add
test case.
[pw: test cleanup]
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code was approximate in the filetypes it recognized.
Put in the canonical list and be more careful about matching
elements of the file type.
This might change behavior in some cases, hopefully for the
better. Windows newline mangling will now happen on all
text files. Previously some like "text+ko" were oddly exempt.
Files with multiple combinations of modifiers, like "text+klx",
are now recognized for keyword expansion. I expect these to be
seen only rarely.
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Join the text before looking for keywords. There is nothing to
prevent the p4 output marshaller from splitting in the middle of a
keyword, although it has never been known to happen.
Also remove the (?i) regexp modifier; perforce keywords are
documented as case-sensitive.
Remove the "\n" end-character match. I don't know why that is
in there, and every keyword in a fairly large production p4 repository
always ends with a $.
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One of the filetypes that p4 supports is utf16. Its behavior is
odd in this case. The data delivered through "p4 -G print" is
not encoded in utf16, although "p4 print -o" will produce the
proper utf16-encoded file.
When dealing with this filetype, discard the data from -G, and
instead read the contents directly.
An alternate approach would be to try to encode the data in
python. That worked for true utf16 files, but for other files
marked as utf16, p4 delivers mangled text in no recognizable encoding.
Add a test case to check utf16 handling, and +k and +ko handling.
Reported-by: Chris Li <git@chrisli.org>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/mediawiki-as-a-remote:
git-remote-mediawiki: allow a domain to be set for authentication
git-remote-mediawiki: obey advice.pushNonFastForward
git-remote-mediawiki: set 'basetimestamp' to let the wiki handle conflicts
git-remote-mediawiki: trivial fixes
git-remote-mediawiki: allow push to set MediaWiki metadata
Add a remote helper to interact with mediawiki (fetch & push)
When the wiki uses e.g. LDAP for authentication, the web interface shows
a popup to allow the user to chose an authentication domain, and we need
to use lgdomain in the API at login time.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already have a check that no new revisions are on the wiki at the
beginning of the push, but this didn't handle concurrent accesses to the
wiki.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a whitespace issue (no space before :) and remove unused %status in
mw_push.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Push can not set the commit note "mediawiki_revision:" and update the
remote reference. This avoids having to "git pull --rebase" after each
push, and is probably more natural. Make it the default, but let it be
configurable with mediawiki.dumbPush or remote.<remotename>.dumbPush.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement a gate between git and mediawiki, allowing git users to push
and pull objects from mediawiki just as one would do with a classic git
repository thanks to remote-helpers.
The following packages need to be installed (available on common
repositories):
libmediawiki-api-perl
libdatetime-format-iso8601-perl
Use remote helpers in order to be as transparent as possible to the git
user.
Download Mediawiki revisions through the Mediawiki API and then
fast-import into git.
Mediawiki revision number and git commits are linked thanks to notes
bound to commits.
The import part is done on a refs/mediawiki/<remote> branch before
coming to refs/remote/origin/master (Huge thanks to Jonathan Nieder
for his help)
We use UTF-8 everywhere: use encoding 'utf8'; does most of the job, but
we also read the output of Git commands in UTF-8 with the small helper
run_git, and write to the console (STDERR) in UTF-8. This allows a
seamless use of non-ascii characters in page titles, but hasn't been
tested on non-UTF-8 systems. In particular, UTF-8 encoding for filenames
could raise problems if different file systems handle UTF-8 filenames
differently. A uri_escape of mediawiki filenames could be imaginable, and
is still to be discussed further.
Partial cloning is supported using one of:
git clone -c remote.origin.pages='A_Page Another_Page' mediawiki::http://wikiurl
git clone -c remote.origin.categories='Some_Category' mediawiki::http://wikiurl
git clone -c remote.origin.shallow='True' mediawiki::http://wikiurl
Thanks to notes metadata, it is possible to compare remote and local last
mediawiki revision to warn non-fast forward pushes and "everything
up-to-date" case.
When allowed, push looks for each commit between remotes/origin/master
and HEAD, catches every blob related to these commit and push them in
chronological order. To do so, it uses git rev-list --children HEAD and
travels the tree from remotes/origin/master to HEAD through children. In
other words:
* Shortest path from remotes/origin/master to HEAD
* For each commit encountered, push blobs related to this commit
Signed-off-by: Jérémie Nikaes <jeremie.nikaes@ensimag.imag.fr>
Signed-off-by: Arnaud Lacurie <arnaud.lacurie@ensimag.imag.fr>
Signed-off-by: Claire Fousse <claire.fousse@ensimag.imag.fr>
Signed-off-by: David Amouyal <david.amouyal@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Sylvain Boulmé <sylvain.boulme@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* va/p4-branch-import:
git-p4: Add simple test case for branch import
git-p4: Allow branch definition with git config
git-p4: Allow filtering Perforce branches by user
git-p4: Correct branch base depot path detection
git-p4: Process detectCopiesHarder with --bool
git-p4: Add test case for copy detection
git-p4: Add test case for rename detection
git-p4: Add description of rename/copy detection options
git-p4: Allow setting rename/copy detection threshold
Perforce does not strictly require the usage of branch specifications to create
branches. In these cases the branch detection code of git-p4 will not be able to
import them.
This patch adds support for git-p4.branchList configuration option, allowing
branches to be defined in git config.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All branches in the Perforce server are downloaded to allow branch detection. If
you have a centralized server on a remote location and there is a big number of
branches this operation can take some time.
This patch adds the configuration option git-p4.branchUser to allow filtering
the branch list by user. Although this limits the branch maintenance in Perforce
to be done by a single user, it might be an advantage when the number of
branches being used in a specific depot is very small when compared with the
branches available in the server.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When branch detection is enabled each branch is named in git after their
relative depot path in Perforce. To do this the depot paths are compared against
each other to find their common base path. The current algorithm makes this
comparison on a character by character basis.
Assuming we have the following branches:
//depot/branches/featureA
//depot/branches/featureB
Then the base depot path would be //depot/branches/feature, which is an invalid
depot path.
The current patch fixes this by splitting the path into a list and comparing the
list entries, making it choose correctly //depot/branches as the base path.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Copy and rename detection arguments (-C and -M) allow setting a threshold value
for the similarity ratio. If the similarity is below this threshold the rename
or copy is ignored and the file is added as new.
This patch allows setting git-p4.detectRenames and git-p4.detectCopies options
to an integer value to set the respective threshold.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes it easy to customize the git diff-tree options, for example
to include -p to include inline diffs.
It defaults to the current options "--stat --summary --find-copies-harder"
and thus is backward-compatible.
Signed-off-by: Jon Jensen <jon@endpoint.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When importing a repo, the time on the initial commit had been
just "now". But this causes problems when trying to share among
git-p4 repos that were created identically, although at different
times. Instead, use the time in the top-most p4 change as the
time for the git import commit.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the namespace mechanism in a new gitnamespaces(7) page.
Reference it from receive-pack and upload-pack.
Document the new --namespace option and GIT_NAMESPACE environment
variable in git(1), and reference gitnamespaces(7).
Add a sample Apache configuration to http-backend(1) to support
namespaced repositories, and reference gitnamespaces(7).
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The SYNOPSIS sections of most commands that span several lines already
use [verse] to retain line breaks. Most commands that don't span
several lines seem not to use [verse]. In the HTML output, [verse]
does not only preserve line breaks, but also makes the section
indented, which causes a slight inconsistency between commands that
use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
for consistency.
Also remove the blank lines from git-fetch.txt and git-rebase.txt to
align with the other man pages. In the case of git-rebase.txt, which
already uses [verse], the blank line makes the [verse] not apply to
the last line, so removing the blank line also makes the formatting
within the document more consistent.
While at it, add single quotes to 'git cvsimport' for consistency with
other commands.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The core.abbrevguard config variable had removed and
now core.abbrev has been used instead. Teach it.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/grep-pcre:
git-grep: Fix problems with recently added tests
git-grep: Update tests (mainly for -P)
Makefile: Pass USE_LIBPCRE down in GIT-BUILD-OPTIONS
git-grep: update tests now regexp type is "last one wins"
git-grep: do not die upon -F/-P when grep.extendedRegexp is set.
git-grep: Bail out when -P is used with -F or -E
grep: Add basic tests
configure: Check for libpcre
git-grep: Learn PCRE
grep: Extract compile_regexp_failed() from compile_regexp()
grep: Fix a typo in a comment
grep: Put calls to fixmatch() and regmatch() into patmatch()
contrib/completion: --line-number to git grep
Documentation: Add --line-number to git-grep synopsis
Handle input in Subversion's dumpfile format, version 3. This is the
format produced by "svnrdump dump" and "svnadmin dump --deltas", and
the main difference between v3 dumpfiles and the dumpfiles already
handled is that these can include nodes whose properties and text are
expressed relative to some other node.
To handle such nodes, we find which node the text and properties are
based on, handle its property changes, use the cat-blob command to
request the basis blob from the fast-import backend, use the
svndiff0_apply() helper to apply the text delta on the fly, writing
output to a temporary file, and then measure that postimage file's
length and write its content to the fast-import stream.
The temporary postimage file is shared between delta-using nodes to
avoid some file system overhead.
The svn-fe interface needs to be more complicated to accomodate the
backward flow of information from the fast-import backend to svn-fe.
The backflow fd is not needed when parsing streams without deltas,
though, so existing scripts using svn-fe on v2 dumps should
continue to work.
NEEDSWORK: generalize interface so caller sets the backflow fd, close
temporary file before exiting
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
This teaches svn-fe to incrementally import into an existing
repository (at last!) at the expense of less convenient UI. Think of
it as growing pains. This opens the door to many excellent things,
and it would be a bad idea to discourage people from building on it
for much longer.
* db/vcs-svn-incremental:
vcs-svn: avoid using ls command twice
vcs-svn: use mark from previous import for parent commit
vcs-svn: handle filenames with dq correctly
vcs-svn: quote paths correctly for ls command
vcs-svn: eliminate repo_tree structure
vcs-svn: add a comment before each commit
vcs-svn: save marks for imported commits
vcs-svn: use higher mark numbers for blobs
vcs-svn: set up channel to read fast-import cat-blob response
Conflicts:
t/t9010-svn-fe.sh
vcs-svn/fast_export.c
vcs-svn/fast_export.h
vcs-svn/repo_tree.c
vcs-svn/svndump.c
* ld/p4-preserve-user-names:
git-p4: warn if git authorship won't be retained
git-p4: small improvements to user-preservation
git-p4: add option to preserve user names
* sg/completion-updates:
Revert "completion: don't declare 'local words' to make zsh happy"
git-completion: fix regression in zsh support
completion: move private shopt shim for zsh to __git_ namespace
completion: don't declare 'local words' to make zsh happy
If the git commits you are submitting contain changes made by
other people, the authorship will not be retained. Change git-p4
to warn of this and to note that --preserve-user can be used
to solve the problem (if you have suitable permissions).
The warning can be disabled.
Add a test case and update documentation.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The zsh support of git-completion script in contrib/ is broken for current
versions of zsh, and does not notice when there's a subcommand.
For example: "git log origi<TAB>" gives no completions because it would
try to find a "git origi..." command. This will be fixed by zsh 4.3.12,
but for now we can workaround it by backporting the same fix as zsh folks
implemented.
The problem started after commit v1.7.4-rc0~11^2~2 (bash: get
--pretty=m<tab> completion to work with bash v4), which introduced
_get_comp_words_by_ref() that comes from bash-completion[1] scripts, and
relies on the 'words' variable.
However, it turns out 'words' is a special variable used by zsh
completion. From zshcompwid(1):
[...] the parameters are reset on each function exit (including nested
function calls from within the completion widget) to the values they had
when the function was entered.
As a result, subcommand words are lost. Ouch.
This is now fixed in the latest master branch of zsh[2] by simply defining
'words' as hidden (typeset -h), which removes the special meaning inside
the emulated bash function. So let's do the same.
Jonathan Nieder helped on the commit message.
[1] http://bash-completion.alioth.debian.org/
[2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=e880604f029088f32fb1ecc39213d720ae526aaa
Reported-by: Stefan Haller <lists@haller-berlin.de>
Comments-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>
This patch teaches git-grep the --perl-regexp/-P options (naming
borrowed from GNU grep) in order to allow specifying PCRE regexes on the
command line.
PCRE has a number of features which make them more handy to use than
POSIX regexes, like consistent escaping rules, extended character
classes, ungreedy matching etc.
git isn't build with PCRE support automatically. USE_LIBPCRE environment
variable must be enabled (like `make USE_LIBPCRE=YesPlease`).
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
. Slightly more paranoid checking of results from 'p4 change'
. Remove superfluous "-G"
. Don't modify the username if it is unchanged.
. Add a comment in the change template to show what is
going to be done.
Signed-off-by: Luke Diamand <luke@diamand.org>
Acked-By: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most zsh users probably probably do not expect a custom shopt function
to enter their environment just because they ran "source
~/.git-completion.sh".
Such namespace pollution makes development of other scripts confusing
(because it makes the bash-specific shopt utility seem to be available
in zsh) and makes git's tab completion script brittle (since any other
shell snippet implementing some other subset of shopt will break it).
Rename the shopt shim to the more innocuous __git_shopt to be a good
citizen (with two underscores to avoid confusion with completion rules
for a hypothetical "git shopt" command).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-n" option of "git grep" gained a synonym "--line-number" with
commit 7d6cb10b ("grep: Add the option '--line-number'", 2011-03-28).
Teach bash-completion about it.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "_get_comp_words_by_ref -n := words" command from the
bash_completion library reassembles a modified version of COMP_WORDS
with ':' and '=' no longer treated as word separators and stores it in
the ${words[@]} array. Git's programmable tab completion script uses
this to abstract away the difference between bash v3's and bash v4's
definitions of COMP_WORDS (bash v3 used shell words, while bash v4
breaks at separator characters); see v1.7.4-rc0~11^2~2 (bash: get
--pretty=m<tab> completion to work with bash v4, 2010-12-02).
zsh has (or rather its completion functions have) another idea about
what ${words[@]} should contain: the array is prepopulated with the
words from the command it is completing. For reasons that are not
well understood, when git-completion.bash reserves its own "words"
variable with "local words", the variable becomes empty and cannot be
changed from then on. So the completion script neglects the arguments
it has seen, and words complete like git subcommand names. For
example, typing "git log origi<TAB>" gives no completions because
there are no "git origi..." commands.
However, when this words variable is not declared as local but is just
populated by _get_comp_words_by_ref() and then read in various
completion functions, then zsh seems to be happy about it and our
completion script works as expected.
So, to get our completion script working again under zsh and to
prevent the words variable from leaking into the shell environment
under bash, we will only declare words as local when using bash.
Reported-by: Stefan Haller <lists@haller-berlin.de>
Suggested-by: Felipe Contreras <felipe.contreras@gmail.com>
Explained-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
to access completion-related variables. That was large change, and to
make it easily reviewable, we invoked _get_comp_words_by_ref() in each
completion function and systematically replaced every occurance of
bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
variables set by _get_comp_words_by_ref().
This has the downside that _get_comp_words_by_ref() is invoked several
times during a single completion. The worst offender is perhaps 'git
log mas<TAB>': during the completion of 'master'
_get_comp_words_by_ref() is invoked no less than six times.
However, the variables $prev, $cword, and $words provided by
_get_comp_words_by_ref() are not modified in any of the completion
functions, and the previous commit ensures that the $cur variable is
not modified as well. This makes it possible to invoke
_get_comp_words_by_ref() to get those variables only once in our
toplevel completion functions _git() and _gitk(), and all other
completion functions will inherit them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
with bash v4, 2010-12-02) we use _get_comp_words_by_ref() to access
completion-related variables, and the $cur variable holds the word
containing the current cursor position in all completion functions.
This $cur variable is left unchanged in most completion functions;
there are only four functions modifying its value, namely __gitcomp(),
__git_complete_revlist_file(), __git_complete_remote_or_refspec(), and
_git_config().
If this variable were never modified, then it would allow us a nice
optimisation and cleanup. Therefore, this patch assigns $cur to an
other local variable and uses that for later modifications in those
four functions.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If bashcompinit has not already been autoloaded, do so
automatically, as it is required to properly parse the
git-completion file with ZSH.
Helped-by: Felipe Contreras
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Patches from git passed into p4 end up with the committer being identified
as the person who ran git-p4.
With "submit --preserve-user", git-p4 modifies the p4 changelist (after it
has been submitted), setting the p4 author field.
The submitter is required to have sufficient p4 permissions or git-p4
refuses to proceed. If the git author is not known to p4, the submit will
be abandoned unless git-p4.allowMissingP4Users is true.
Signed-off-by: Luke Diamand <luke@diamand.org>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that the majority of git-p4 uses spaces, not tabs, for indentation.
Consistent indentation is a good hygiene for Python scripts, and mixing
tabs and spaces in Python can lead to hard-to-find bugs.
Signed-off-by: Andrew Garber <andrew@andrewgarber.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If font-lock is disabled, font-lock-compile-keywords complains.
Really what we want to do is to replace log-edit's font-lock
definitions with our own, so define a major mode deriving from
log-edit and set up font-lock-defaults there. We then use the
optional MODE argument to log-edit to set up the major mode of the
commit buffer appropriately.
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Acked-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
contrib/thunderbird-patch-inline: do not require bash to run the script
t8001: check the exit status of the command being tested
strbuf.h: remove a tad stale docs-in-comment and reference api-doc instead
Typos: t/README
Documentation/config.txt: make truth value of numbers more explicit
git-pack-objects.txt: fix grammatical errors
parse-remote: replace unnecessary sed invocation
The script does not have to be run under bash, but any POSIX compliant
shell would do, as it does not use any bash-isms.
It may be written under a different style than what is recommended in
Documentation/CodingGuidelines, but that is a different matter.
While at it, fix obvious typos in the comment.
Signed-off-by: Maxin B. John <maxin@maxinbjohn.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/rev-list-n-parents:
tests: avoid nonportable {foo,bar} glob
rev-list --min-parents,--max-parents: doc, test and completion
revision.c: introduce --min-parents and --max-parents options
t6009: use test_commit() from test-lib.sh
This also adds test for "--merges" and "--no-merges" which we did not
have so far.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tl/p4:
git-p4: Fix error message crash in P4Sync.commit.
Teach git-p4 to ignore case in perforce filenames if configured.
git-p4: Teach gitConfig method about arguments.
Enable bash completion for "git help <alias>", analogous to "git
<alias>", which was already implemented.
Signed-off-by: Jakob Pfender <jpfender@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
e32e00d (git-p4: better message for "git-p4 sync" when not
cloned, 2011-02-19) broke another use case, that of using
"git-p4 sync" to import a new branch into an existing repository.
Refine the fix again, on top of the fix in ac34efc.
Reported-by: Michael Horowitz <michael.horowitz@ieee.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Tested-by: Michael Horowitz <michael.horowitz@ieee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is an error message that crashes the script because of an invalid ref
to the non-existing "path" variable. It is almost never printed, which
would explain why nobody encountered this problem before... But anyway,
this oneliner fixes it.
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When files are added to perforce, the path to that file has whichever case
configuration that exists on the machine of the user who added the file.
What does that mean? It means that when Alice adds a file
//depot/DirA/FileA.txt
... and Bob adds:
//depot/dirA/FileB.txt
... we may or may not get a problem. If a user sets the config variable
git-p4.ignorecase to "true", we will consider //depot/DirA and //depot/dirA
to be the same directory.
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this patch, it is possible to call the gitConfig method with an optional
argument string, which will be passed to the "git config" executable. For
instance:
gitConfig("core.ignorecase", "--bool")
will ensure that you get the value "true", and won't have to check the returned
value for [1, true, on, yes].
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
e32e00d (git-p4: better message for "git-p4 sync" when not cloned,
2011-02-19) broke the use of the "@all" revision specifier, e.g.,
git-p4 clone //depot/xxx@all
Fix it as per Tor Arvid's quick patch.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Reported-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Based-on-patch-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set up some plumbing: teach the svndump lib to pass a file descriptor
number to the fast_export lib, representing where cat-blob/ls
responses can be read from, and add a get_response_line helper
function to the fast_export lib to read a line from that file.
Unfortunately this means that svn-fe needs file descriptor 3 to be
redirected from somewhere (preferrably the cat-blob stream of a
fast-import backend); otherwise it will fail:
$ svndump <path> | svn-fe
fatal: cannot read from file descriptor 3: Bad file descriptor
For the moment, "svn-fe 3</dev/null" works as a workaround but it
will not work for very long. A fast-import backend that can retrieve
old commits is needed in order to be able to fulfill svn
"Node-copyfrom-rev" requests that refer to revs from a previous run.
[jn: with new change description]
Based-on-patch-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
* 'svn-fe' of git://repo.or.cz/git/jrn: (31 commits)
fast-import: make code "-Wpointer-arith" clean
vcs-svn: teach line_buffer about temporary files
vcs-svn: allow input from file descriptor
vcs-svn: allow character-oriented input
vcs-svn: add binary-safe read function
t0081 (line-buffer): add buffering tests
vcs-svn: tweak test-line-buffer to not assume line-oriented input
tests: give vcs-svn/line_buffer its own test script
vcs-svn: make test-line-buffer input format more flexible
vcs-svn: teach line_buffer to handle multiple input files
vcs-svn: collect line_buffer data in a struct
vcs-svn: replace buffer_read_string memory pool with a strbuf
vcs-svn: eliminate global byte_buffer
fast-import: add 'ls' command
vcs-svn: Allow change nodes for root of tree (/)
vcs-svn: Implement Prop-delta handling
vcs-svn: Sharpen parsing of property lines
vcs-svn: Split off function for handling of individual properties
vcs-svn: Make source easier to read on small screens
vcs-svn: More dump format sanity checks
...
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pw/p4:
git-p4: support clone --bare
git-p4: decode p4 wildcard characters
git-p4: better message for "git-p4 sync" when not cloned
git-p4: reinterpret confusing p4 message
git-p4: accommodate new move/delete type in p4
git-p4: add missing newline in initial import message
git-p4: fix key error for p4 problem
git-p4: test script
* git://github.com/gitster/git:
vcs-svn: Allow change nodes for root of tree (/)
vcs-svn: Implement Prop-delta handling
vcs-svn: Sharpen parsing of property lines
vcs-svn: Split off function for handling of individual properties
vcs-svn: Make source easier to read on small screens
vcs-svn: More dump format sanity checks
vcs-svn: Reject path nodes without Node-action
vcs-svn: Delay read of per-path properties
vcs-svn: Combine repo_replace and repo_modify functions
vcs-svn: Replace = Delete + Add
vcs-svn: handle_node: Handle deletion case early
vcs-svn: Use mark to indicate nodes with included text
vcs-svn: Unclutter handle_node by introducing have_props var
vcs-svn: Eliminate node_ctx.mark global
vcs-svn: Eliminate node_ctx.srcRev global
vcs-svn: Check for errors from open()
vcs-svn: Allow simple v3 dumps (no deltas yet)
Conflicts:
t/t9010-svn-fe.sh
vcs-svn/svndump.c
In an attempt to overwrite the 'Description:' section of the p4 change
log to include the git commit messages, it also overwrote the 'Jobs:'
section. Â This fix restores the 'Job:' section.
Signed-off-by: Michael Horowitz <michael.horowitz@ieee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the git prompt (when enabled) show a CHERRY-PICKING indicator
when we are in the middle of a conflicted cherry-pick, analogous
to the existing MERGING and BISECTING flags.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new config options:
git-p4.detectCopies - Enable copy detection.
git-p4.detectCopiesHarder - Find copies harder.
The detectCopies option should be set to a true/false value.
The detectCopiesHarder option should be set to true/false value.
P4Submit can now process diff-tree C status and integrate files accordingly.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Acked-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only open files for edit after integrating if the SHA1 of source and destination
differ from each other.
Add git config option detectRenames to allow permanent rename detection. This
options should be set to a true/false value.
Rename "detectRename" variable to "detectRenames" to make it more coherent with
the description in git man pages, which always use plural.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Acked-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just like git clone --bare, build a .git directory but no
checked out files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-By: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are four wildcard characters in p4. Files with these
characters can be added to p4 repos using the "-f" option.
They are stored in %xx notation, and when checked out, p4
converts them back to normal.
This patch does the same thing when importing into git,
converting the four special characters. Without this change,
the files appear with literal %xx in their names.
Be careful not to produce "*" in filenames on windows. That
will fail.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A common error is to do "git-p4 sync" in a repository that
was not initialized by "git-p4 clone". There will be no
p4 refs. The error message in this case is a traceback
for an assertion, which is confusing.
Change it instead to explain the likely problem.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-By: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Error output will look like this:
glom$ git p4 clone //deopt
Importing from //deopt into .
Reinitialized existing Git repository in /tmp/x/.git/
Doing initial import of //deopt from revision #head into refs/remotes/p4/master
p4 returned an error: //deopt/... - must refer to client glom.
This particular p4 error is misleading.
Perhaps the depot path was misspelled.
Depot path: //deopt
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
562d53f (git-p4: Fix sync errors due to new server version, 2010-01-21)
taught git-p4 sync to recognize the new move/delete type, but this type
can also show up in an initial clone and labels output.
Instead of replicating the support in three places, hoist the definition
somewhere global.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-By: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some p4 failures result in an error, but the info['code'] is not
set. These include a bad p4 executable, or a core dump from p4,
and other odd internal errors where p4 fails to generate proper
marshaled output.
Make sure the info key exists before using it to avoid a python
traceback.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the p4 client spec, this attempts to obey the client's
output preferences.
For example, a view like
//depot/foo/branch/... //client/branch/foo/...
//depot/bar/branch/... //client/branch/bar/...
will result in a directory layout in the git tree of
branch/
branch/foo
branch/bar
p4 can do various other reordering that this change doesn't support,
but we should detect it and at least fail nicely.
Signed-off-by: Ian Wienand <ianw@vmware.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Acked-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
svn-fe is young and some coming cleanups might involve backward
incompatible UI changes. Add some words of warning to the manual so
early adopters that are not following the project closely don't get
burned.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For example, this would allow cherry-picking or reverting patches from
a piece of history with a different end-of-line style, like so:
$ git revert -Xrenormalize old-problematic-commit
Currently that is possible with manual use of merge-recursive but the
cherry-pick/revert porcelain does not expose the functionality.
While at it, document the existing support for --strategy.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pd/bash-4-completion:
bash: simple reimplementation of _get_comp_words_by_ref
bash: get --pretty=m<tab> completion to work with bash v4
Conflicts:
contrib/completion/git-completion.bash
Quite a few configuration variables have been added since 226b343
(completion: add missing configuration variables to _git_config(),
2009-05-03). Add these variables to the Bash completion script.
Also remove the obsolete 'add.ignore-errors' and
'color.grep.external', as well as 'diff.renameLimit.', which never
existed and rename the misspelled 'sendemail.aliasesfiletype'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"Promote" the reflog command out of plumbing, so that we now run
completion for it. After all, it's listed under porcelain (ancillary),
and we do run completion for those commands.
Add basic completion for the three subcommands - show, expire, delete.
Try completing refs for these too.
Helped-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' (early part): (529 commits)
completion: fix zsh check under bash with 'set -u'
Fix copy-pasted comments related to tree diff handling.
Git 1.7.3.2
{cvs,svn}import: use the new 'git read-tree --empty'
t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
Clarify and extend the "git diff" format documentation
git-show-ref.txt: clarify the pattern matching
documentation: git-config minor cleanups
Update test script annotate-tests.sh to handle missing/extra authors
Better advice on using topic branches for kernel development
Documentation: update implicit "--no-index" behavior in "git diff"
Documentation: expand 'git diff' SEE ALSO section
Documentation: diff can compare blobs
Documentation: gitrevisions is in section 7
fast-import: Allow filemodify to set the root
shell portability: no "export VAR=VAL"
CodingGuidelines: reword parameter expansion section
Documentation: update-index: -z applies also to --index-info
gitweb: Improve behavior for actionless path_info gitweb URLs
gitweb: Fix bug in evaluate_path_info
...
Conflicts:
GIT-VERSION-GEN
RelNotes
contrib/completion/git-completion.bash
Add a minimal implementation of _get_comp_words_by_ref so
$ git show head:g <tab><tab>
on bash 4 can complete paths within the head commit without requiring
the bash_completion functions to be loaded. This is a follow-up to
the previous patch (bash: get --pretty=m<tab> completion to work with
bash v4).
Based on bash-completion 2.x (commit bf763033, 2010-10-26) but tweaked
for simplicity and to allow zsh to parse the code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: SZEDER Gábor <szeder@ira.uka.de>
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
The function was returning 0 for failure and 1 for success which was
breaking the logic in the main loop. It now also returns in all
cases, rather than exiting.
Signed-off-by: Alan Raison <alan@theraisons.me.uk>
Acked-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
add: introduce add.ignoreerrors synonym for add.ignore-errors
bash: Match lightweight tags in prompt
git-commit.txt: (synopsis): move -i and -o before "--"
* maint-1.7.2:
add: introduce add.ignoreerrors synonym for add.ignore-errors
bash: Match lightweight tags in prompt
git-commit.txt: (synopsis): move -i and -o before "--"
The bash prompt would display a commit's object name when having checked
out a lightweight tag. Provide `--tags` to `git describe` in the completion
script, so it will display lightweight tag names, as it already does for
annotated tags.
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/phrase-remote-tracking:
git-branch.txt: mention --set-upstream as a way to change upstream configuration
user-manual: remote-tracking can be checked out, with detached HEAD
user-manual.txt: explain better the remote(-tracking) branch terms
Change incorrect "remote branch" to "remote tracking branch" in C code
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change "tracking branch" to "remote-tracking branch"
everyday.txt: change "tracking branch" to "remote-tracking branch"
Change remote tracking to remote-tracking in non-trivial places
Replace "remote tracking" with "remote-tracking"
Better "Changed but not updated" message in git-status
test-svn-fe segfaults when passed a bogus path. Simplify debugging by
exiting with a meaningful error message instead.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sg/completion:
bash: support pretty format aliases
bash: support more 'git notes' subcommands and their options
bash: not all 'git bisect' subcommands make sense when not bisecting
bash: offer refs for 'git bisect start'
c5022f57 (git-blame.el: Change how blame information is shown,
2009-09-29) taught the "M-x git-blame" mode to format its output
in a more interesting way, making use of the format-spec function.
format-spec is included in Emacs 23 and is a useful function.
Older emacsen can get it from Gnus. In all emacsen, we need
to 'require it before use to avoid warnings:
git-blame.el:483:1:Warning: the function `format-spec' is not known to be
defined.
Reported-by: Sergei Organov <osv@javad.com>
Reported-by: Kevin Ryde <user42@zip.com.au>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(Just like we did for documentation already)
In the process, we change "non-remote branch" to "branch outside the
refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch".
The new formulation actually corresponds to how the code detects this
case (i.e. prefixcmp(refname, "refs/remotes")).
Also, we use 'remote-tracking branch' in generated merge messages (by
merge an fmt-merge-msg).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For each commit a shorter version of the name will be generated. This is
either the truncated hash or the output of git-describe. The
call to git-describe was only made with an empty shell variable instead
of an actual commit hash. Thus it only described the current HEAD and
not each commit we want to submit to cia.vc.
Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 06f44c3 (completion: make compatible with zsh) broke bash
compatibility with 'set -u': a warning was generated when checking
$ZSH_VERSION. The solution is to supply a default value, using
${ZSH_VERSION-}. Thanks to SZEDER Gábor for the fix.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since fb1bb96 (read-tree: deprecate syntax without tree-ish args,
2010-09-10) not passing --empty caused a spurious warning that was
shown to the user.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since commit 70c9ac2 (DWIM: "git checkout frotz" to "git checkout
-b frotz origin/frotz"), git checkout has supported a DWIM mode where
it creates a local tracking branch for a remote branch if just the name
of the remote branch is specified on the command-line and only one remote
has a branch with that name. Teach the bash completion script to understand
this DWIM mode and provide such remote-tracking branch names as possible
completions.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can have their own pretty format aliases since 8028184 (pretty:
add aliases for pretty formats, 2010-05-02), so let's offer those
after '--pretty=' and '--format=' for 'log' and 'show', too.
Similar to the completion of aliases, this will invoke 'git config'
each time pretty aliases needs to be completed, so changes in pretty.*
configuration will be reflected immediately.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current completion function for 'git notes' only supported the
'edit' and 'show' subcommands and none of their options. This patch
adds support for all missing subcommands, options, and their arguments
(files or refs), if any.
The code responsible for completing subcommand looks different
compared to the completion functions of other git commands with
subcommands. This is because of the '--ref <notes-ref>' option which
comes before the subcommand (i.e. git notes --ref <notes-ref> add).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... but only 'start' and 'replay'. The other commands will either
error out or offer to start bisecting for the user.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The completion script only offered path completion after 'git bisect
start', although bad and good refs could also be specified before the
doubledash.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the Perl scripts to turn on lexical warnings instead of setting
the global $^W variable via the -w switch.
The -w sets warnings for all code that interpreter runs, while "use
warnings" is lexically scoped. The former is probably not what the
authors wanted.
As an auxiliary benefit it's now possible to build Git with:
PERL_PATH='/usr/bin/env perl'
Which would previously result in failures, since "#!/usr/bin/env perl -w"
doesn't work as a shebang.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though "-L" is POSIX, the former is more portable, and
we tend to prefer it already.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changes the logic in the script to determine whether an email message
will be sent before invoking the send_mail() function; otherwise, if
the logic determines that a message will not be sent, send_mail() will
cause an empty email to be sent. In addition, ensures that if multiple
refs are updated and a message cannot be sent for one of them,
the others are still processed normally.
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify git-completion.bash so that it also works with zsh when using
bashcompinit. In particular:
declare -F
Zsh doesn't have the same 'declare -F' as bash, but 'declare -f'
is the same, and it works just as well for our purposes.
${var:2}
Zsh does not implement ${var:2} to skip the first 2 characters, but
${var#??} works in both shells to replace the first 2 characters
with nothing. Thanks to Jonathan Nieder for the suggestion.
for (( n=1; "$n" ... ))
Zsh does not allow "$var" in arithmetic loops. Instead, pre-compute
the endpoint and use the variables without $'s or quotes.
shopt
Zsh uses 'setopt', which has a different syntax than 'shopt'. Since
'shopt' is used infrequently in git-completion, we provide
a bare-bones emulation.
emulate -L bash
KSH_TYPESET
Zsh offers bash emulation, which turns on a set of features to
closely resemble bash. In particular, this enables SH_WORDSPLIT,
which splits scalar variables on word boundaries in 'for' loops.
We also need to set KSH_TYPESET, to fix "local var=$(echo foo bar)"
issues.
The last set of options are turned on only in _git and _gitk. Some of
the sub-functions may not work correctly if called directly.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/cherry-revert-message-clean-up:
tests: fix syntax error in "Use advise() for hints" test
cherry-pick/revert: Use advise() for hints
cherry-pick/revert: Use error() for failure message
Introduce advise() to print hints
Eliminate “Finished cherry-pick/revert” message
t3508: add check_head_differs_from() helper function and use it
revert: improve success message by adding abbreviated commit sha1
revert: don't print "Finished one cherry-pick." if commit failed
revert: refactor commit code into a new run_git_commit() function
revert: report success when using option --strategy
* jn/svn-fe:
t/t9010-svn-fe.sh: add an +x bit to this test
t9010 (svn-fe): avoid symlinks in test
t9010 (svn-fe): use Unix-style path in URI
vcs-svn: Avoid %z in format string
vcs-svn: Rename dirent pool to build on Windows
compat: add strtok_r()
treap: style fix
vcs-svn: remove build artifacts on "make clean"
svn-fe manual: Clarify warning about deltas in dump files
Update svn-fe manual
SVN dump parser
Infrastructure to write revisions in fast-export format
Add stream helper library
Add string-specific memory pool
Add treap implementation
Add memory pool library
Introduce vcs-svn lib
Port v1.7.0-rc0~83^2 (Teach --[no-]rerere-autoupdate option to
merge, revert and friends, 2009-12-04) to the example merge script.
After this change, all tests pass for me with the scripted
merge.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.2-rc1~10^2 (Teach @{-1} to git merge, 2009-02-13) to
the old merge script.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a --no-ff merge with conflicts, "git commit" used to forget the
--no-ff when used to complete the merge. That was fixed by
v1.6.1-rc1~134^2 (builtin-commit: use reduce_heads() only when
appropriate, 2008-10-03) for the builtin merge. Port the change to
the merge script in contrib/examples.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.6-rc0~62^2 (Teach 'git merge' and 'git pull' the option
--ff-only, 2009-10-29) to the old merge script.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Based on v1.6.0-rc0~51^2~5 (Build in merge, 2008-07-07).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Based on v1.7.1.1~23^2 (merge: --log appends shortlog to message if
specified, 2010-05-11). Without this change, the scripted
(non-builtin) merge does not pass t7604.
Cc: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some git-merge-* commands are not merge strategies. This is based on
v1.6.1-rc1~294^2~7 (builtin-merge: allow using a custom strategy,
2008-07-30) but it is less smart: we just use a hard-coded list of
forbidden strategy names. It is okay if this falls out of date, since
the code is just an example.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The idea comes from v1.6.1-rc1~294^2~7 (builtin-merge: allow using a
custom strategy, 2008-07-30).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this support, the scripted merge cannot pass t6037.
Based on v1.7.0-rc0~55^2~5 (git merge -X<option>, 2009-11-25).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- point out remote-tracking branches as "remote branch
'upstream/master'";
- avoid misleading log messages when a tag and branch
share a name.
This approximates the builtin merge command's behavior well
enough to pass the relevant tests.
Based roughly on v1.6.4.2~10^2 (merge: indicate remote tracking
branches in merge message, 2009-08-09) and v1.6.4.2~10^2~1 (merge: fix
incorrect merge message for ambiguous tag/branch, 2009-08-09).
Cc: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check MERGE_HEAD and bail out if it exists. Based on v1.6.3.3~3^2
(refuse to merge during a merge, 2009-06-01). Without this change,
the scripted merge does not pass t3030.
Cc: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before:
You are in the middle of a conflicted merge.
After:
Merge is not possible because you have unmerged files.
I prefer the old message, but the new one is more consistent with
other commands and tests expect it. In particular, without this
change the scripted merge does not pass t3030.
Based on v1.7.0-rc0~66^2 (Be more user-friendly when refusing to do
something because of conflict., 2010-01-12).
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.1-rc1~319 (provide more errors for the "merge into empty
head" case, 2008-08-21) to the example merge script.
Noticed by comparison with builtin merge.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit”
was quiet, and the output from cherry-pick provided useful information
about the progress of a rebase.
Now next to the output from “git commit”, the cherry-pick notification
is so much noise (except for the name of the picked commit).
$ git cherry-pick ..topic
Finished cherry-pick of 499088b.
[detached HEAD 17e1ff2] Move glob module to libdpkg
Author: Guillem Jover <guillem@debian.org>
8 files changed, 12 insertions(+), 9 deletions(-)
rename {src => lib/dpkg}/glob.c (98%)
rename {src => lib/dpkg}/glob.h (93%)
Finished cherry-pick of ae947e1.
[detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script
Author: Guillem Jover <guillem@debian.org>
1 files changed, 2 insertions(+), 0 deletions(-)
$
The noise is especially troublesome when sifting through the output of
a rebase or multiple cherry-pick that eventually failed.
With the commit subject, it is already not hard to figure out where
the commit came from. So drop the “Finished” message.
Cc: Christian Couder <chriscool@tuxfamily.org>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Those in the know would notice that dump file format version 2
means "svnadmin dump --no-deltas", but for the rest of us, an
explicit reminder is useful.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The svn-fe example does not litter the working directory with
.bin files any more (hoorah!).
The permissive error handling implies a known bug. We should
be flagging iffy input and, even if we continue, reporting it
on exit.
Cc: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
svndump parses data that is in SVN dumpfile format produced by
`svnadmin dump` with the help of line_buffer and uses repo_tree and
fast_export to emit a git fast-import stream.
Based roughly on com.hydrografix.svndump 0.92 from the SvnToCCase
project at <http://svn2cc.sarovar.org/>, by Stefan Hegny and
others.
[rr: allow input from files other than stdin]
[jn: with test, more error reporting]
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Provide a 'list' command to view available bare repositories ending in
.git and a 'help command to display usage. Also add documentation in
a README
Signed-off-by: Greg Brockman <gdb@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous form produced subjects like
[SCM] project.git branch, foo, updated. ...
The new one will produce the lighter
[SCM] project.git branch foo updated. ...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Include the path "../../vcs-svn" while compiling it in the Makefile
and change svn-fe.c to include svndump.h.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After v1.7.1.1~17^2~3 (pretty: Respect --abbrev option, 2010-05-03),
plumbing users do not abbreviate %h hashes by default any more.
Noticed while investigating the bug fixed by v1.7.1.1~17^2
(commit::print_summary(): don't use format_commit_message(),
2010-06-12).
Cc: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have become used to the features of svnmailer when used with Subversion,
and one of those useful features is that it can limit the maximum length
(in lines) of a commit email message. This is terribly useful since once the
goes beyond a reasonable number of lines, nobody is going to read the remainder,
and if they really want the entire contents of the commits, they can use
git itself to get them using the revision IDs present in the message already.
Change the post-receive-email script to respond to an 'emailmaxlines' config key
which, if specified, will limit the number of lines generated (including
headers); any lines beyond the limit are suppressed, and a final line is added
indicating the number that were suppressed.
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The svn-fe tool takes a Subversion dump file as input and produces
a fast-import stream as output. This can be useful as a low-level
tool in building other importers, or for debugging the vcs-svn
library.
make svn-fe
make svn-fe.1
to test.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a notification in the command prompt specifying whether (and optionally how
far) your branch has diverged from its upstream. This is especially helpful in
small teams that very frequently (forget to) push to each other.
Support git-svn upstream detection as a special case, as migrators from
centralised version control systems are especially likely to forget to push.
Support for other types of upstream than SVN should be easy to add if anyone is
so inclined.
Signed-off-by: Andrew Sayers <andrew-git@pileofstuff.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Define several variables in __git_ps1 to avoid errors under "set -u" semantics.
__git_ps1 seems to have been missed when the rest of the file was fixed in
25a31f8.
Signed-off-by: Andrew Sayers <andrew-git@pileofstuff.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update git-completion.bash with new --orphan option to 'git checkout'.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Makefile: reenable install with NO_CURL
completion: --set-upstream option for git-branch
get_cwd_relative(): do not misinterpret suffix as subdirectory
* jn/request-pull:
tests: chmod +x t5150
adapt request-pull tests for new pull request format
t5150: protect backslash with backslash in shell
request-pull: protect against OPTIONS_KEEPDASHDASH from environment
tests for request-pull
According to the default hooks/post-receive file, the hook is called
with three arguments on stdin:
<oldrev> <newrev> <refname>
In command-line mode, the arguments come in a different order, because
the email hook instead calls:
generate_email $2 $3 $1
Add a comment to explain why, based on comments from the mailing list
and the commit message to v1.5.1~9. Thanks to Andy for the
explanation.
Requested-by: martin f. krafft <madduck@debian.org>
Cc: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like most git commands, request-pull supports a -- delimiter to allow
callers to pass arguments that would otherwise be treated as an option
afterwards. The internal OPTIONS_KEEPDASHDASH variable is passed
empty to git-sh-setup to indicate that request-pull itself does not
care about the position of the -- delimiter. But if the user has
that variable in her environment, request-pull will see the “--” and
fail.
Empty it explicitly to guard against this. While at it, make the
corresponding fix to git-resurrect, too (all other scripts in git.git
already protect themselves).
Acked-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the "tagopt = --tags" option of a remote is set, all tags
will be fetched as in "git fetch --tags".
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These have been extensively live-tested in the last week. The version 2
ciabot.sh maintainer has passed the baton to me; ciabot.py is original.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On FreeBSD, Python does not ship as part of the base system but is available
via the ports system, which install the binary in /usr/local/bin.
Signed-off-by: R. Tyler Ballance <tyler@monkeypox.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already complete HEAD, of course, and might as well complete the other
common refs mentioned in the rev-parse man page: FETCH_HEAD, ORIG_HEAD, and
MERGE_HEAD.
Signed-off-by: Ian Ward Comfort <icomfort@stanford.edu>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/notes: (33 commits)
Documentation: fix a few typos in git-notes.txt
notes: fix malformed tree entry
builtin-notes: Minor (mostly parse_options-related) fixes
builtin-notes: Add "copy" subcommand for copying notes between objects
builtin-notes: Misc. refactoring of argc and exit value handling
builtin-notes: Add -c/-C options for reusing notes
builtin-notes: Refactor handling of -F option to allow combining -m and -F
builtin-notes: Deprecate the -m/-F options for "git notes edit"
builtin-notes: Add "append" subcommand for appending to note objects
builtin-notes: Add "add" subcommand for adding notes to objects
builtin-notes: Add --message/--file aliases for -m/-F options
builtin-notes: Add "list" subcommand for listing note objects
Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
builtin-notes: Add "prune" subcommand for removing notes for missing objects
Notes API: prune_notes(): Prune notes that belong to non-existing objects
t3305: Verify that removing notes triggers automatic fanout consolidation
builtin-notes: Add "remove" subcommand for removing existing notes
Teach builtin-notes to remove empty notes
Teach notes code to properly preserve non-notes in the notes tree
t3305: Verify that adding many notes with git-notes triggers increased fanout
...
Conflicts:
Makefile
gitk aliases either start with "!gitk", or look something like "!sh -c
FOO=bar gitk", IOW they contain the "gitk" word. With this patch the
completion script will recognize these cases and will offer gitk's
options.
Just like the earlier change improving on aliased command recognition,
this change can also be fooled easily by some complex aliases, but
users of such aliases could remedy it with custom completion
functions.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix inadvertent breakage from b932705 (git-p4: stream from perforce to
speed up clones, 2009-07-30) in the code that strips the trailing '\n'
from p4 print on a symlink. (In practice, contents is of the form
['target\n', ''].)
Signed-off-by: Evan Powers <evan.powers@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The builtin-ification includes some minor behavioural changes to the
command-line interface: It is no longer allowed to mix the -m and -F
arguments, and it is not allowed to use multiple -F options.
As part of the builtin-ification, we add the commit_notes() function
to the builtin API. This function (together with the notes.h API) can
be easily used from other builtins to manipulate the notes tree.
Also includes needed changes to t3301.
This patch has been improved by the following contributions:
- Stephen Boyd: Use die() instead of fprintf(stderr, ...) followed by exit(1)
Cc: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix sync errors due to new Perforce servers.
The P4D/NTX64/2009.2/228098 (2009/12/16) server reports
'move/delete' instead of 'delete'. This causes the Perforce
depot and the git repo to get out of sync. Fixed by adding
the new status string.
Signed-off-by: Pal-Kristian Engstad <pal_engstad@naughtydog.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... and it will offer refs unless after -m or -F, because these two
options require a non-ref argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commits a2d725b7 (Use an external program to implement fetching
with curl, 2009-08-05) and c9e388bb (Make the
"traditionally-supported" URLs a special case, 2009-09-03) remote
transport helpers like 'remote-ftp' and 'remote-curl' are offered by the
completion script as available subcommands. Not good, since they are
helpers, therefore should not be offered, so filter them out.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Having recently added support for building git-imap-send on
Windows, we now link against OpenSSL libraries, and the linker
issues the following warning:
warning LNK4044: unrecognized option '/lssl'; ignored
In order to suppress the warning, we change the msvc linker
script to translate an '-lssl' parameter to the ssleay32.lib
library.
Note that the linker script was already including ssleay32.lib
(along with libeay32.lib) as part of the translation of the
'-lcrypto' library parameter. However, libeay32.dll does not
depend on ssleay32.dll and can be used stand-alone, so we remove
ssleay32.lib from the '-lcrypto' translation.
The dependence of ssleay32.dll on libeay32.dll is represented in
the Makefile by the NEEDS_CRYPTO_WITH_SSL build variable.
Also, add the corresponding change to the buildsystem generator.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ade2ca0c (Do not try to remove directories when removing
old links, 2009-10-27) added an expression to a 'test' using an
'-o' or connective. This resulted in the buildsystem generator
mistaking a conditional 'rm' for a linker command. In order to
fix the breakage, we filter out all 'test' commands before then
attempting to identify the commands of interest.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The strip() is required to remove the trailing newline character,
as already done elsewhere.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ap/merge-backend-opts:
Document that merge strategies can now take their own options
Extend merge-subtree tests to test -Xsubtree=dir.
Make "subtree" part more orthogonal to the rest of merge-recursive.
pull: Fix parsing of -X<option>
Teach git-pull to pass -X<option> to git-merge
git merge -X<option>
git-merge-file --ours, --theirs
Conflicts:
git-compat-util.h
* maint-1.6.5:
Git 1.6.5.8
Fix mis-backport of t7002
bash completion: factor submodules into dirty state
reset: unbreak hard resets with GIT_WORK_TREE
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
Teach "-X <option>" command line argument to "git merge" that is passed to
strategy implementations. "ours" and "theirs" autoresolution introduced
by the previous commit can be asked to the recursive strategy.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script passes the author and committer to git-commit via environment
variables, but it was missing the seccond T of COMMITTER in a few places.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
Acked-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the implementation of GIT_PS1_SHOWDIRTYSTATE in 738a94a (bash:
offer to show (un)staged changes, 2009-02-03), I cut&pasted the
git-diff invocations from dirty-worktree checks elsewhere, carrying
along the --ignore-submodules option.
As pointed out by Kevin Ballard, this doesn't really make sense: to
the _user_, a changed submodule counts towards uncommitted changes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the readability of the bash prompt by adding a space between
the branch name and the status flags (dirty, stash, untracked).
While we are cleaning up this section of code, the two cases for
formatting the prompt are identical except for the format string,
so make them the same.
Suggested-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the new options --all, --prune, and --dry-run for
'git fetch'.
As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I just wanted to add the recently learnt '--reset-author' option, but
then noticed that there are many more options missing. This patch
adds support for all of 'git commit's options, except '--allow-empty',
because it is primarily there for foreign scm interfaces.
Furthermore, this patch also adds support for completing the arguments
of those options that take a non-filename argument: valid modes are
offered for '--cleanup' and '--untracked-files', while refs for
'--reuse-message' and '--reedit-message', because these two take a
commit as argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/editor-pager:
Provide a build time default-pager setting
Provide a build time default-editor setting
am -i, git-svn: use "git var GIT_PAGER"
add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
Teach git var about GIT_PAGER
Teach git var about GIT_EDITOR
Suppress warnings from "git var -l"
Do not use VISUAL editor on dumb terminals
Handle more shell metacharacters in editor names
* jn/help-everywhere: (23 commits)
diff --no-index: make the usage string less scary
merge-{recursive,subtree}: use usagef() to print usage
Introduce usagef() that takes a printf-style format
Let 'git <command> -h' show usage without a git dir
Show usage string for 'git http-push -h'
Let 'git http-fetch -h' show usage outside any git repository
Show usage string for 'git stripspace -h'
Show usage string for 'git unpack-file -h'
Show usage string for 'git show-index -h'
Show usage string for 'git rev-parse -h'
Show usage string for 'git merge-one-file -h'
Show usage string for 'git mailsplit -h'
Show usage string for 'git imap-send -h'
Show usage string for 'git get-tar-commit-id -h'
Show usage string for 'git fast-import -h'
Show usage string for 'git check-ref-format -h'
http-fetch: add missing initialization of argv0_path
Show usage string for 'git show-ref -h'
Show usage string for 'git merge-ours -h'
Show usage string for 'git commit-tree -h'
...
Conflicts:
imap-send.c
* ef/msys-imap:
Windows: use BLK_SHA1 again
MSVC: Enable OpenSSL, and translate -lcrypto
mingw: enable OpenSSL
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
imap-send: build imap-send on Windows
imap-send: fix compilation-error on Windows
imap-send: use run-command API for tunneling
imap-send: use separate read and write fds
imap-send: remove useless uid code
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
On this slow laptop, this decreases the time to load
git-completion.bash from about 500 ms to about 175 ms.
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: SZEDER Gábor <szeder@ira.uka.de>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-fetch was builtin-ized, the previous script was moved to
contrib/examples. Now, it is the sole remaining user for
'git fetch--tool'.
The fetch--tool code is still worth keeping around so people can
try out the old git-fetch.sh, for example when investigating
regressions from the builtinifaction.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of having all PDB files for all projects named "vc90.pdb", name them
after the respective project to make the relation more clear (and to avoid name
clashes when copying files around).
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add p4merge to the set of built-in diff/merge tools, and update
bash completion and documentation.
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
