We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* jc/combine-diff-many-parents:
t4038: add tests for "diff --cc --raw <trees>"
combine-diff: lift 32-way limit of combined diff
The "complete with known paths only" update to completion scripts
returns directory names without trailing slash to compensate the
addition of '/' done by bash that reads from our completion result.
tcsh completion code that reads from our internal completion result
does not add '/', so let it ask our complletion code to keep the '/'
at the end.
* mk/tcsh-complete-only-known-paths:
completion: handle path completion and colon for tcsh script
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
* mp/complete-paths:
git-completion.bash: add support for path completion
According to the glossary, "reset" should be
translated as "neu setzen" but in a couple of
messages we've translated it as "zurücksetzen".
This fixes that.
l10n: de.po: translate "revision" consistently as "Revision"
In the current German translation, the word "revision" was
translated as both "Version" (translation of "commit") and
"Revision". Since a revision in Git is not necessarily a
commit, we should not translate it with the same word in
order to give the user an idea that it's not necessarily
the same. After this commit, "revision" is consistently
translated as "Revision".
Merge branch 'jc/fake-ancestor-with-non-blobs' into maint
Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* jc/fake-ancestor-with-non-blobs:
apply: diagnose incomplete submodule object name better
apply: simplify build_fake_ancestor()
git-am: record full index line in the patch used while rebasing
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
* da/mergetool-docs:
doc: generate a list of valid merge tools
mergetool--lib: list user configured tools in '--tool-help'
mergetool--lib: add functions for finding available tools
mergetool--lib: improve the help text in guess_merge_tool()
mergetool--lib: simplify command expressions
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
* nd/branch-error-cases:
branch: let branch filters imply --list
docs: clarify git-branch --list behavior
branch: mark more strings for translation
branch: give a more helpful message on redundant arguments
branch: reject -D/-d without branch name
An age-old workaround to prevent buggy versions of ccache from
breaking the auto-generation of dependencies, which unfortunately
is still relevant because some people use ancient distros.
* jn/auto-depend-workaround-buggy-ccache:
Makefile: explicitly set target name for autogenerated dependencies
Update documentation to change "GIT" which was a poor-man's small
caps to "Git". The latter was the intended spelling.
Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.
* ta/doc-no-small-caps:
Documentation: StGit is the right spelling, not StGIT
Documentation: describe the "repository" in repository-layout
Documentation: add a description for 'gitfile' to glossary
Documentation: do not use undefined terms git-dir and git-file
Documentation: the name of the system is 'Git', not 'git'
Documentation: avoid poor-man's small caps GIT
Rebasing the history of superproject with change in the submodule
was broken since v1.7.12.
* jc/fake-ancestor-with-non-blobs:
apply: diagnose incomplete submodule object name better
apply: simplify build_fake_ancestor()
git-am: record full index line in the patch used while rebasing
Prepare remote-helper test written in Python to be run with Python3.
* jk/remote-helpers-in-python-3:
git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
git-remote-testpy: fix path hashing on Python 3
git-remote-testpy: call print as a function
git-remote-testpy: don't do unbuffered text I/O
git-remote-testpy: hash bytes explicitly
svn-fe: allow svnrdump_sim.py to run with Python 3
git_remote_helpers: use 2to3 if building with Python 3
git_remote_helpers: force rebuild if python version changes
git_remote_helpers: fix input when running under Python 3
git_remote_helpers: allow building with Python 3
* pw/git-p4-on-cygwin: (21 commits)
git p4: introduce gitConfigBool
git p4: avoid shell when calling git config
git p4: avoid shell when invoking git config --get-all
git p4: avoid shell when invoking git rev-list
git p4: avoid shell when mapping users
git p4: disable read-only attribute before deleting
git p4 test: use test_chmod for cygwin
git p4: cygwin p4 client does not mark read-only
git p4 test: avoid wildcard * in windows
git p4 test: use LineEnd unix in windows tests too
git p4 test: newline handling
git p4: scrub crlf for utf16 files on windows
git p4: remove unreachable windows \r\n conversion code
git p4 test: translate windows paths for cygwin
git p4 test: start p4d inside its db dir
git p4 test: use client_view in t9806
git p4 test: avoid loop in client_view
git p4 test: use client_view to build the initial client
git p4: generate better error message for bad depot path
git p4: remove unused imports
...
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
* mm/add-u-A-sans-pathspec:
add: warn when -u or -A is used without pathspec
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
* jc/push-reject-reasons:
push: finishing touches to explain REJECT_ALREADY_EXISTS better
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
push: further simplify the logic to assign rejection reason
push: further clean up fields of "struct ref"
Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.
* jk/config-parsing-cleanup:
reflog: use parse_config_key in config callback
help: use parse_config_key for man config
submodule: simplify memory handling in config parsing
submodule: use parse_config_key when parsing config
userdiff: drop parse_driver function
convert some config callbacks to parse_config_key
archive-tar: use parse_config_key when parsing config
config: add helper function for parsing key names
* jc/merge-blobs:
Makefile: Replace merge-file.h with merge-blobs.h in LIB_H
merge-tree: fix d/f conflicts
merge-tree: add comments to clarify what these functions are doing
merge-tree: lose unused "resolve_directories"
merge-tree: lose unused "flags" from merge_list
Which merge_file() function do you mean?
completion: handle path completion and colon for tcsh script
Recent enhancements to git-completion.bash provide intelligent path
completion for git commands. Such completions do not provide the
'/' at the end of directories for recent versions of bash; instead,
bash itself will add the trailing slash to directories to the result
provided by git-completion.bash. However, the completion for tcsh
uses the result of the bash completion script directly, so it either
needs to add the necessary slash itself, or needs to ask the bash
script to keep the trailing slash.
Adding the slash itself is difficult because we have to check the
each path in the output of the bash script to see if it is meant to
be a directory or something else. For example, assuming there is a
directory named 'commit' in the current directory, then, when
completing
git add commit<tab>
we would need to add a slash, but for
git help commit<tab>
we should not.
Figuring out such differences would require adding much intelligence
to the tcsh completion script. Instead, it is simpler to ask the
bash script to keep the trailing slash. This patch does this.
Also, tcsh does not handle the colon as a completion separator so we
remove it from the list of separators.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
builtin/apply: tighten (dis)similarity index parsing
This was prompted by an incorrect warning issued by clang [1], and a
suggestion by Linus to restrict the range to check for values greater
than INT_MAX since these will give bogus output after casting to int.
In fact the (dis)similarity index is a percentage, so reject values
greater than 100.
The "raw" format of combine-diff output is supposed to have as many
colons as there are parents at the beginning, then blob modes for
these parents, and then object names for these parents.
We weren't however prepared to handle a more than 32-way merge and
did not show the correct number of colons in such a case.
Use the show_tool_names() function to build lists of all
the built-in tools supported by difftool and mergetool.
This frees us from needing to update the documentation
whenever a new tool is added.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: explicitly set target name for autogenerated dependencies
"gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile
snippet named "depfile" describing what files are needed to build the
target given by "-o". When ccache versions before v3.0pre0~187 (Fix
handling of the -MD and -MDD options, 2009-11-01) run, they execute
gcc -MF depfile -MMD -MP -E
instead to get the final content for hashing. Notice that the "-c -o"
combination is replaced by "-E". The result is a target name without
a leading path.
Thus when building git with such versions of ccache with
COMPUTE_HEADER_DEPENDENCIES enabled, the generated makefile snippets
define dependencies for the wrong target:
$ make builtin/add.o
GIT_VERSION = 1.7.8.rc3
* new build flags or prefix
CC builtin/add.o
$ head -1 builtin/.depend/add.o.d
add.o: builtin/add.c cache.h git-compat-util.h compat/bswap.h strbuf.h \
After a change in a header file, object files in a subdirectory are
not automatically rebuilt by "make":
$ touch cache.h
$ make builtin/add.o
$
Luckily we can prevent trouble by explicitly supplying the name of the
target to ccache and gcc, using the -MQ option. Do so.
Reported-and-tested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reported-by: : 허종만 <jongman.heo@samsung.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
mergetools: teach tortoisemerge to handle filenames with SP correctly
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused the whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
Signed-off-by: Sven Strickroth <email@cs-ware.de> Reported-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When looking up a topic via "git help <topic>", git-help prepends "git-"
to topics that are the names of commands (either builtin or found on the
path) and "git" (no hyphen) to any other topic name.
"git-remote-helpers" is not the name of a command, so "git help
remote-helpers" looks for "gitremote-helpers" and does not find it.
Fix this by renaming "git-remote-helpers.txt" to
"gitremote-helpers.txt".
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps. Later we stopped doing so at around 1.6.5 days.
Let's stop doing so throughout the documentation. The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git". And document this in the coding
guideline.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
* jn/do-not-drop-username-when-reading-from-etc-mailname:
ident: do not drop username when reading from /etc/mailname
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* jc/no-git-config-in-clone:
clone: do not export and unexport GIT_CONFIG
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
* nd/fetch-depth-is-broken:
fetch: elaborate --depth action
upload-pack: fix off-by-one depth calculation in shallow clone
fetch: add --unshallow for turning shallow repo into complete one
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: diagnose incomplete submodule object name better
"git am -3" uses this function to build a tree that records how the
preimage the patch was created from would have looked like. An
abbreviated object name on the index line is ordinarily sufficient
for us to figure out the object name the preimage tree would have
contained, but a change to a submodule by definition shows an object
name of a submodule commit which our repository should not have, and
get_sha1_blob() is not an appropriate way to read it (or get_sha1()
for that matter).
Use get_sha1_hex() and complain if we do not find a full object name
there.
We could read from the payload part of the patch to learn the full
object name of the commit, but the primary user "git rebase" has
been fixed to give us a full object name, so this should suffice
for now.
The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor, 2007-09-17) made the "missing in the
ancestor" case unnecessary, hence sha1_ptr, when used, always points
at the local array.
Get rid of the unneeded variable, and restructure the if/else
cascade a bit to make it easier to read. There should be no
behaviour change.
git-am: record full index line in the patch used while rebasing
Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end. While doing so, it used "git diff-tree" but without
giving it the "--full-index" option.
This does not matter for in-repository objects; during rebasing, any
abbreviated object name should uniquely identify them.
But we may be rebasing a commit that contains a change to a gitlink,
in which case we usually should not have the object (it names a
commit in the submodule). A full object name is necessary to later
reconstruct a fake ancestor index for them.
Currently, a branch filter like `--contains`, `--merged`, or
`--no-merged` is ignored when we are not in listing mode.
For example:
git branch --contains=foo bar
will create the branch "bar" from the current HEAD, ignoring
the `--contains` argument entirely. This is not very
helpful. There are two reasonable behaviors for git here:
1. Flag an error; the arguments do not make sense.
2. Implicitly go into `--list` mode
This patch chooses the latter, as it is more convenient, and
there should not be any ambiguity with attempting to create
a branch; using `--contains` and not wanting to list is
nonsensical.
That leaves the case where an explicit modification option
like `-d` is given. We already catch the case where
`--list` is given alongside `-d` and flag an error. With
this patch, we will also catch the use of `--contains` and
other filter options alongside `-d`.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was not clear from the "description" section of git-branch(1)
that using a <pattern> meant that you _had_ to use the --list
option. Let's clarify that, and while we're at it, reword some
clunky and ambiguous sentences.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gpg: close stderr once finished with it in verify_signed_buffer()
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges | grep "key"
on the linux kernel git repo. Eventually it will fail with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
After a push of a branch other than the current branch fails in
a no-ff error and if you are still on an unborn branch, the code
recently added to report the failure dereferenced a null pointer
while checking the name of the current branch.
Signed-off-by: Fraser Tweedale <frase@frase.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]), although Brandon Casey recently added
support for 2.4 and 2.5 to git-p4 [3].
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [5].
- Python 3.1 is required to support the 'surrogateescape' error handler
for encoding/decodng filenames to/from Unicode strings and Python 3.0
is not longer supported.
git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20)
started using a marker file to keep track of the version of Python interpreter
used for the last build, but forgot to remove it when asked to "make clean".
Acked-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>