"git rebase [-i] --root $tip" can now be used to rewrite all the
history down to the root.
* cw/rebase-i-root:
t3404: make test 57 work with dash and others
Add tests for rebase -i --root without --onto
rebase -i: support --root without --onto
Teach "git p4" to notice "Jobs:" in the log message and relay it to
Perforce to trigger its "jobs" support.
# By Pete Wyckoff
* pw/git-p4-jobs:
git p4: notice Jobs lines in git commit messages
git p4 test: refactor marshal_dump
git p4: remove unused P4Submit interactive setting
Due to the way "git diff --no-index" is bolted onto by touching the
low level code that is shared with the rest of the "git diff" code,
even though it has to work in a very different way, any comparison
that involves a file "-" at the root level incorrectly tried to read
from the standard input. This cleans up the no-index codepath
further to remove code that reads from the standard input from the
core side, which is never necessary when git is running its usual
diff operation.
* jc/refactor-diff-stdin:
diff-index.c: "git diff" has no need to read blob from the standard input
diff-index.c: unify handling of command line paths
diff-index.c: do not pretend paths are pathspecs
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.
I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.
* tb/sanitize-decomposed-utf-8-pathname:
git on Mac OS and precomposed unicode
Fixes "git show"'s auto-walking behaviour, and make it behave just
like "git log" does when it walks.
* tr/maint-show-walk:
show: fix "range implies walking"
Demonstrate git-show is broken with ranges
Teach "am --rebasing" codepath to grab authorship, log message and
the patch text directly out of existing commits. This will help
rebasing commits that have confusing "diff" output in their log
messages.
* mz/rebase-no-mbox:
am: don't call mailinfo if $rebasing
am --rebasing: get patch body from commit, not from mailbox
rebase --root: print usage on too many args
rebase: don't source git-sh-setup twice
The test creates 16 objects that share the same prefix, and two other
objects that do not. Tweak the test so that the other two share the
same prefix that is different from the one that is shared by the 16.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For -M option (detectRenames) in P4Submit, use 'p4 move' rather
than 'p4 integrate'. Check Perforce server for exisitence of
'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
[pw: wildcard-encode src/dest, add/update tests, tweak code]
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>
Running filter-branch on a history that has a commit with timestamp
at epoch used to fail, but it should have been fixed. Add test to
make sure it won't break again.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 69c3051 (submodules: refactor computation of relative gitdir path)
cloning a submodule recursively fails for nested submodules when a
symbolic link is part of the path to the work tree of the superproject.
This happens when module_clone() tries to find the relative paths between
the work tree and the git dir. When a symbolic link in current $PWD points
to a directory that is at a different level, then determining the number
of "../" needed to traverse to the superproject's work tree leads to a
wrong result.
As there is no portable way to say "pwd -P", use cd_to_toplevel to remove
the link from $PWD, which fixes this problem.
A test for this issue has been added to t7406.
Reported-by: Bob Halley <halley@play-bow.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some implementations of sed (e.g. MacOS X) have whitespaces in the
output of "wc -l" that reads from the standard input. Ignore these
whitespaces by not quoting the command substitution to be compared
with the constant "16".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command fragments are quoted nowhere else in title texts of
this file, thus make this one consistent with all other titles.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This quoting style is used by all newly added test code.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --no-index" did not correctly handle relative paths and
did not correctly give exit codes when run under "--quiet" option.
* th/diff-no-index-fixes:
diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes
diff: handle relative paths in no-index
"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.
* nd/clone-single-fix:
clone: fix ref selection in --single-branch --branch=xxx
"git diff COPYING HEAD:COPYING" gave a nonsense error message that
claimed that the treeish HEAD did not have COPYING in it.
* mm/verify-filename-fix:
verify_filename(): ask the caller to chose the kind of diagnosis
sha1_name: do not trigger detailed diagnosis for file arguments
We failed to use ce_namelen() equivalent and instead only compared
up to the CE_NAMEMASK bytes by mistake. Adding an overlong path
that shares the same common prefix as an existing entry in the index
did not add a new entry, but instead replaced the existing one, as
the result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we do not have any pathspec, we typically disallow an
explicit "--only", because it makes no sense (your commit
would, by definition, be empty). But since 6a74642
(git-commit --amend: two fixes., 2006-04-20), we have
allowed "--amend --only" with the intent that it would amend
the commit, ignoring any contents staged in the index.
However, while that commit allowed the combination, we never
actually implemented the logic to make it work. The current
code notices that we have no pathspec and assumes we want to
do an as-is commit (i.e., the "--only" is ignored).
Instead, we must make sure to follow the partial-commit
code-path. We also need to tweak the list_paths function to
handle a NULL pathspec.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option allows you to feed an ambiguous prefix and enumerate
all the objects that share it as a prefix of their object names.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is not strictly correct, in that resetting selected index
entries from corresponding paths out of a given tree without moving
HEAD is a valid operation, and in such case a tree-ish would suffice.
But the existing code already requires a committish in the codepath,
so let's be consistent with it for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "index" line read from the patch to reconstruct a partial
preimage tree records the object names of blob objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the revision parser that in "$name:$path" (used for a
blob object name), "$name" must be a tree-ish.
There are many more places where we know what types of objects are
called for. This patch adds support for "commit", "treeish", "tree",
and "blob", which could be used in the following contexts:
- "git apply --build-fake-ancestor" reads the "index" lines from
the patch; they must name blob objects (not even "blob-ish");
- "git commit-tree" reads a tree object name (not "tree-ish"), and
zero or more commit object names (not "committish");
- "git reset $rev" wants a committish; "git reset $rev -- $path"
wants a treeish.
They will come in later patches in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a field to setup_revision_opt structure and allow these callers
to tell the setup_revisions command parsing machinery that short SHA1
it encounters are meant to name committish.
This step does not go all the way to connect the setup_revisions()
to sha1_name.c yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many callers know that the user meant to name a committish by
syntactical positions where the object name appears. Calling this
function allows the machinery to disambiguate shorter-than-unique
abbreviated object names between committish and others.
Note that this does NOT error out when the named object is not a
committish. It is merely to give a hint to the disambiguation
machinery.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We know that the token "$name" that appear in "$name^{commit}",
"$name^4", "$name~4" etc. can only name a committish (either a
commit or a tag that peels to a commit). Teach get_short_sha1() to
take advantage of that knowledge when disambiguating an abbreviated
SHA-1 given as an object name.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach get_describe_name() to pass the disambiguation hint down the
callchain to get_short_sha1().
Also add tests to show various syntactic elements that we could take
advantage of the object type information to help disambiguration of
abbreviated object names. Many of them are marked as broken, and
some of them will be fixed in later patches in this series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we have all the necessary logic to fall back on three-way merge when
the patch does not cleanly apply, insert the conflicted entries to the
index as appropriate. This obviously triggers only when the "--index"
option is used.
When we fall back to three-way merge and some of the merges fail, just
like the case where the "--reject" option was specified and we had to
write some "*.rej" files out for unapplicable patches, exit the command
with non-zero status without showing the diffstat and summary. Otherwise
they would make the list of problematic paths scroll off the display.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Begin teaching the three-way merge fallback logic "git am -3" uses
to the underlying "git apply". It only implements the command line
parsing part, and does not do anything interesting yet, other than
making sure that "--reject" and "--3way" are not given together, and
making "--3way" imply "--index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit --amend" used on a commit with an empty message fails
unless -m is given, whether or not --allow-empty-message is
specified.
Allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later
if an empty message is saved from the editor (this check was
already necessary to prevent a non-empty commit message being edited
to an empty one).
Add a test for --amend --edit of an empty commit message which fails
without this fix, as it's a rare case that won't get frequently
tested otherwise.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We did not have test to make sure "git rebase" without extra options
filters out an empty commit in the original history.
* mz/empty-rebase-test:
add test case for rebase of empty commit
More "git p4" tests.
* pw/git-p4-tests:
git p4 test: fix badp4dir test
git p4 test: split up big t9800 test
git p4 test: cleanup_git should make a new $git
git p4 test: copy source indeterminate
git p4 test: check for error message in failed test
git p4 test: rename some "git-p4 command" strings
git p4 test: never create default test repo
git p4 test: simplify quoting involving TRASH_DIRECTORY
git p4 test: use real_path to resolve p4 client symlinks
git p4 test: wait longer for p4d to start and test its pid
"git fast-export" produced an input stream for fast-import without
properly quoting pathnames when they contain SPs in them.
* js/fast-export-paths-with-spaces:
fast-export: quote paths with spaces
"git checkout --detach", when you are still on an unborn branch,
should be forbidden, but it wasn't.
* cw/no-detaching-an-unborn:
git-checkout: disallow --detach on unborn branch
Some implementations of Perl terminates "lines" with CRLF even when
the script is operating on just a sequence of bytes. Make sure to
use "$PERL_PATH", the version of Perl the user told Git to use, in
our tests to avoid unnecessary breakages in tests.
* vr/use-our-perl-in-tests:
t/README: add a bit more Don'ts
tests: enclose $PERL_PATH in double quotes
t/test-lib.sh: export PERL_PATH for use in scripts
t: Replace 'perl' by $PERL_PATH
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
Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow
the user to avoid cluttering $HOME.
* mm/config-xdg:
config: write to $XDG_CONFIG_HOME/git/config file when appropriate
Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes
Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore
config: read (but not write) from $XDG_CONFIG_HOME/git/config file
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
P4 has a feature called "jobs" that allows linking changes
to a bug tracking system or other tasks. When submitting
code, a job name can be specified to mark that this change
is associated with a particular job.
Teach git-p4 to find an optional "Jobs:" line in git commit
messages and use them to make a Jobs section in the p4
change specifitation.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function will be useful in future tests. Move it to
the git-p4 test library. Let it accept an optional argument
to pick a certain marshaled object out of the input stream.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The construct
VAR=value test_must_fail command args
works only for some shells (such as bash) but not others (such as dash)
because VAR=value does not end up in the environment for command when it
is called by the shell function test_must_fail. That is why we explicitly
set and export variable in a subshell, i.e.
(
VAR=value &&
export VAR &&
test_must_fail command args
)
in most places already, bar the newly introduced 57 from b64b7fe
(Add tests for rebase -i --root without --onto, 2012-06-26).
Make test 57 use that construct also.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.
* nd/clone-single-fix:
clone: fix ref selection in --single-branch --branch=xxx
"git diff --no-index" did not correctly handle relative paths and
did not give correct exit codes when run under "--quiet" option.
* th/diff-no-index-fixes:
diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes
diff: handle relative paths in no-index
When we get disconnected while expecting a response from the remote
side because authentication failed, we issued an error message "The
remote side hung up unexpectedly."
Give hint that it may be a permission problem in the message when we
can reasonably suspect it.
* hv/remote-end-hung-up:
remove the impression of unexpectedness when access is denied
Only "diff --no-index -" does. Bolting the logic into the low-level
function diff_populate_filespec() was a layering violation from day
one. Move populate_from_stdin() function out of the generic diff.c
to its only user, diff-index.c.
Also make sure "-" from the command line stays a special token "read
from the standard input", even if we later decide to sanitize the
result from prefix_filename() function in a few obvious ways,
e.g. removing unnecessary "./" prefix, duplicated slashes "//" in
the middle, etc.
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.
Teach "git submodule" deal with nested submodule structure where a
module is contained within a module whose origin is specified as a
relative URL to its superproject's origin.
The construct used to get the return code was flawed, in that
errors in the &&-chain before the semicolon were not caught. Use
the standard test_expect_code instead.
Set PATH in a subshell instead of relying on the bashism of
setting it just for a single command.
And fix the grep line so it doesn't worry about grep segfaults,
and doesn't fail for i18n issues.
Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original t9800 test code has a mix of assorted topics, some
of which are big enough to deserve their own homes.
Interdependencies between the topics make it confusing when
trying to study one in isolation. And it takes so long to run
that debugging an individual test is difficult.
Split out three big chunks of tests into their own files:
t9812-git-p4-wildcards.sh gets the 8 p4 wildcard tests
t9813-git-p4-preserve-users.sh gets the 4 --preserve-user tests
t9814-git-p4-rename.sh gets the 2 copy and rename tests
Test 9800 execution time drops from 29 sec to 9 sec. The
sequential time to run all tests is a slower due to the three
extra p4d startup/shutdown sequences, but the overall parallel
execution time is about the same, at 52 sec.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For convenience, leave one in place at the end of each
test so that it is not necessary to build a new one. This
makes it consistent with $cli.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Msysgit testing showed that the source file found by copy
detection is indeterminate when there are multiple sources
to choose from. This appears to be valid. Adjust the test
so that it passes if it finds any of the potential copy sources.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For temporary files that are created in the top-level TRASH_DIRECTORY,
trust that the tests do not chdir except in subshells, and avoid some
quoting.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The p4 program is finicky about making sure the recorded client Root
matches the current working directory. The way it discovers the latter
seems to be to inspect shell variable $PWD. This could involve symlinks,
that while leading to the same place as the client Root, look different,
and cause p4 to fail.
Resolve all client paths using "test-path-utils real_path $path". This
removes ".." and resolves all symlinks.
Discovered while running with --root=/dev/shm, which is a link to
/run/shm.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running tests at high parallelism on a slow machine, 5 sec is
not enough to wait for p4d to start. Change it to 5 minutes,
adding an environment variable P4D_START_PATIENCE to shrink
that if needed in automated test environments.
Also check if the pid of the p4d that we started is still
around. If not, quit waiting for it immediately.
Remove all the confusing && chaining and simplify the code.
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A path containing a space must be quoted when used as an
argument to either the copy or rename commands (because
unlike other commands, the path is not the final thing on
the line for those commands).
Commit 6280dfdc3b (fast-export: quote paths in output,
2011-08-05) previously attempted to fix fast-export's
quoting by passing all paths through quote_c_style().
However, that function does not consider the space to be a
character which requires quoting, so let's special-case the
space inside print_path(). This will cause space-containing
paths to also be quoted in other commands where such quoting
is not strictly necessary, but it does not hurt to do so.
The test from 6280dfdc3b did not detect this because, while
it does introduce renames in the export stream, it does not
actually turn on rename detection, so they were presented as
pairs of deletions/adds. Using "-M" reveals the bug.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test for likely breakages in t3404, including successful reordering of
non-conflicting changes with a new root, correct preservation of commit
message and author in a root commit when it is squashed with the
sentinel, and presence of the sentinel following a conflicting
cherry-pick of a new root.
Remove test_must_fail for git rebase --root without --onto from t3412 as
this case will now be successfully handled by an implicit git rebase -i.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rebasing a commit that contains a diff in the commit message results
in a failure with output such as
First, rewinding head to replay your work on top of it...
Applying: My cool patch.
fatal: sha1 information is lacking or useless
(app/controllers/settings_controller.rb).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 My cool patch.
The reason is that 'git rebase' without -p/-i/-m internally calls 'git
format-patch' and pipes the output to 'git am --rebasing', which has
no way of knowing what is a real patch and what is a commit message
that contains a patch.
Make 'git am' while in --rebasing mode get the patch body from the
commit object instead of extracting it from the mailbox.
Patch by Junio, test case and commit log message by Martin.
Reported-by: anikey <arty.anikey@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just like
git rebase --onto newbase upstream branch error
displays the usage message, so should clearly
git rebase --onto newbase --root branch error
, but it doesn't. Instead, it ignores both "branch" and "error" and
rebases the current HEAD. This is because we try to match the number
of remainging arguments "$#", which fails to match "1" argument and
matches the "*" that really should have been a "0".
Make sure we display usage information when too many arguments are
given. Also fail-fast in case of similar bugs in the future by
matching on exactly 0 arguments and failing on unknown numbers.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
abe199808c (git checkout -b: allow switching out of an unborn branch)
introduced a bug demonstrated by
git checkout --orphan foo
git checkout --detach
git symbolic-ref HEAD
which gives 'refs/heads/(null)'.
This happens because we strbuf_addf(&branch_ref, "refs/heads/%s",
opts->new_branch) when opts->new_branch can be NULL for --detach.
Catch and forbid this case, adding a test to t2017 to catch it in
future.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of outputing only the username and password, print all the
attributes, even those that already appeared in the input.
This is closer to what the C API does, and allows one to take the exact
output of "git credential fill" as input to "git credential approve" or
"git credential reject".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The credential API is in C, and not available to scripting languages.
Expose the functionalities of the API by wrapping them into a new
plumbing command "git credentials".
In other words, replace the internal "test-credential" by an official Git
command.
Most documentation writen by: Jeff King <peff@peff.net>
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: Kim Thuat Nguyen <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: Javier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git to write to $XDG_CONFIG_HOME/git/config if
- it already exists,
- $HOME/.gitconfig file doesn't, and
- The --global option is used.
Otherwise, write to $HOME/.gitconfig when the --global option is
given, as before.
If the user doesn't create $XDG_CONFIG_HOME/git/config, there is
absolutely no change. Users can use this new file only if they want.
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used.
Advice for users who often come back to an old version of Git: you
shouldn't create this file.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives the default value for the core.attributesfile variable
following the exact same logic of the previous change for the
core.excludesfile setting.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To use the feature of core.excludesfile, the user needs:
1. to create such a file,
2. and add configuration variable to point at it.
Instead, we can make this a one-step process by choosing a default value
which points to a filename in the user's $HOME, that is unlikely to
already exist on the system, and only use the presence of the file as a
cue that the user wants to use that feature.
And we use "${XDG_CONFIG_HOME:-$HOME/.config/git}/ignore" as such a
file, in the same directory as the newly added configuration file
("${XDG_CONFIG_HOME:-$HOME/.config/git}/config). The use of this
directory is in line with XDG specification as a location to store
such application specific files.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git to read the "gitconfig" information from a new location,
$XDG_CONFIG_HOME/git/config; this allows the user to avoid
cluttering $HOME with many per-application configuration files.
In the order of reading, this file comes between the global
configuration file (typically $HOME/.gitconfig) and the system wide
configuration file (typically /etc/gitconfig).
We do not write to this new location (yet).
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used. This is in line with XDG specification.
If the new file does not exist, the behavior is unchanged.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This dot-sources GIT-BUILD-OPTIONS a lot earlier in test-lib.sh so
that its use of "perl" can use "$PERL_PATH" to choose the version of
Perl the user told us is suitable for our use.
This is iffy; I didn't check it very carefully, and I would not be
surprised if there are subtle breakages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a few more advices that we often have to give to new test
writers.
Also update an example where a double quote pair is used to enclose
a test body to use a single quote pair, which is more readable and
more importantly gives saner semantics for variable substitution.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it will be split at a space after "Program" when it is set
to "\\Program Files\perl" or something silly like that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most notably, t4031 creates a small shell script that invokes perl
and we want to use "$PERL_PATH" to name the version of Perl suitable
for our use, read from GIT-BUILD-OPTS. The test would fail when it
is directly run in t/ directory from the shell or "make" is run in t/
directory.
This problem was hidden from "make test" run in the top-level
directory, because its Makefile exports PERL_PATH.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- do not fetch HEAD
- do not also fetch refs following "xxx"
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running 'git diff --quiet <file1> <file2>', if file1 or file2
is outside the repository, it will exit(0) even if the files differ.
It should exit(1) when they differ.
This happens because 'diff_no_index' looks at the 'found_changes'
member from 'diff_options' to determine if changes were made. This
is the wrong thing to do, since it is only set if xdiff is actually
run and it finds a change (the diff machinery will optimize out the
xdiff call when it is not necessary) and in that case HAS_CHANGED
flag needs to be taken into account.
Use diff_result_code() that knows all these details for the correct
exit value instead.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When diff-no-index is given a relative path to a file outside the
repository, it aborts with error. However, if the file is given
using an absolute path, the diff runs as expected. The two cases
should be treated the same.
Tests and commit message by Tim Henigan.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone --local $path" started its life as an experiment to
optionally use link/copy when cloning a repository on the disk, but
we didn't deprecate it after we made the option a no-op to always
use the optimization.
The command learns "--no-local" option to turn this off, as a more
explicit alternative over use of file:// URL.
* jk/clone-local:
clone: allow --no-local to turn off local optimizations
docs/clone: mention that --local may be ignored
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>
The logic of git-show has remained largely unchanged since around
5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start
a revision walker with no_walk=1, look at its pending objects and
handle them one-by-one. For commits, this means stuffing them into a
new queue all alone, and running the walker.
Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came
along and set no_walk=0 whenever the user specifies a range. Which
appears to work fine, until you actually prod it hard enough, as the
preceding commit shows: UNINTERESTING commits will be marked as such,
but not walked further to propagate the marks.
Demonstrate this with the main tests of this patch: 'showing a range
walks (Y shape)'. The Y shape of history ensures that propagating the
UNINTERESTING marks is necessary to correctly exclude the main1
commit. The only example I could find actually requires that the
negative revisions are listed later, and in this scenario a dotted
range actually works. However, it is easy to find examples in git.git
where a dotted range is wrong, e.g.
$ git show v1.7.0..v1.7.1 | grep ^commit | wc -l
1297
$ git rev-list v1.7.0..v1.7.1 | wc -l
702
While there, also test a few other things that are not covered so far:
the -N way of triggering a range (added in 5853cae, DWIM 'git show -5'
to 'git show --do-walk -5', 2010-06-01), and the interactions of tags,
commits and ranges.
Pointed out by Dr_Memory on #git.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a server accessed through ssh is denying access git will currently
issue the message
"fatal: The remote end hung up unexpectedly"
as the last line. This sounds as if something really ugly just happened.
Since this is a quite typical situation in which users regularly get
we do not say that if it happens at the beginning when reading the
remote heads.
If its in the very first beginning of reading the remote heads it is
very likely an authentication error or a missing repository.
If it happens later during reading the remote heads we still indicate
that it happened during this initial contact phase.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
verify_filename() can be called in two different contexts. Either we
just tried to interpret a string as an object name, and it fails, so
we try looking for a working tree file (i.e. we finished looking at
revs that come earlier on the command line, and the next argument
must be a pathname), or we _know_ that we are looking for a
pathname, and shouldn't even try interpreting the string as an
object name.
For example, with this change, we get:
$ git log COPYING HEAD:inexistant
fatal: HEAD:inexistant: no such path in the working tree.
Use '-- <path>...' to specify paths that do not exist locally.
$ git log HEAD:inexistant
fatal: Path 'inexistant' does not exist in 'HEAD'
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diagnose_invalid_sha1_path() is meant to be called to diagnose a
misspelt <treeish>:<pathname> when <pathname> does not exist in
<treeish>. However, the code may call it if <treeish>:<pathname> is
invalid (which triggers another call with only_to_die == 1), but for
another reason. This happens when calling e.g.
git log existing-file HEAD:existing-file
because existing-file is a path and not a revision, the code
verifies that the arguments that follow to be paths. This leads to
an incorrect message like "existing-file does not exist in HEAD",
even though the path exists in HEAD.
Check that the search for <pathname> in <treeish> fails before
triggering the diagnosis.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not mix byte and line counts. Binary files have byte counts;
skip them when accumulating line insertions/deletions.
The regression was introduced in e18872b.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A recently introduced test uses an absolute path. But when run on Windows
using the MSYS bash, such a path is mangled into a Windows style path when
it is passed to 'git config'. The subsequent 'test' then compares the
mangled path to the unmangled version and reports a failure.
A path beginning with two slashes denotes a network directory
(//server/share path) and is not mangled. Use that trick to side-step the
issue. Just in case that 'git submodule init' regresses in such a way that
it accesses the URL, use a path name that is unlikely to exist on POSIX
systems, and that cannot be a server name on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new informative help messages at the output of 'git status' when
the user is splitting a commit. The code figures this state by
comparing the contents of the following files in the .git/ directory:
- HEAD
- ORIG_HEAD
- rebase-merge/amend
- rebase-merge/orig-head
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The display of the advice '(use git add/rm [...])' (when there are
unmerged files) after running 'git status' is now depending of the
mark, whether it's 'both deleted', 'deleted by us/them' or others. For
instance, when there is just one file that's marked as 'both deleted',
'git status' shows '(use git rm [...])' and if there are two files,
one as 'both deleted' and the other as 'added by them', the advice is
'(use git add/rm [...])'.
The previous tests in t7512-status-help.sh are updated.
Test about the case of only 'both deleted' is added in
t7060-wtstatus.sh
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
