We currently ignore the first line passed to `git interpret-trailers`,
when looking for the beginning of the trailers.
Unfortunately this does not work well when a commit is created with a
line break in the title, using for example the following command:
git commit -m 'place of
code: change we made'
That's why instead of ignoring only the first line, it is better to
ignore the first paragraph.
Signed-off-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While we are here, remove some boilerplate by using test_commit.
Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you init or clone an empty repository, the initial
message from running "git log" is not very friendly:
$ git init
Initialized empty Git repository in /home/peff/foo/.git/
$ git log
fatal: bad default revision 'HEAD'
Let's detect this situation and write a more friendly
message:
$ git log
fatal: your current branch 'master' does not have any commits yet
We also detect the case that 'HEAD' points to a broken ref;
this should be even less common, but is easy to see. Note
that we do not diagnose all possible cases. We rely on
resolve_ref, which means we do not get information about
complex cases. E.g., "--default master" would use dwim_ref
to find "refs/heads/master", but we notice only that
"master" does not exist. Similarly, a complex sha1
expression like "--default HEAD^2" will not resolve as a
ref.
But that's OK. We fall back to a generic error message in
those cases, and they are unlikely to be used anyway.
Catching an empty or broken "HEAD" improves the common case,
and the other cases are not regressed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove a cache invalidation which would cause the shared index to be
rewritten on as-is commits.
When the cache-tree has changed, we need to update it. But we don't
necessarily need to update the shared index. So setting
active_cache_changed to SOMETHING_CHANGED is unnecessary. Instead, we
let update_main_cache_tree just update the CACHE_TREE_CHANGED bit.
In order to test this, make test-dump-split-index not segfault on
missing replace_bitmap/delete_bitmap. This new codepath is not called
now that the test passes, but is necessary to avoid a segfault when the
new test is run with the old builtin/commit.c code.
Signed-off-by: David Turner <dturner@twopensource.com>
Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"interpret-trailers" helper mistook a single-liner log message that
has a colon as the end of existing trailer.
* cc/trailers-corner-case-fix:
trailer: retitle a test and correct an in-comment message
trailer: ignore first line of message
The experimental untracked-cache feature were buggy when paths with
a few levels of subdirectories are involved.
* dt/untracked-subdir:
untracked cache: fix entry invalidation
untracked-cache: fix subdirectory handling
With --detect-labels enabled, git-p4 will try to create tags
using git fast-import by writing a "tag" clause to the
fast-import stream.
If the commit that the tag references has not yet actually
been processed by fast-import, then the tag can't be created
and git-p4 fails to import the P4 label.
Teach git-p4 to use fast-import "marks" when creating tags
which reference commits created during the current run of the
program.
Commits created before the current run are still referenced
in the old way using a normal git commit.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When importing a label which references a commit that git-p4 does
not know about, git-p4 should skip it and go on to process other
labels that can be imported.
Instead it crashes when attempting to find the missing commit in
the git history. This test demonstrates the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perforce depot may record paths in mixed cases, e.g. "p4 files" may
show that there are these two paths:
//depot/Path/to/file1
//depot/pATH/to/file2
and with "p4" or "p4v", these end up in the same directory, e.g.
//depot/Path/to/file1
//depot/Path/to/file2
which is the desired outcome on case insensitive systems.
If git-p4 is used with client spec "//depot/Path/...", however, then
all files not matching the case in the client spec are ignored (in
the example above "//depot/pATH/to/file2").
Fix this by using the path case that appears first in lexicographical
order when core.ignorecase is set to true. This behavior is consistent
with "p4" and "p4v".
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support more than 65535 entries cleanly by writing a "zip64 end of
central directory record" (with a 64-bit field for the number of
entries) before the usual "end of central directory record" (which
contains only a 16-bit field). InfoZIP's zip does the same.
Archives with 65535 or less entries are not affected.
Programs that extract all files like InfoZIP's zip and 7-Zip
ignored the field and could extract all files already. Software
that relies on the ZIP file directory to show a list of contained
files quickly to simulate to normal directory like Windows'
built-in ZIP functionality only saw a subset of the included files.
Windows supports ZIP64 since Vista according to
https://en.wikipedia.org/wiki/Zip_%28file_format%29#ZIP64.
Suggested-by: Johannes Schauer <josch@debian.org>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A ZIP file directory has a 16-bit field for the number of entries it
contains. There are 64-bit extensions to deal with that. Demonstrate
that git archive --format=zip currently doesn't use them and instead
overflows the field.
InfoZIP's unzip doesn't care about this field and extracts all files
anyway. Software that uses the directory for presenting a filesystem
like view quickly -- notably Windows -- depends on it, but doesn't
lend itself to an automatic test case easily. Use InfoZIP's zipinfo,
which probably isn't available everywhere but at least can provides
*some* way to check this field.
To speed things up a bit create and commit only a subset of the files
and build a fake tree out of duplicates and pass that to git archive.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git am" that was recently reimplemented in C had a performance
regression in "git am --abort" that goes back to the version before
an attempted (and failed) patch application.
* pt/am-builtin-abort-fix:
am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
"git clone $URL" in recent releases of Git contains a regression in
the code that invents a new repository name incorrectly based on
the $URL. This has been corrected.
* jk/guess-repo-name-regression-fix:
clone: use computed length in guess_dir_name
clone: add tests for output directory
Running tests with the "-x" option to make them verbose had some
unpleasant interactions with other features of the test suite.
* jk/test-with-x:
test-lib: disable trace when test is not verbose
test-lib: turn off "-x" tracing during chain-lint check
After "git am --opt1" stops, running "git am --opt2" pays attention
to "--opt2" only for the patch that caused the original invocation
to stop.
* pt/am-builtin-options:
am: let --signoff override --no-signoff
am: let command-line options override saved options
test_terminal: redirect child process' stdin to a pty
When linked worktree is used, simultaneous "notes merge" instances
for the same ref in refs/notes/* are prevented from stomping on
each other.
* dt/notes-multiple:
notes: handle multiple worktrees
worktrees: add find_shared_symref
'git describe --contains' doesn't default to HEAD when no commit is
given, and it doesn't produce any output, not even an error:
~/src/git ((v2.5.0))$ ./git describe --contains
~/src/git ((v2.5.0))$ ./git describe --contains HEAD
v2.5.0^0
Unlike other 'git describe' options, the '--contains' code path is
implemented by calling 'name-rev' with a bunch of options plus all the
commit-ishes that were passed to 'git describe'. If no commit-ish was
present, then 'name-rev' got invoked with none, which then leads to the
behavior illustrated above.
Porcelain commands usually default to HEAD when no commit-ish is given,
and 'git describe' already does so in all other cases, so it should do
so with '--contains' as well.
Pass HEAD to 'name-rev' when no commit-ish is given on the command line
to make '--contains' behave consistently with other 'git describe'
options. While at it, use argv_array_pushv() instead of the loop to
pass commit-ishes to 'git name-rev'.
'git describe's short help already indicates that the commit-ish is
optional, but the synopsis in the man page doesn't, so update it
accordingly as well.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/git-path:
memoize common git-path "constant" files
get_repo_path: refactor path-allocation
find_hook: keep our own static buffer
refs.c: remove_empty_directories can take a strbuf
refs.c: avoid git_path assignment in lock_ref_sha1_basic
refs.c: avoid repeated git_path calls in rename_tmp_log
refs.c: simplify strbufs in reflog setup and writing
path.c: drop git_path_submodule
refs.c: remove extra git_path calls from read_loose_refs
remote.c: drop extraneous local variable from migrate_file
prefer mkpathdup to mkpath in assignments
prefer git_pathdup to git_path in some possibly-dangerous cases
add_to_alternates_file: don't add duplicate entries
t5700: modernize style
cache.h: complete set of git_path_submodule helpers
cache.h: clarify documentation for git_path, et al
When we are running the git command "foo", we may have to
look up the config keys "pager.foo" and "alias.foo". These
config schemes are mis-designed, as the command names can be
anything, but the config syntax has some restrictions. For
example:
$ git foo_bar
error: invalid key: pager.foo_bar
error: invalid key: alias.foo_bar
git: 'foo_bar' is not a git command. See 'git --help'.
You cannot name an alias with an underscore. And if you have
an external command with one, you cannot configure its
pager.
In the long run, we may develop a different config scheme
for these features. But in the near term (and because we'll
need to support the existing scheme indefinitely), we should
at least squelch the error messages shown above.
These errors come from git_config_parse_key. Ideally we
would pass a "quiet" flag to the config machinery, but there
are many layers between the pager code and the key parsing.
Passing a flag through all of those would be an invasive
change.
Instead, let's provide a config function to report on
whether a key is syntactically valid, and have the pager and
alias code skip lookup for bogus keys. We can build this
easily around the existing git_config_parse_key, with two
minor modifications:
1. We now handle a NULL store_key, to validate but not
write out the normalized key.
2. We accept a "quiet" flag to avoid writing to stderr.
This doesn't need to be a full-blown public "flags"
field, because we can make the existing implementation
a static helper function, keeping the mess contained
inside config.c.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When looking for the start of the trailers in the message
we are passed, we should ignore the first line of the message.
The reason is that if we are passed a patch or commit message
then the first line should be the patch title.
If we are passed only trailers we can expect that they start
with an empty line that can be ignored too.
This way we can properly process commit messages that have
only one line with something that looks like a trailer, for
example like "area of code: change we made".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_path() and mkpath() are handy helper functions but it is easy
to misuse, as the callers need to be careful to keep the number of
active results below 4. Their uses have been reduced.
* jk/git-path:
memoize common git-path "constant" files
get_repo_path: refactor path-allocation
find_hook: keep our own static buffer
refs.c: remove_empty_directories can take a strbuf
refs.c: avoid git_path assignment in lock_ref_sha1_basic
refs.c: avoid repeated git_path calls in rename_tmp_log
refs.c: simplify strbufs in reflog setup and writing
path.c: drop git_path_submodule
refs.c: remove extra git_path calls from read_loose_refs
remote.c: drop extraneous local variable from migrate_file
prefer mkpathdup to mkpath in assignments
prefer git_pathdup to git_path in some possibly-dangerous cases
add_to_alternates_file: don't add duplicate entries
t5700: modernize style
cache.h: complete set of git_path_submodule helpers
cache.h: clarify documentation for git_path, et al
"git clone $URL", when cloning from a site whose sole purpose is to
host a single repository (hence, no path after <scheme>://<site>/),
tried to use the site name as the new repository name, but did not
remove username or password when <site> part was of the form
<user>@<pass>:<host>. The code is taught to redact these.
* ps/guess-repo-name-at-root:
clone: abort if no dir name could be guessed
clone: do not use port number as dir name
clone: do not include authentication data in guessed dir
"git clone $URL" in recent releases of Git contains a regression in
the code that invents a new repository name incorrectly based on
the $URL. This has been corrected.
* jk/guess-repo-name-regression-fix:
clone: use computed length in guess_dir_name
clone: add tests for output directory
A negative !ref entry in multi-value transfer.hideRefs
configuration can be used to say "don't hide this one".
* jk/negative-hiderefs:
refs: support negative transfer.hideRefs
docs/config.txt: reorder hideRefs config
Running tests with the "-x" option to make them verbose had some
unpleasant interactions with other features of the test suite.
* jk/test-with-x:
test-lib: disable trace when test is not verbose
test-lib: turn off "-x" tracing during chain-lint check
t1509 test that requires a dedicated VM environment had some
bitrot, which has been corrected.
* ps/t1509-chroot-test-fixup:
tests: fix cleanup after tests in t1509-root-worktree
tests: fix broken && chains in t1509-root-worktree
Running an aliased command from a subdirectory when the .git thing
in the working tree is a gitfile pointing elsewhere did not work.
* nd/export-worktree:
setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR
The "rev-parse --parseopt" mode parsed the option specification
and the argument hint in a strange way to allow '=' and other
special characters in the option name while forbidding them from
the argument hint. This made it impossible to define an option
like "--pair <key>=<value>" with "pair=key=value" specification,
which instead would have defined a "--pair=key <value>" option.
* ib/scripted-parse-opt-better-hint-string:
rev-parse --parseopt: allow [*=?!] in argument hints
"sparse checkout" misbehaved for a path that is excluded from the
checkout when switching between branches that differ at the path.
* as/sparse-checkout-removal:
unpack-trees: don't update files with CE_WT_REMOVE set
We should not die when reading the submodule config cache since the
user might not be able to get out of that situation when the
configuration is part of the history.
We should handle this condition later when the value is about to be
used.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We remove the extracted functions and directly parse into and read out
of the cache. This allows us to have one unified way of accessing
submodule configuration values specific to single submodules. Regardless
whether we need to access a configuration from history or from the
worktree.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a superproject some commands need to interact with submodules. They
need to query values from the .gitmodules file either from the worktree
of from certain revisions. At the moment this is quite hard since a
caller would need to read the .gitmodules file from the history and then
parse the values. We want to provide an API for this so we have one
place to get values from .gitmodules from any revision (including the
worktree).
The API is realized as a cache which allows us to lazily read
.gitmodules configurations by commit into a runtime cache which can then
be used to easily lookup values from it. Currently only the values for
path or name are stored but it can be extended for any value needed.
It is expected that .gitmodules files do not change often between
commits. Thats why we lookup the .gitmodules sha1 from a commit and then
either lookup an already parsed configuration or parse and cache an
unknown one for each sha1. The cache is lazily build on demand for each
requested commit.
This cache can be used for all purposes which need knowledge about
submodule configurations. Example use cases are:
* Recursive submodule checkout needs to lookup a submodule name from
its path when a submodule first appears. This needs be done before
this configuration exists in the worktree.
* The implementation of submodule support for 'git archive' needs to
lookup the submodule name to generate the archive when given a
revision that is not checked out.
* 'git fetch' when given the --recurse-submodules=on-demand option (or
configuration) needs to lookup submodule names by path from the
database rather than reading from the worktree. For new submodule it
needs to lookup the name from its path to allow cloning new
submodules into the .git folder so they can be checked out without
any network interaction when the user does a checkout of that
revision.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running "git am --abort", and then running "git reset --hard",
files that were not modified would still be re-checked out.
This is because clean_index() in builtin/am.c mistakenly called the
read_tree() function, which overwrites all entries in the index,
including the stat info.
"git am --skip" did not seem to have this issue because am_skip() called
am_run(), which called refresh_cache() to update the stat info. However,
there's still a performance penalty as the lack of stat info meant that
refresh_cache() would have to scan all files for changes.
Fix this by using unpack_trees() instead to merge the tree into the
index, so that the stat info from the index is kept.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
First, the current code in untracked_cache_invalidate_path() is wrong
because it can only handle paths "a" or "a/b", not "a/b/c" because
lookup_untracked() only looks for entries directly under the given
directory. In the last case, it will look for the entry "b/c" in
directory "a" instead. This means if you delete or add an entry in a
subdirectory, untracked cache may become out of date because it does not
invalidate properly. This is noticed by David Turner.
The second problem is about invalidation inside a fully untracked/excluded
directory. In this case we may have to invalidate back to root. See the
comment block for detail.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, some calls lookup_untracked would pass a full path. But
lookup_untracked assumes that the portion of the path up to and
including to the untracked_cache_dir has been removed. So
lookup_untracked would be looking in the untracked_cache for 'foo' for
'foo/bar' (instead of just looking for 'bar'). This would cause
untracked cache corruption.
Instead, treat_directory learns to track the base length of the parent
directory, so that only the last path component is passed to
lookup_untracked.
Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When in the middle of t7063, we are sure untracked cache is supported,
so we can use --force-untracked-cache to skip the support detection
phase and save a few seconds. It's also good that --force-untracked-cache
is exercised in the test suite.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach notes about a new "notes.<name>.mergeStrategy" option for
configuring the notes merge strategy when merging into
refs/notes/<name>. This option allows for the selection of merge
strategy for particular notes refs, rather than all notes ref merges, as
user may not want cat_sort_uniq for all refs, but only some. Note that
the <name> is the local reference we are merging into, not the remote
ref we merged from. The assumption is that users will mostly want to
configure separate local ref merge strategies rather than strategies
depending on which remote ref they merge from.
notes.<name>.mergeStrategy overrides the general behavior as it is more
specific.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git-notes about "notes.mergeStrategy" to select a general strategy
for all notes merges. This enables a user to always get expected merge
strategy such as "cat_sort_uniq" without having to pass the "-s" option
manually.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new tests to ensure that --commit, --abort, and --strategy are
mutually exclusive.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow untracked cache (experimental) to be used when sparse
checkout (experimental) is also in use.
* dt/untracked-sparse:
untracked-cache: support sparse checkout
"git pull --rebase" has been taught to pay attention to
rebase.autostash configuration.
* kd/pull-rebase-autostash:
pull: allow dirty tree when rebase.autostash enabled
The code to perform multi-tree merges has been taught to repopulate
the cache-tree upon a successful merge into the index, so that
subsequent "diff-index --cached" (hence "status") and "write-tree"
(hence "commit") will go faster.
The same logic in "git checkout" may now be removed, but that is a
separate issue.
* dt/unpack-trees-cache-tree-revalidate:
unpack-trees: populate cache-tree on successful merge
Tests that assume how reflogs are represented on the filesystem too
much have been corrected.
* dt/reflog-tests:
tests: remove some direct access to .git/logs
t/t7509: remove unnecessary manipulation of reflog
The "new-worktree-mode" hack in "checkout" that was added in
nd/multiple-work-trees topic has been removed by updating the
implementation of new "worktree add".
* es/worktree-add-cleanup: (25 commits)
Documentation/git-worktree: fix duplicated 'from'
Documentation/config: mention "now" and "never" for 'expire' settings
Documentation/git-worktree: fix broken 'linkgit' invocation
checkout: drop intimate knowledge of newly created worktree
worktree: populate via "git reset --hard" rather than "git checkout"
worktree: avoid resolving HEAD unnecessarily
worktree: make setup of new HEAD distinct from worktree population
worktree: detect branch-name/detached and error conditions locally
worktree: add_worktree: construct worktree-population command locally
worktree: elucidate environment variables intended for child processes
worktree: make branch creation distinct from worktree population
worktree: add: suppress auto-vivication with --detach and no <branch>
worktree: make --detach mutually exclusive with -b/-B
worktree: introduce options container
worktree: simplify new branch (-b/-B) option checking
worktree: improve worktree setup message
branch: publish die_if_checked_out()
checkout: teach check_linked_checkout() about symbolic link HEAD
checkout: check_linked_checkout: simplify symref parsing
checkout: check_linked_checkout: improve "already checked out" aesthetic
...
Code and documentation clean-up to "git bisect".
* ad/bisect-cleanup:
bisect: don't mix option parsing and non-trivial code
bisect: simplify the addition of new bisect terms
bisect: replace hardcoded "bad|good" by variables
Documentation/bisect: revise overall content
Documentation/bisect: move getting help section to the end
bisect: correction of typo
After resolving a conflicting patch, a user may wish to sign off the
patch to declare that the patch has been modified. As such, the user
will expect that running "git am --signoff --continue" will append the
signoff to the commit message.
However, the --signoff option is only taken into account during the
mail-parsing stage. If the --signoff option is set, then the signoff
will be appended to the commit message. Since the mail-parsing stage
comes before the patch application stage, the --signoff option, if
provided on the command-line when resuming, will have no effect at all.
We cannot move the append_signoff() call to the patch application stage
as the applypatch-msg hook and interactive mode, which run before patch
application, may expect the signoff to be there.
Fix this by taking note if the user explictly set the --signoff option
on the command-line, and append the signoff to the commit message when
resuming if so.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resuming, git-am mistakenly ignores command-line options.
For instance, when a patch fails to apply with "git am patch",
subsequently running "git am --3way" would not cause git-am to fall
back on attempting a threeway merge. This occurs because by default
the --3way option is saved as "false", and the saved am options are
loaded after the command-line options are parsed, thus overwriting
the command-line options when resuming.
Fix this by moving the am_load() function call before parse_options(),
so that command-line options will override the saved am options.
The purpose of supporting this use case is to enable users to "wiggle"
that one conflicting patch. As such, it is expected that the
command-line options do not affect subsequent applied patches. Implement
this by calling am_load() once we apply the conflicting patch
successfully.
Noticed-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resuming, git-am detects if we are trying to feed it patches or not
by checking if stdin is a TTY.
However, the test library redirects stdin to /dev/null. This makes it
difficult, for instance, to test the behavior of "git am -3" when
resuming, as git-am will think we are trying to feed it patches and
error out.
Support this use case by extending test-terminal.perl to create a
pseudo-tty for the child process' standard input as well.
Note that due to the way the code is structured, the child's stdin
pseudo-tty will be closed when we finish reading from our stdin. This
means that in the common case, where our stdin is attached to /dev/null,
the child's stdin pseudo-tty will be closed immediately. Some operations
like isatty(), which git-am uses, require the file descriptor to be
open, and hence if the success of the command depends on such functions,
test_terminal's stdin should be redirected to a source with large amount
of data to ensure that the child's stdin is not closed, e.g.
test_terminal git am --3way </dev/zero
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A test case introduced by ae454f61 (Add tests for wildcard "path vs ref"
disambiguation) allocates a file named '*.c'. This does not work on
Windows, because the OS forbids file names containing wildcard
characters. The test case fails where the shell attempts to allocate the
file. Skip the test on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A test case introduced by 91479b9c (t7300: add tests to document
behavior of clean and nested git) uses 'chmod 0' to verify that a
subdirectory that has an unreadable .git file is not removed. This can
work only when the system pays attention to the permissions set with
'chmod'. Therefore, set the POSIXPERM prerequisite on the test case.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner <dturner@twopensource.com>
Reviewed-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The add_to_alternates_file function blindly uses
hold_lock_file_for_append to copy the existing contents, and
then adds the new line to it. This has two minor problems:
1. We might add duplicate entries, which are ugly and
inefficient.
2. We do not check that the file ends with a newline, in
which case we would bogusly append to the final line.
This is quite unlikely in practice, though, as we call
this function only from git-clone, so presumably we are
the only writers of the file (and we always add a
newline).
Instead of using hold_lock_file_for_append, let's copy the
file line by line, which ensures all records are properly
terminated. If we see an extra line, we can simply abort the
update (there is no point in even copying the rest, as we
know that it would be identical to the original).
As a bonus, we also get rid of some calls to the
static-buffer mkpath and git_path functions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The early part of this test is rather old, and does not
follow our usual style guidelines. In particular:
- the tests liberally chdir, and expect out-of-test "cd"
commands to return them to a sane state
- test commands aren't indented at all
- there are a lot of minor formatting nits, like the
opening quote of the test block on the wrong line,
spaces after ">", etc
This patch fixes the style issues, and uses a few helper
functions, along with subshells and "git -C", to avoid
changing the cwd of the main script.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the URI contains a port number and the URI's path component is
empty we fail to guess a sensible directory name. E.g. cloning a
repository 'ssh://example.com:2222/' we guess a directory name
'2222' where we would want the hostname only, e.g. 'example.com'.
We need to take care to not drop trailing port-like numbers in
certain cases. E.g. when cloning a repository 'foo/bar:2222.git'
we want to guess the directory name '2222' instead of 'bar'.
Thus, we have to first check the stripped URI for path separators
and only strip port numbers if there are path separators present.
This heuristic breaks when cloning a repository 'bar:2222.git',
though.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the URI contains authentication data and the URI's path
component is empty, we fail to guess a sensible directory name.
E.g. cloning a repository 'ssh://user:password@example.com/' we
guess a directory name 'password@example.com' where we would want
the hostname only, e.g. 'example.com'.
The naive way of just adding '@' as a path separator would break
cloning repositories like 'foo/bar@baz.git' (which would
currently become 'bar@baz' but would then become 'baz' only).
Instead fix this by first dropping the scheme and then greedily
scanning for an '@' sign until we find the first path separator.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7e837c6 (clone: simplify string handling in
guess_dir_name(), 2015-07-09) changed clone to use
strip_suffix instead of hand-rolled pointer manipulation.
However, strip_suffix will strip from the end of a
NUL-terminated string, and we may have already stripped some
characters (like directory separators, or "/.git"). This
leads to commands like:
git clone host:foo.git/
failing to strip the ".git".
We must instead convert our pointer arithmetic into a
computed length and feed that to strip_suffix_mem, which will
then reduce the length further for us.
It would be nicer if we could drop the pointer manipulation
entirely, and just continually strip using strip_suffix. But
that doesn't quite work for two reasons:
1. The early suffixes we're stripping are not constant; we
need to look for is_dir_sep, which could be one of
several characters.
2. Mid-way through the stripping we compute the pointer
"start", which shows us the beginning of the pathname.
Which really give us two lengths to work with: the
offset from the start of the string, and from the start
of the path. By using pointers for the early part, we
can just compute the length from "start" when we need
it.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we run "git clone $url", clone guesses from the $url
what to name the local output directory. We don't have any
test coverage of this, so let's add some basic tests.
This reveals a few problems:
- cloning "foo.git/" does not properly remove the ".git";
this is a recent regression from 7e837c6 (clone:
simplify string handling in guess_dir_name(), 2015-07-09)
- likewise, cloning foo/.git does not seem to handle the
bare case (we should end up in foo.git, but we try to
use foo/.git on the local end), which also comes from
7e837c6.
- cloning the root is not very smart about URL parsing,
and usernames and port numbers may end up in the
directory name
All of these tests are marked as failures.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git config' can only show values or name-value pairs, so if a shell
script needs the names of set config variables it has to run 'git config
--list' or '--get-regexp' and parse the output to separate config
variable names from their values. However, such a parsing can't cope
with multi-line values. Though 'git config' can produce null-terminated
output for newline-safe parsing, that's of no use in such a case, becase
shells can't cope with null characters.
Even our own bash completion script suffers from these issues.
Help the completion script, and shell scripts in general, by introducing
the '--name-only' option to modify the output of '--list' and
'--get-regexp' to list only the names of config variables, so they don't
have to perform error-prone post processing to separate variable names
from their values anymore.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-x" test-script option turns on the shell's "-x"
tracing, which can help show why a particular test is
failing. Unfortunately, this can create false negatives in
some tests if they invoke a shell function with its stderr
redirected. t5512.10 is such a test, as it does:
test_must_fail git ls-remote refs*master >actual 2>&1 &&
test_cmp exp actual
The "actual" file gets the "-x" trace for the test_must_fail
function, which prevents it from matching the expected
output.
There's no way to avoid this without managing the
trace flag inside each sub-function, which isn't really a
workable solution. But unless you specifically care about
t5512.10, we can work around it by enabling tracing only for
the specific tests we want.
You can already do:
./t5512-ls-remote.sh -x --verbose-only=16
to see the trace only for a specific test. But that doesn't
_disable_ the tracing in the other tests; it just sends it
to /dev/null. However, there's no point in generating a
trace that the user won't see, so we can simply disable
tracing whenever it doesn't have a matching verbose flag.
The normal case of just "./t5512-ls-remote.sh -x" stays the
same, as "-x" already implies "--verbose" (and
"--verbose-only" overrides "--verbose", which is why this
works at all). And for our test, we need only check
$verbose, as maybe_setup_verbose will have already
set that flag based on the $verbose_only list).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that GIT_TEST_CHAIN_LINT is on by default, running:
./t0000-basic.sh -x --verbose-only=1
starts with:
expecting success:
find .git/objects -type f -print >should-be-empty &&
test_line_count = 0 should-be-empty
+ exit 117
error: last command exited with $?=117
+ find .git/objects -type f -print
+ test_line_count = 0 should-be-empty
+ test 3 != 3
+ wc -l
+ test 0 = 0
ok 1 - .git/objects should be empty after git init in an empty repo
This is confusing, as the "exit 117" line and the error line
(which is printed in red, no less!) are not part of the test
at all, but are rather in the separate chain-lint test_eval.
Let's unset the "trace" variable when eval-ing the chain
lint check, which avoids this.
Note that we cannot just do a one-shot variable like:
trace= test_eval ...
as the behavior of one-shot variables for function calls
is not portable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you hide a hierarchy of refs using the transfer.hideRefs
config, there is no way to later override that config to
"unhide" it. This patch implements a "negative" hide which
causes matches to immediately be marked as unhidden, even if
another match would hide it. We take care to apply the
matches in reverse-order from how they are fed to us by the
config machinery, as that lets our usual "last one wins"
config precedence work (and entries in .git/config, for
example, will override /etc/gitconfig).
So you can now do:
$ git config --system transfer.hideRefs refs/secret
$ git config transfer.hideRefs '!refs/secret/not-so-secret'
to hide refs/secret in all repos, except for one public bit
in one specific repo. Or you can even do:
$ git clone \
-u "git -c transfer.hiderefs="!refs/foo" upload-pack" \
remote:repo.git
to clone remote:repo.git, overriding any hiding it has
configured.
There are two alternatives that were considered and
rejected:
1. A generic config mechanism for removing an item from a
list. E.g.: (e.g., "[transfer] hideRefs -= refs/foo").
This is nice because it could apply to other
multi-valued config, as well. But it is not nearly as
flexible. There is no way to say:
[transfer]
hideRefs = refs/secret
hideRefs = refs/secret/not-so-secret
Having explicit negative specifications means we can
override previous entries, even if they are not the
same literal string.
2. Adding another variable to override some parts of
hideRefs (e.g., "exposeRefs").
This solves the problem from alternative (1), but it
cannot easily obey the normal config precedence,
because it would use two separate lists. For example:
[transfer]
hideRefs = refs/secret
exposeRefs = refs/secret/not-so-secret
hideRefs = refs/secret/not-so-secret/no-really-its-secret
With two lists, we have to apply the "expose" rules
first, and only then apply the "hide" rules. But that
does not match what the above config intends.
Of course we could internally parse that to a single
list, respecting the ordering, which saves us having to
invent the new "!" syntax. But using a single name
communicates to the user that the ordering _is_
important. And "!" is well-known for negation, and
should not appear at the beginning of a ref (it is
actually valid in a ref-name, but all entries here
should be fully-qualified, starting with "refs/").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During cleanup we do a simple 'rm /*' to remove leftover files
from previous tests. As 'rm' errors out when there is anything it
cannot delete and there are directories present at '/' it will
throw an error, causing the '&&' chain to fail.
Fix this by explicitly removing the files.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the am.threeWay configuration variable to use the -3 or --3way
option of git am by default. When am.threeway is set and not desired
for a specific git am command, the --no-3way option can be used to
override it.
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows a natural user-interface when looking for any change in the
code, not just regression. For example:
git bisect start --term-old fast --term-new slow
git bisect fast
git bisect slow
...
There were several proposed user-interfaces for this feature. This patch
implements it as options to 'git bisect start' for the following reasons:
* By construction, the terms will be valid for one and only one
bisection.
* Unlike positional arguments, using named options avoid having to
remember an order.
* We can combine user-defined terms and passing old/new commits as
argument to "git bisect start".
* The implementation is relatively simple.
See previous discussions:
http://mid.gmane.org/1435337896-20709-3-git-send-email-Matthieu.Moy@imag.fr
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When not looking for a regression during a bisect but for a fix or a
change in another given property, it can be confusing to use 'good'
and 'bad'.
This patch introduce `git bisect new` and `git bisect old` as an
alternative to 'bad' and good': the commits which have a certain
property must be marked as `new` and the ones which do not as `old`.
The output will be the first commit after the change in the property.
During a new/old bisect session you cannot use bad/good commands and
vice-versa.
Some commands are still not available for old/new:
* git rev-list --bisect does not treat the revs/bisect/new and
revs/bisect/old-SHA1 files.
Old discussions:
- http://thread.gmane.org/gmane.comp.version-control.git/86063
introduced bisect fix unfixed to find fix.
- http://thread.gmane.org/gmane.comp.version-control.git/182398
discussion around bisect yes/no or old/new.
- http://thread.gmane.org/gmane.comp.version-control.git/199758
last discussion and reviews
New discussions:
- http://thread.gmane.org/gmane.comp.version-control.git/271320
( v2 1/7-4/7 )
- http://comments.gmane.org/gmane.comp.version-control.git/271343
( v2 5/7-7/7 )
Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>
Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.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: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow an asterisk as a substring (as opposed to the entirety) of
a path component for both side of a refspec, e.g.
"refs/heads/o*:refs/remotes/heads/i*".
* jk/refspec-parse-wildcard:
refs: loosen restriction on wildcard "*" refspecs
refs: cleanup comments regarding check_refname_component()
In preparation for allowing different "backends" to store the refs
in a way different from the traditional "one ref per file in $GIT_DIR
or in a $GIT_DIR/packed-refs file" filesystem storage, reduce
direct filesystem access to ref-like things like CHERRY_PICK_HEAD
from scripts and programs.
* dt/refs-backend-preamble:
git-stash: use update-ref --create-reflog instead of creating files
update-ref and tag: add --create-reflog arg
refs: add REF_FORCE_CREATE_REFLOG flag
git-reflog: add exists command
refs: new public ref function: safe_create_reflog
refs: break out check for reflog autocreation
refs.c: add err arguments to reflog functions
"sparse checkout" misbehaved for a path that is excluded from the
checkout when switching between branches that differ at the path.
* as/sparse-checkout-removal:
unpack-trees: don't update files with CE_WT_REMOVE set
Teach "git log" and friends a new "--date=format:..." option to
format timestamps using system's strftime(3).
* jk/date-mode-format:
strbuf: make strbuf_addftime more robust
introduce "format" date-mode
convert "enum date_mode" into a struct
show-branch: use DATE_RELATIVE instead of magic number
* pt/am-tests:
t3901: test git-am encoding conversion
t3418: non-interactive rebase --continue with rerere enabled
t4150: tests for am --[no-]scissors
t4150: am with post-applypatch hook
t4150: am with pre-applypatch hook
t4150: am with applypatch-msg hook
t4150: am --resolved fails if index has unmerged entries
t4150: am --resolved fails if index has no changes
t4150: am refuses patches when paused
t4151: am --abort will keep dirty index intact
t4150: am fails if index is dirty
t4150: am.messageid really adds the message id
Optimize computation of untracked status indicator by bash prompt
script (in contrib/).
* sg/bash-prompt-untracked-optim:
bash prompt: faster untracked status indicator with untracked directories
bash prompt: test untracked files status indicator with untracked dirs
The "rev-parse --parseopt" mode parsed the option specification
and the argument hint in a strange way to allow '=' and other
special characters in the option name while forbidding them from
the argument hint. This made it impossible to define an option
like "--pair <key>=<value>" with "pair=key=value" specification,
which instead would have defined a "--pair=key <value>" option.
* ib/scripted-parse-opt-better-hint-string:
rev-parse --parseopt: allow [*=?!] in argument hints
"git fast-import" learned to respond to the get-mark command via
its cat-blob-fd interface.
* mh/fast-import-get-mark:
fast-import: add a get-mark command
Add "drop commit-object-name subject" command as another way to
skip replaying of a commit in "rebase -i", and then punish those
who do not use it (and instead just remove the lines) by throwing
a warning.
* gr/rebase-i-drop-warn:
git rebase -i: add static check for commands and SHA-1
git rebase -i: warn about removed commits
git-rebase -i: add command "drop" to remove a commit
Add a new configuration variable to enable "--follow" automatically
when "git log" is run with one pathspec argument.
* dt/log-follow-config:
log: add "log.follow" configuration variable
Teach "git status" to show a more detailed information regarding
the "rebase -i" session in progress.
* gp/status-rebase-i-info:
status: add new tests for status during rebase -i
status: give more information during rebase -i
status: differentiate interactive from non-interactive rebases
status: factor two rebase-related messages together
"cat-file" learned "--batch-all-objects" option to enumerate all
available objects in the repository more quickly than "rev-list
--all --objects" (the output includes unreachable objects, though).
* jk/cat-file-batch-all:
cat-file: sort and de-dup output of --batch-all-objects
cat-file: add --batch-all-objects option
cat-file: split batch_one_object into two stages
cat-file: stop returning value from batch_one_object
cat-file: add --buffer option
cat-file: move batch_options definition to top of file
cat-file: minor style fix in options list
Allow ignoring fsck errors on specific set of known-to-be-bad
objects, and also tweaking warning level of various kinds of non
critical breakages reported.
* js/fsck-opt:
fsck: support ignoring objects in `git fsck` via fsck.skiplist
fsck: git receive-pack: support excluding objects from fsck'ing
fsck: introduce `git fsck --connectivity-only`
fsck: support demoting errors to warnings
fsck: document the new receive.fsck.<msg-id> options
fsck: allow upgrading fsck warnings to errors
fsck: optionally ignore specific fsck issues completely
fsck: disallow demoting grave fsck errors to warnings
fsck: add a simple test for receive.fsck.<msg-id>
fsck: make fsck_tag() warn-friendly
fsck: handle multiple authors in commits specially
fsck: make fsck_commit() warn-friendly
fsck: make fsck_ident() warn-friendly
fsck: report the ID of the error/warning
fsck (receive-pack): allow demoting errors to warnings
fsck: offer a function to demote fsck errors to warnings
fsck: provide a function to parse fsck message IDs
fsck: introduce identifiers for fsck messages
fsck: introduce fsck options
Enhance packet tracing machinery to allow capturing an incoming
pack data to a file for debugging.
* jk/pkt-log-pack:
pkt-line: support tracing verbatim pack contents
pkt-line: tighten sideband PACK check when tracing
pkt-line: simplify starts_with checks in packet tracing
"git rebase -i"'s list of todo is made configurable.
* mr/rebase-i-customize-insn-sheet:
git-rebase--interactive.sh: add config option for custom instruction format
"git send-email" now performs alias-expansion on names that are
given via --cccmd, etc.
This round comes with a lot more enhanced e-mail address parser,
which makes it a bit scary, but as long as it works as designed, it
makes it wonderful ;-).
* rl/send-email-aliases:
send-email: suppress meaningless whitespaces in from field
send-email: allow multiple emails using --cc, --to and --bcc
send-email: consider quote as delimiter instead of character
send-email: reduce dependencies impact on parse_address_line
send-email: minor code refactoring
send-email: allow use of aliases in the From field of --compose mode
send-email: refactor address list process
t9001-send-email: refactor header variable fields replacement
send-email: allow aliases in patch header and command script outputs
t9001-send-email: move script creation in a setup test
Running an aliased command from a subdirectory when the .git thing
in the working tree is a gitfile pointing elsewhere did not work.
* nd/export-worktree:
setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR
Replace "is this subdirectory a separate repository that should not
be touched?" check "git clean" does by checking if it has .git/HEAD
using the submodule-related code with a more optimized check.
* ee/clean-remove-dirs:
read_gitfile_gently: fix use-after-free
clean: improve performance when removing lots of directories
p7300: add performance tests for clean
t7300: add tests to document behavior of clean and nested git
setup: sanity check file size in read_gitfile_gently
setup: add gentle version of read_gitfile
Move machinery to parse human-readable scaled numbers like 1k, 4M,
and 2G as an option parameter's value from pack-objects to
parse-options API, to make it available to other codepaths.
* cb/parse-magnitude:
parse-options: move unsigned long option parsing out of pack-objects.c
test-parse-options: update to handle negative ints
"git verify-tag" and "git verify-commit" have been taught to share
more code, and then learned to optionally show the verification
message from the underlying GPG implementation.
* bc/gpg-verify-raw:
verify-tag: add option to print raw gpg status information
verify-commit: add option to print raw gpg status information
gpg: centralize printing signature buffers
gpg: centralize signature check
verify-commit: add test for exit status on untrusted signature
verify-tag: share code with verify-commit
verify-tag: add tests
Various enhancements around "git am" reading patches generated by
foreign SCM.
* pt/am-foreign:
am: teach mercurial patch parser how to read from stdin
am: use gmtime() to parse mercurial patch date
t4150: test applying StGit series
am: teach StGit patch parser how to read from stdin
t4150: test applying StGit patch
Abandoning an already applied change in "git rebase -i" with
"--continue" left CHERRY_PICK_HEAD and confused later steps.
* js/rebase-i-clean-up-upon-continue-to-skip:
rebase -i: do not leave a CHERRY_PICK_HEAD file behind
t3404: demonstrate CHERRY_PICK_HEAD bug
Various fixes around "git am" that applies a patch to a history
that is not there yet.
* pt/am-abort-fix:
am --abort: keep unrelated commits on unborn branch
am --abort: support aborting to unborn branch
am --abort: revert changes introduced by failed 3way merge
am --skip: support skipping while on unborn branch
am -3: support 3way merge on unborn branch
am --skip: revert changes introduced by failed 3way merge
"git for-each-ref" reported "missing object" for 0{40} when it
encounters a broken ref. The lack of object whose name is 0{40} is
not the problem; the ref being broken is.
* mh/reporting-broken-refs-from-for-each-ref:
read_loose_refs(): treat NULL_SHA1 loose references as broken
read_loose_refs(): simplify function logic
for-each-ref: report broken references correctly
t6301: new tests of for-each-ref error handling
"git commit --cleanup=scissors" was not careful enough to protect
against getting fooled by a line that looked like scissors.
* sg/commit-cleanup-scissors:
commit: cope with scissors lines in commit message
Add the '--contains' option provided by 'ref-filter'. The '--contains'
option lists only refs which contain the mentioned commit (HEAD if no
commit is explicitly given).
Add documentation and tests for the same.
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into the named commit.
Add documentation and tests for the same.
Based-on-patch-by: Jeff King <peff@peff.net>
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the '--points-at' option provided by 'ref-filter'. The
option lets the user to list only refs which points at the
given object.
Add documentation and tests for the same.
Based-on-patch-by: Jeff King <peff@peff.net>
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test suite for testing the ref-filter APIs used
by for-each-ref. We just intialize the test suite for now.
More tests will be added in the following patches as more
options are added to for-each-ref.
Based-on-patch-by: Jeff King <peff@peff.net>
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove a check that would disable the untracked cache for sparse
checkouts. Add tests that ensure that the untracked cache works with
sparse checkouts -- specifically considering the case that a file
foo/bar is checked out, but foo/.gitignore is not.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we unpack trees into an existing index, we discard the old
index and replace it with the new, merged index. Ensure that this
index has its cache-tree populated. This will make subsequent git
status and commit commands faster.
Signed-off-by: Brian Degenhardt <bmd@bmdhacks.com>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alternate refs backends might store reflogs somewhere other than
.git/logs. Change most test code that directly accesses .git/logs to
instead use git reflog commands.
There are still a few tests which need direct access to reflogs: to
check reflog permissions, to manually create reflogs from scratch, to
save/restore reflogs, to check the format of raw reflog data, and to
remove not just reflog contents, but the reflogs themselves. All cases
which don't need direct access have been modified.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove unnecessary reflog manipulation. The test does not rely in any
way on this reflog manipulation, and the case that the test
exercises is unrelated to reflogs.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A minor bugfix when pack bitmap is used with "rev-list --count".
* jk/rev-list-no-bitmap-while-pruning:
rev-list: disable --use-bitmap-index when pruning commits
An ancient test framework enhancement to allow color was not
entirely correct; this makes it work even when tput needs to read
from the ~/.terminfo under the user's real HOME directory.
* rh/test-color-avoid-terminfo-in-original-home:
test-lib.sh: fix color support when tput needs ~/.terminfo
Revert "test-lib.sh: do tests for color support after changing HOME"
Loosen restrictions on refspecs by allowing patterns that have a "*"
within a component instead of only as the whole component.
Remove the logic to accept a single "*" as a whole component from
check_refname_format(), and implement an extended form of that logic
in check_refname_component(). Pass the pointer to the flags argument
to the latter, as it has to clear REFNAME_REFSPEC_PATTERN bit when
it sees "*".
Teach check_refname_component() function to allow an asterisk "*"
only when REFNAME_REFSPEC_PATTERN is set in the flags, and drop the
bit after seeing a "*", to ensure that one side of a refspec
contains at most one asterisk.
This will allow us to accept refspecs such as `for/bar*:foo/baz*`.
Any refspec which functioned before shall continue functioning with
the new logic.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit d96a275b91.
It used to be possible to apply a patch series with "git am mbox"
and then only after seeing a failure, switch to three-way mode via
"git am -3" (no other options or arguments). The commit being
reverted broke this workflow.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for Fountain, a plain text screenplay format. Git
facilitates not just programming specifically, but creative writing
in general, so it makes sense to also support other plain text
documents besides source code.
In the structure of a screenplay specifically, scenes are roughly
analogous to functions, in the sense that it makes your job easier
if you can see which ones were changed in a given range of patches.
More information about the Fountain format can be found on its
official website, at http://fountain.io .
Signed-off-by: Zoë Blade <zoe@bytenoise.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase learned to stash changes when it encounters a dirty work tree,
but git pull --rebase does not.
Only verify if the working tree is dirty when rebase.autostash is not
enabled.
Signed-off-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow the creation of a ref (e.g. stash) with a reflog already in
place. For most refs (e.g. those under refs/heads), this happens
automatically, but for others, we need this option.
Currently, git does this by pre-creating the reflog, but alternate ref
backends might store reflogs somewhere other than .git/logs. Code
that now directly manipulates .git/logs should instead use git
plumbing commands.
I also added --create-reflog to git tag, just for completeness.
In a moment, we will use this argument to make git stash work with
alternate ref backends.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is necessary because alternate ref backends might store reflogs
somewhere other than .git/logs. Code that now directly manipulates
.git/logs should instead go through git-reflog.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't update files in the worktree from cache entries which are
flagged with CE_WT_REMOVE.
When a user does a sparse checkout, git removes files that are
marked with CE_WT_REMOVE (because they are out-of-scope for the
sparse checkout). If those files are also marked CE_UPDATE (for
instance, because they differ in the branch that is being checked
out and the outgoing branch), git would previously recreate them.
This patch prevents them from being recreated.
These erroneously-created files would also interfere with merges,
causing pre-merge revisions of out-of-scope files to appear in the
worktree.
apply_sparse_checkout() is the function where all "action"
manipulation (add, delete, update files..) for sparse checkout
occurs; it should not ask to delete and update both at the same
time.
Signed-off-by: Anatole Shaw <git-devel@omni.poc.net>
Signed-off-by: David Turner <dturner@twopensource.com>
Helped-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The return value of strftime is poorly designed; when it
returns 0, the caller cannot tell if the buffer was not
large enough, or if the output was actually 0 bytes. In the
original implementation of strbuf_addftime, we simply punted
and guessed that our 128-byte hint would be large enough.
We can do better, though, if we're willing to treat strftime
like less of a black box. We can munge the incoming format
to make sure that it never produces 0-length output, and
then "fix" the resulting output. That lets us reliably grow
the buffer based on strftime's return value.
Clever-idea-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The next commit will tweak the way __git_ps1() decides whether to display
the untracked files status indicator in the presence of untracked
directories. Add tests to make sure it doesn't change current behavior,
in particular that an empty untracked directory doesn't trigger the
untracked files status indicator.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix oversight where branch auto-vivication incorrectly kicks in when
--detach is specified and <branch> omitted. Instead, treat:
git worktree add --detach <path>
as shorthand for:
git worktree add --detach <path> HEAD
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Be consistent with git-checkout which disallows this (not particularly
meaningful) combination.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
check_linked_checkout() only understands symref-style HEAD (i.e. "ref:
refs/heads/master"), however, HEAD may also be a an actual symbolic link
(on platforms which support it). To accurately detect if a branch is
checked out elsewhere, it needs to handle symbolic link HEAD, as well.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
supported the --utf8 and --no-utf8 options, and if set, would pass the
-u flag and the -k flag respectively.
git mailinfo -u will re-code the commit log message and authorship info
in the charset specified by i18n.commitencoding setting, while
git mailinfo -n will disable the re-coding.
Since d84029b (--utf8 is now default for 'git-am', 2007-01-08), --utf8
is set by default in git-am.
Add various encoding conversion tests to t3901 to test git-mailinfo's
encoding conversion. In addition, add a test for --no-utf8 to check that
no encoding conversion will occur if that option is set.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 8389b52 (git-rerere: reuse recorded resolve., 2006-01-28), git-am
will call git-rerere to re-use recorded merge conflict resolutions if
any occur in a threeway merge.
Add a test to ensure that git-rerere is called by git-am (which handles
the non-interactive rebase).
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 017678b (am/mailinfo: Disable scissors processing by default,
2009-08-26), git-am supported the --[no-]scissors option, passing it to
git-mailinfo.
Add tests to ensure that git-am will pass the --scissors option to
git-mailinfo, and that --no-scissors will override the configuration
setting of mailinfo.scissors.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sh will invoke the post-applypatch hook after the patch is
applied and a commit is made. The exit code of the hook is ignored.
Add tests for this hook.
Helped-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sg will invoke the pre-applypatch hook after applying the patch
to the index, but before a commit is made. Should the hook exit with a
non-zero status, git am will exit.
Add tests for this hook.
Helped-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will invoke the applypatch-msg hooks just after extracting the patch
message. If the applypatch-msg hook exits with a non-zero status, git-am
abort before even applying the patch to the index.
Add tests for this hook.
Helped-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since c1d1128 (git-am --resolved: more usable error message.,
2006-04-28), git-am --resolved will check to see if there are any
unmerged entries, and will error out with a user-friendly error message
if there are.
Add a test for this.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 6d28644 (git-am: do not allow empty commits by mistake.,
2006-02-23), git-am --resolved will check to see if the index has any
changes to prevent the user from creating an empty commit by mistake.
Add a test for this.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since c95b138 (Fix git-am safety checks, 2006-09-15), when there is a
session in progress, git-am will check the command-line arguments and
standard input to ensure that the user does not pass it any patches.
Add a test for this.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 7b3b7e3 (am --abort: keep unrelated commits since the last failure
and warn, 2010-12-21), git-am --abort will not touch the index if on the
previous invocation, git-am failed because the index is dirty. This is
to ensure that the user's modifications to the index are not discarded.
Add a test for this.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will ensure that the index is clean before applying the patch. This is
to prevent changes unrelated to the patch from being committed.
Add a test for this check.
Reviewed-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git format-patch --ignore-if-upstream A..B" did not like to be fed
tags as boundary commits.
* jc/do-not-feed-tags-to-clear-commit-marks:
format-patch: do not feed tags to clear_commit_marks()
A line in the input to "rev-parse --parseopt" describes an option by
listing a short and/or long name, optional flags [*=?!], argument hint,
and then whitespace and help string.
We did not allow any of the [*=?!] characters in the argument hints.
The following input
pair=key=value equals sign in the hint
used to generate a help line like this:
--pair=key <value> equals sign in the hint
and used to expect "pair=key" as the argument name.
That is not very helpful as we generally do not want any of the [*=?!]
characters in the argument names. But we do want to use at least the
equals sign in the argument hints.
Update the parser to make long argument names stop at the first [*=?!]
character.
Add test case with equals sign in the argument hint and update the test
to perform all the operations in test_expect_success matching the
t/README requirements and allowing commands like
./t1502-rev-parse-parseopt.sh --run=1-2
to stop at the test case 2 without any further modification of the test
state area.
Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update to the "linked checkout" in 2.5.0-rc1.
Instead of "checkout --to" that does not do what "checkout"
normally does, move the functionality to "git worktree add".
* es/worktree-add: (24 commits)
Revert "checkout: retire --ignore-other-worktrees in favor of --force"
checkout: retire --ignore-other-worktrees in favor of --force
worktree: add: auto-vivify new branch when <branch> is omitted
worktree: add: make -b/-B default to HEAD when <branch> is omitted
worktree: extract basename computation to new function
checkout: require worktree unconditionally
checkout: retire --to option
tests: worktree: retrofit "checkout --to" tests for "worktree add"
worktree: add -b/-B options
worktree: add --detach option
worktree: add --force option
worktree: introduce "add" command
checkout: drop 'checkout_opts' dependency from prepare_linked_checkout
checkout: make --to unconditionally verbose
checkout: prepare_linked_checkout: drop now-unused 'new' argument
checkout: relocate --to's "no branch specified" check
checkout: fix bug with --to and relative HEAD
Documentation/git-worktree: add EXAMPLES section
Documentation/git-worktree: add high-level 'lock' overview
Documentation/git-worktree: split technical info from general description
...
"git checkout [<tree-ish>] <paths>" spent unnecessary cycles
checking if the current branch was checked out elsewhere, when we
know we are not switching the branches ourselves.
* nd/multiple-work-trees:
worktree: new place for "git prune --worktrees"
checkout: don't check worktrees when not necessary
Abandoning an already applied change in "git rebase -i" with
"--continue" left CHERRY_PICK_HEAD and confused later steps.
* js/rebase-i-clean-up-upon-continue-to-skip:
rebase -i: do not leave a CHERRY_PICK_HEAD file behind
t3404: demonstrate CHERRY_PICK_HEAD bug
A minor bugfix when pack bitmap is used with "rev-list --count".
* jk/rev-list-no-bitmap-while-pruning:
rev-list: disable --use-bitmap-index when pruning commits
An ancient test framework enhancement to allow color was not
entirely correct; this makes it work even when tput needs to read
from the ~/.terminfo under the user's real HOME directory.
* rh/test-color-avoid-terminfo-in-original-home:
test-lib.sh: fix color support when tput needs ~/.terminfo
Revert "test-lib.sh: do tests for color support after changing HOME"
The for_each_packed_object() API function did not iterate over
objects in a packfile that hasn't been used yet.
* jk/maint-for-each-packed-object:
for_each_packed_object: automatically open pack index
People who work on projects with mostly linear history with frequent
whole file renames may want to always use "git log --follow" when
inspecting the life of the content that live in a single path.
Teach the command to behave as if "--follow" was given from the
command line when log.follow configuration variable is set *and*
there is one (and only one) path on the command line.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove leading and trailing whitespaces in from field before
interepreting it to improve consistency with other options. The
split_addrs function already take care of trailing and leading
whitespaces for to, cc and bcc fields.
The from option now:
- has the same behavior when passing arguments like
" jdoe@example.com ", "\t jdoe@example.com " or
"jdoe@example.com".
- interprets aliases in string containing leading and trailing
whitespaces such as " alias" or "alias\t" like other options.
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses from the header of an existing e-mail message,
which already lists them as comma-separated list, as a value to a
single parameter.
The following format can now be used:
$ git send-email --to='Jane <jdoe@example.com>, mike@example.com'
Remove the limitation imposed by 79ee555b (Check and document the
options to prevent mistakes, 2006-06-21) which rejected every argument
with comma in --cc, --to and --bcc.
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
parse_address_line had not the same behavior whether the user had
Mail::Address or not. Teach parse_address_line to behave like
Mail::Address.
When the user input is correct, this implementation behaves
exactly like Mail::Address except when there are quotes
inside the name:
"Jane Do"e <jdoe@example.com>
In this case the result of parse_address_line is:
With M::A : "Jane Do" e <jdoe@example.com>
Without : "Jane Do e" <jdoe@example.com>
When the user input is not correct, the behavior is also mostly
the same.
Unlike Mail::Address, this doesn't parse groups and recursive
commentaries.
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a convenience, when <branch> is omitted from "git worktree <path>
<branch>" and neither -b nor -B is used, automatically create a new
branch named after <path>, as if "-b $(basename <path>)" was specified.
Thus, "git worktree add ../hotfix" creates a new branch named "hotfix"
and associates it with new worktree "../hotfix".
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since a078f73 (git-am: add --message-id/--no-message-id, 2014-11-25),
the am.messageid setting determines whether the --message-id option is
set by default.
Add a test for this.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expand test coverage with one or more than two commands done
and with zero, one or more than two commands remaining.
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a convenience, like "git branch" and "git checkout -b", make
"git worktree add -b <newbranch> <path> <branch>" default to HEAD when
<branch> is omitted.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the introduction of "git worktree add", "git checkout --to" is
slated for removal. Therefore, retrofit linked worktree creation tests
to use "git worktree add" instead.
(The test to check exclusivity of "checkout --to" and "checkout <paths>"
is dropped altogether since it becomes meaningless with retirement of
"checkout --to".)
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Given "git checkout --to <path> HEAD~1", the new worktree's HEAD should
begin life at the current branch's HEAD~1, however, it actually ends up
at HEAD~2. This happens because:
1. git-checkout resolves HEAD~1
2. to satisfy is_git_directory(), prepare_linked_worktree() creates
a HEAD for the new worktree with the value of the resolved HEAD~1
3. git-checkout re-invokes itself with the same arguments within the
new worktree to populate the worktree
4. the sub git-checkout resolves HEAD~1 relative to its own HEAD,
which is the resolved HEAD~1 from the original invocation,
resulting unexpectedly and incorrectly in HEAD~2 (relative to the
original)
Fix this by unconditionally assigning the current worktree's HEAD as the
value of the new worktree's HEAD.
As a side-effect, this change also eliminates a dependence within
prepare_linked_checkout() upon 'struct branch_info'. The plan is to
eventually relocate "git checkout --to" functionality to "git worktree
add", and worktree.c won't have knowledge of 'struct branch_info', so
removal of this dependency is a step toward that goal.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reachability bitmaps do not have enough information to
tell us which commits might have changed path "foo", so the
current code produces wrong answers for:
git rev-list --use-bitmap-index --count HEAD -- foo
(it silently ignores the "foo" limiter). Instead, we should
fall back to doing a normal traversal (it is OK to fall
back rather than complain, because --use-bitmap-index is a
pure optimization, and might not kick in for other reasons,
such as there being no bitmaps in the repository).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used -
2015-05-02) changes how the disambiguation rules work. This patch adds
some tests to demonstrate, basically, if wildcard characters are in an
argument:
- if the argument is valid extended sha-1 syntax, "--" must be used
- otherwise the argument is considered a path, even without "--"
And wildcard can appear in extended sha-1 syntax, either as part of
regex in ":/<regex>" or as the literal path in ":<path>". The latter
case is less likely to happen in real world. But if you do ":/" a lot,
you may need to type "--" more.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is sometimes useful for importers to be able to read the SHA-1
corresponding to a mark that they have created via fast-import. For
example, they might want to embed the SHA-1 into the commit message of
a later commit. Or it might be useful for internal bookkeeping uses,
or for logging.
Add a "get-mark" command to "git fast-import" that allows the importer
to ask for the value of a mark that has been created earlier.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check before the start of the rebasing if the commands exists, and for
the commands expecting a SHA-1, check if the SHA-1 is present and
corresponds to a commit. In case of error, print the error, stop git
rebase and prompt the user to fix with 'git rebase --edit-todo' or to
abort.
This allows to avoid doing half of a rebase before finding an error
and giving back what's left of the todo list to the user and prompt
him to fix when it might be too late for him to do so (he might have
to abort and restart the rebase).
Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check if commits were removed (i.e. a line was deleted) and print
warnings or stop git rebase depending on the value of the
configuration variable rebase.missingCommitsCheck.
This patch gives the user the possibility to avoid silent loss of
information (losing a commit through deleting the line in this case)
if he wants.
Add the configuration variable rebase.missingCommitsCheck.
- When unset or set to "ignore", no checking is done.
- When set to "warn", the commits are checked, warnings are
displayed but git rebase still proceeds.
- When set to "error", the commits are checked, warnings are
displayed and the rebase is stopped.
(The user can then use 'git rebase --edit-todo' and
'git rebase --continue', or 'git rebase --abort')
rebase.missingCommitsCheck defaults to "ignore".
Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of removing a line to remove the commit, you can use the
command "drop" (just like "pick" or "edit"). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a commit by mistake.
Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create a function which replaces Date, Message-Id and
X-Mailer lines generated by git-send-email by a specific string:
Date:.*$ -> Date: DATE-STRING
Message-Id:.*$ -> Message-Id: MESSAGE-ID-STRING
X-Mailer:.*$ -> X-Mailer: X-MAILER-STRING
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Interpret aliases in:
- Header fields of patches generated by git format-patch
(using --to, --cc, --add-header for example) or
manually modified. Example of fields in header:
To: alias1
Cc: alias2
Cc: alias3
- Outputs of command scripts specified by --cc-cmd and
--to-cmd. Example of script:
#!/bin/sh
echo alias1
echo alias2
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the creation of the scripts used in to-cmd and cc-cmd tests
in a setup test to make them available for later tests.
Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.
The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in git-rebase.sh, even
before git-rebase--interactive.sh is called.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rev-list's --cherry option does not detect that a patch has already
been applied upstream, an interactive rebase would offer to reapply it and
consequently stop at that patch with a failure, mentioning that the diff
is empty.
Traditionally, a `git rebase --continue` simply skips the commit in such a
situation.
However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD
behind, making the Git prompt believe that a cherry pick is still going
on. This commit adds a test case demonstrating this bug.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This feeds the format directly to strftime. Besides being a
little more flexible, the main advantage is that your system
strftime may know more about your locale's preferred format
(e.g., how to spell the days of the week).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 23af91d (prune: strategies for linked checkouts - 2014-11-30)
adds "--worktrees" to "git prune" without realizing that "git prune" is
for object database only. This patch moves the same functionality to a
new command "git worktree".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
In the test case, we run setup_git_dir_gently() the first time to read
$GIT_DIR/config so that we can resolve aliases. We'll enter
setup_discovered_git_dir() and may or may not call set_git_dir() near
the end of the function, depending on whether the detected git dir is
".git" or not. This set_git_dir() will set env var $GIT_DIR.
For normal repo, git dir detected via setup_discovered_git_dir() will be
".git", and set_git_dir() is not called. If .git file is used however,
the git dir can't be ".git" and set_git_dir() is called and $GIT_DIR
set. This is the key of this problem.
If we expand an alias (or autocorrect command names), then
setup_git_dir_gently() is run the second time. If $GIT_DIR is not set in
the first run, we run the same setup_discovered_git_dir() as before.
Nothing to see. If it is, however, we'll enter setup_explicit_git_dir()
this time.
This is where the "fun" is. If $GIT_WORK_TREE is not set but
$GIT_DIR is, you are supposed to be at the root level of the
worktree. But if you are in a subdir "foo/bar" (real worktree's top
is "foo"), this rule bites you: your detected worktree is now
"foo/bar", even though the first run correctly detected worktree as
"foo". You get "internal error: work tree has already been set" as a
result.
Bottom line is, when $GIT_DIR is set, $GIT_WORK_TREE should be set too
unless there's no work tree. But setting $GIT_WORK_TREE inside
set_git_dir() may backfire. We don't know at that point if work tree is
already configured by the caller. So set it when work tree is
detected. It does not harm if $GIT_WORK_TREE is set while $GIT_DIR is
not.
Reported-by: Bjørnar Snoksrud <snoksrud@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The sorting we could probably live without, but printing
duplicates is just a hassle for the user, who must then
de-dup themselves (or risk a wrong answer if they are doing
something like counting objects with a particular property).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The setup code used to die when core.bare and core.worktree are set
inconsistently, even for commands that do not need working tree.
* jk/die-on-bogus-worktree-late:
setup_git_directory: delay core.bare/core.worktree errors
Recent "git prune" traverses young unreachable objects to safekeep
old objects in the reachability chain from them, which sometimes
caused error messages that are unnecessarily alarming.
* jk/squelch-missing-link-warning-for-unreachable:
suppress errors on missing UNINTERESTING links
silence broken link warnings with revs->ignore_missing_links
add quieter versions of parse_{tree,commit}
"git rebase -i" fired post-rewrite hook when it shouldn't (namely,
when it was told to stop sequencing with 'exec' insn).
* mm/rebase-i-post-rewrite-exec:
t5407: use <<- to align the expected output
rebase -i: fix post-rewrite hook with failed exec command
rebase -i: demonstrate incorrect behavior of post-rewrite
If this extension is used in a repository, then no
operations should run which may drop objects from the object
storage. This can be useful if you are sharing that storage
with other repositories whose refs you cannot see.
For instance, if you do:
$ git clone -s parent child
$ git -C parent config extensions.preciousObjects true
$ git -C parent config core.repositoryformatversion 1
you now have additional safety when running git in the
parent repository. Prunes and repacks will bail with an
error, and `git gc` will skip those operations (it will
continue to pack refs and do other non-object operations).
Older versions of git, when run in the repository, will
fail on every operation.
Note that we do not set the preciousObjects extension by
default when doing a "clone -s", as doing so breaks
backwards compatibility. It is a decision the user should
make explicitly.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally we try to avoid bumps of the whole-repository
core.repositoryformatversion field. However, it is
unavoidable if we want to safely change certain aspects of
git in a backwards-incompatible way (e.g., modifying the set
of ref tips that we must traverse to generate a list of
unreachable, safe-to-prune objects).
If we were to bump the repository version for every such
change, then any implementation understanding version `X`
would also have to understand `X-1`, `X-2`, and so forth,
even though the incompatibilities may be in orthogonal parts
of the system, and there is otherwise no reason we cannot
implement one without the other (or more importantly, that
the user cannot choose to use one feature without the other,
weighing the tradeoff in compatibility only for that
particular feature).
This patch documents the existing repositoryformatversion
strategy and introduces a new format, "1", which lets a
repository specify that it must run with an arbitrary set of
extensions. This can be used, for example:
- to inform git that the objects should not be pruned based
only on the reachability of the ref tips (e.g, because it
has "clone --shared" children)
- that the refs are stored in a format besides the usual
"refs" and "packed-refs" directories
Because we bump to format "1", and because format "1"
requires that a running git knows about any extensions
mentioned, we know that older versions of the code will not
do something dangerous when confronted with these new
formats.
For example, if the user chooses to use database storage for
refs, they may set the "extensions.refbackend" config to
"db". Older versions of git will not understand format "1"
and bail. Versions of git which understand "1" but do not
know about "refbackend", or which know about "refbackend"
but not about the "db" backend, will refuse to run. This is
annoying, of course, but much better than the alternative of
claiming that there are no refs in the repository, or
writing to a location that other implementations will not
read.
Note that we are only defining the rules for format 1 here.
We do not ever write format 1 ourselves; it is a tool that
is meant to be used by users and future extensions to
provide safety with older implementations.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
More Perforce row number limit workaround for "git p4".
* ld/p4-changes-block-size:
git-p4: fixing --changes-block-size handling
git-p4: add tests for non-numeric revision range
git-p4: test with limited p4 server results
git-p4: additional testing of --changes-block-size
"git commit --cleanup=scissors" was not careful enough to protect
against getting fooled by a line that looked like scissors.
* sg/commit-cleanup-scissors:
commit: cope with scissors lines in commit message
"git for-each-ref" reported "missing object" for 0{40} when it
encounters a broken ref. The lack of object whose name is 0{40} is
not the problem; the ref being broken is.
* mh/reporting-broken-refs-from-for-each-ref:
read_loose_refs(): treat NULL_SHA1 loose references as broken
read_loose_refs(): simplify function logic
for-each-ref: report broken references correctly
t6301: new tests of for-each-ref error handling
Various fixes around "git am" that applies a patch to a history
that is not there yet.
* pt/am-abort-fix:
am --abort: keep unrelated commits on unborn branch
am --abort: support aborting to unborn branch
am --abort: revert changes introduced by failed 3way merge
am --skip: support skipping while on unborn branch
am -3: support 3way merge on unborn branch
am --skip: revert changes introduced by failed 3way merge
Traditionally, external low-level 3-way merge drivers are expected
to produce their results based solely on the contents of the three
variants given in temporary files named by %O, %A and %B on their
command line. Additionally allow them to look at the final path
(given by %P).
* jc/ll-merge-expose-path:
ll-merge: pass the original path to external drivers
"git pull" has become more aware of the options meant for
underlying "git fetch" and then learned to use parse-options
parser.
* pt/pull-optparse:
pull: use git-rev-parse --parseopt for option parsing
pull: handle git-fetch's options as well
"git format-patch --ignore-if-upstream A..B" did not like to be fed
tags as boundary commits.
* jc/do-not-feed-tags-to-clear-commit-marks:
format-patch: do not feed tags to clear_commit_marks()
"git send-email" learned to handle more forms of sendmail style
aliases file.
* es/send-email-sendmail-alias:
send-email: further warn about unsupported sendmail aliases features
t9001: add sendmail aliases line continuation tests
t9001: refactor sendmail aliases test infrastructure
send-email: implement sendmail aliases line continuation support
send-email: simplify sendmail aliases comment and blank line recognizer
send-email: refactor sendmail aliases parser
send-email: fix style: cuddle 'elsif' and 'else' with closing brace
send-email: drop noise comments which merely repeat what code says
send-email: visually distinguish sendmail aliases parser warnings
send-email: further document missing sendmail aliases functionality
"git apply" cannot diagnose a patch corruption when the breakage is
to mark the length of the hunk shorter than it really is on the
hunk header line "@@ -l,k +m,n @@"; one special case it could is
when the hunk becomes no-op (e.g. k == n == 2 for two-line context
patch output), and it learned how to do so.
* jc/apply-reject-noop-hunk:
apply: reject a hunk that does not do anything
The optional new config option `receive.fsck.skipList` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
This is extremely handy in case of legacy repositories where it would
cause more pain to change incorrect objects than to live with them
(e.g. a duplicate 'author' line in an early commit object).
The intended use case is for server administrators to inspect objects
that are reported by `git push` as being too problematic to enter the
repository, and to add the objects' SHA-1 to a (preferably sorted) file
when the objects are legitimate, i.e. when it is determined that those
problematic objects should be allowed to enter the server.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option avoids unpacking each and all blob objects, and just
verifies the connectivity. In particular with large repositories, this
speeds up the operation, at the expense of missing corrupt blobs,
ignoring unreachable objects and other fsck issues, if any.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c fsck.missingEmail=ignore fsck` would hide
problems with missing emails in author, committer and tagger lines.
In the same spirit that `git receive-pack`'s usage of the fsck machinery
differs from `git fsck`'s – some of the non-fatal warnings in `git fsck`
are fatal with `git receive-pack` when receive.fsckObjects = true, for
example – we strictly separate the fsck.<msg-id> from the
receive.fsck.<msg-id> settings.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalidTagName` and
`missingTaggerEntry` in the receive.fsck.<msg-id> config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported with the "error:" prefix, as it used to be
the case before this commit).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An fsck issue in a legacy repository might be so common that one would
like not to bother the user with mentioning it at all. With this change,
that is possible by setting the respective message type to "ignore".
This change "abuses" the missingEmail=warn test to verify that "ignore"
is also accepted and works correctly. And while at it, it makes sure
that multiple options work, too (they are passed to unpack-objects or
index-pack as a comma-separated list via the --strict=... command-line
option).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
