A new whitespace "rule" is added that sets the tab width to use for
whitespace checks and fix-ups and replaces the hard-coded constant 8.
Since the setting is part of the rules, it can be set per file using
.gitattributes.
The new configuration is backwards compatible because older git versions
simply ignore unknown whitespace rules.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the whitespace rule tab-in-indent is enabled, apply --whitespace=fix
replaces tabs by the appropriate amount of blanks. The code used
"dst->len % 8" as the criterion to stop adding blanks. But it forgot that
dst holds more than just the current line. Consequently, the modulus was
computed correctly only for the first added line, but not for the second
and subsequent lines. Fix it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new rule: a "cat-blob" can be inserted wherever a comment is
allowed, which means at the start of any line except in the middle of
a "data" command.
This saves frontends from having to loop over everything they want to
commit in the next commit and cat-ing the necessary objects in
advance.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New objects written by fast-import are not available immediately.
Until a checkpoint has been started and finishes writing the pack
index, any new blobs will not be accessible using standard git tools.
So introduce a new way to access them: a "cat-blob" command in the
command stream requests for fast-import to print a blob to stdout or a
file descriptor specified by the argument to --cat-blob-fd. The value
for cat-blob-fd cannot be specified in the stream because that would
be a layering violation: the decision of where to direct a stream has
to be made when fast-import is started anyway, so we might as well
make the stream format is independent of that detail.
Output uses the same format as "git cat-file --batch".
Thanks to Sverre Rabbelier and Sam Vilain for guidance in designing
the protocol.
Based-on-patch-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check the result from strtoul to avoid accepting arguments like
--depth=-1 and --active-branches=foo,bar,baz.
Requested-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Matching index entries against an excludes file currently has two
problems.
First, there's no function to do it. Code paths (like sparse
checkout) that wanted to try it would iterate over index entries and
for each index entry pass that path to excluded_from_list(). But that
is not how excluded_from_list() works; one is supposed to feed in each
ancester of a path before a given path to find out if it was excluded
because of some parent or grandparent matching a
bigsubdirectory/
pattern despite the path not matching any .gitignore pattern directly.
Second, it's inefficient. The excludes mechanism is supposed to let
us block off vast swaths of the filesystem as uninteresting; separately
checking every index entry doesn't fit that model.
Introduce a new function to take care of both these problems. This
traverses the index in depth-first order (well, that's what order the
index is in) to mark un-excluded entries.
Maybe some day the in-core index format will be restructured to make
this sort of operation easier. Or maybe we will want to try some
binary search based thing. The interface is simple enough to allow
all those things. Example:
clear_ce_flags(the_index.cache, the_index.cache_nr,
CE_CANDIDATE, CE_CLEARME, exclude_list);
would clear the CE_CLEARME flag on all index entries with
CE_CANDIDATE flag and not matched by exclude_list.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cb/leading-path-removal:
use persistent memory for rejected paths
do not overwrite files in leading path
lstat_cache: optionally return match_len
add function check_ok_to_remove()
t7607: add leading-path tests
t7607: use test-lib functions and check MERGE_HEAD
Conflicts:
t/t7607-merge-overwrite.sh
* en/merge-recursive: (41 commits)
t6022: Use -eq not = to test output of wc -l
merge-recursive:make_room_for_directories - work around dumb compilers
merge-recursive: Remove redundant path clearing for D/F conflicts
merge-recursive: Make room for directories in D/F conflicts
handle_delete_modify(): Check whether D/F conflicts are still present
merge_content(): Check whether D/F conflicts are still present
conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts
conflict_rename_delete(): Check whether D/F conflicts are still present
merge-recursive: Delay modify/delete conflicts if D/F conflict present
merge-recursive: Delay content merging for renames
merge-recursive: Delay handling of rename/delete conflicts
merge-recursive: Move handling of double rename of one file to other file
merge-recursive: Move handling of double rename of one file to two
merge-recursive: Avoid doubly merging rename/add conflict contents
merge-recursive: Update merge_content() call signature
merge-recursive: Update conflict_rename_rename_1to2() call signature
merge-recursive: Structure process_df_entry() to handle more cases
merge-recursive: Have process_entry() skip D/F or rename entries
merge-recursive: New function to assist resolving renames in-core only
merge-recursive: New data structures for deferring of D/F conflicts
...
Conflicts:
t/t6020-merge-df.sh
t/t6036-recursive-corner-cases.sh
* jn/fast-import-fix:
fast-import: do not clear notes in do_change_note_fanout()
t9300 (fast-import): another test for the "replace root" feature
fast-import: tighten M 040000 syntax
fast-import: filemodify after M 040000 <tree> "" crashes
You can tell "git status" to paint the name of the current branch in its
output (the line that says "On branch ...") by setting the configuration
variable color.status.branch; it is by default turned off.
Signed-off-by: Aleksi Aalto <aga@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since c85c792 (pull --rebase: be cleverer with rebased upstream
branches, 2008-01-26), "git pull --rebase" has used the reflog to try to
rebase from the old upstream onto the new upstream.
Make this work if the local repository is explicitly passed on the
command line as in 'git pull --rebase . foo'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Acked-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test fails on Windows since 2dec68c (tests: add missing &&, batch 2).
Even though this test allocates and leaves behind files, subsequent tests
do not depend on this, so it is safe to just skip it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ao/send-email-irt:
git-send-email.perl: make initial In-Reply-To apply only to first email
t9001: send-email interation with --in-reply-to and --chain-reply-to
* kb/maint-rebase-autosquash:
rebase: teach --autosquash to match on sha1 in addition to message
rebase: better rearranging of fixup!/squash! lines with --autosquash
* mm/phrase-remote-tracking:
git-branch.txt: mention --set-upstream as a way to change upstream configuration
user-manual: remote-tracking can be checked out, with detached HEAD
user-manual.txt: explain better the remote(-tracking) branch terms
Change incorrect "remote branch" to "remote tracking branch" in C code
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change "tracking branch" to "remote-tracking branch"
everyday.txt: change "tracking branch" to "remote-tracking branch"
Change remote tracking to remote-tracking in non-trivial places
Replace "remote tracking" with "remote-tracking"
Better "Changed but not updated" message in git-status
By ignoring the Text-Delta and Prop-Delta node fields, current svn-fe
happily mistakes deltas for full text and instead of cleanly erroring
out, it produces a valid but semantically bogus fast-import stream
when fed a dump file in the modern "svnadmin dump --deltas" format.
Dump file parsers are supposed to ignore header fields they don't
understand (to allow for backward-compatible extensions), but they are
also supposed to check the SVN-fs-dump-format-version header to
prevent misinterpretation of non backward-compatible extensions.
Do so.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jm/mailmap:
t4203: do not let "git shortlog" DWIM based on tty
t4203 (mailmap): stop hardcoding commit ids and dates
mailmap: fix use of freed memory
The reflog-walking mechanism is based on the regular
revision traversal. We just rewrite the parents of each
commit in fake_reflog_parent to point to the commit in the
next reflog entry instead of the real parents.
However, the regular revision traversal tries not to show
the same commit twice, and so sets the SHOWN flag on each
commit it shows. In a reflog, however, we may want to see
the same commit more than once if it appears in the reflog
multiple times (which easily happens, for example, if you do
a reset to a prior state).
The fake_reflog_parent function takes care of this by
clearing flags, including SHOWN. Unfortunately, it does so
at the very end of the function, and it is possible to
return early from the function if there is no fake parent to
set up (e.g., because we are at the very first reflog entry
on the branch). In such a case the flag is not cleared, and
the entry is skipped by the revision traversal machinery as
already shown.
You can see this by walking the log of a ref which is set to
its very first commit more than once (the test below shows
such a situation). In this case the reflog walk will fail to
show the entry for the initial creation of the ref.
We don't want to simply move the flag-clearing to the top of
the function; we want to make sure flags set during the
fake-parent installation are also cleared. Instead, let's
hoist the flag-clearing out of the fake_reflog_parent
function entirely. It's not really about fake parents
anyway, and the only caller is the get_revision machinery.
Reported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a non-interactive rebase of a ref fails at commit X and is aborted by
the user, the ref will be updated twice. First to point at X (with the
reflog message "rebase finished: $head_name onto $onto"), and then back
to $orig_head. It should not be updated at all.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running test t9010 without the SVN:: perl modules currently errors
out, for no good reason. We can make these tests easier to read and
run by not using the perl libsvn bindings and instead duplicating only
the relevant code from lib-git-svn.sh.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass output through the pager if format-patch is run with --stdout. This
saves the user the trouble of running git with '-p' or piping through a
pager.
setup_pager() already checks if stdout is a tty, so we don't have to
worry about behaviour if the user redirects/pipes stdout. Paging can
also be disabled with the config
[pager]
format-patch = false
Add tests to check for these behaviour.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* kb/maint-submodule-savearg:
submodule: only preserve flags across recursive status/update invocations
submodule: preserve all arguments exactly when recursing
* jm/mailmap:
t4203: do not let "git shortlog" DWIM based on tty
t4203 (mailmap): stop hardcoding commit ids and dates
mailmap: fix use of freed memory
* jk/push-progress:
push: pass --progress down to git-pack-objects
t5523-push-upstream: test progress messages
t5523-push-upstream: add function to ensure fresh upstream repo
test_terminal: ensure redirections work reliably
test_terminal: catch use without TTY prerequisite
test-lib: allow test code to check the list of declared prerequisites
tests: test terminal output to both stdout and stderr
tests: factor out terminal handling from t7006
* jn/gitweb-test:
gitweb/Makefile: Include gitweb/config.mak
gitweb/Makefile: Add 'test' and 'test-installed' targets
t/gitweb-lib.sh: Add support for GITWEB_TEST_INSTALLED
gitweb: Move call to evaluate_git_version after evaluate_gitweb_config
When comparing numbers such as "3" to "$(wc -l)", we should check for
numerical equality using -eq instead of string equality using = because
some implementations of wc output extra whitespace.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach 'git merge' the --abort option, which verifies the existence of
MERGE_HEAD and then invokes 'git reset --merge' to abort the current
in-progress merge and attempt to reconstruct the pre-merge state.
The reason for adding this option is to provide a user interface for
aborting an in-progress merge that is consistent with the interface
for aborting a rebase ('git rebase --abort'), aborting the application
of a patch series ('git am --abort'), and aborting an in-progress notes
merge ('git notes merge --abort').
The patch includes documentation and testcases that explain and verify
the various scenarios in which 'git merge --abort' can run. The
testcases also document the cases in which 'git merge --abort' is
unable to correctly restore the pre-merge state (look for the '###'
comments towards the bottom of t/t7609-merge-abort.sh).
This patch has been improved by the following contributions:
- Jonathan Nieder: Move test documentation into test_description
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Script may use 'git notes get-ref' to easily retrieve the current notes ref.
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Notes trees may exist at different fanout levels internally. This
implementation detail should not be visible to the user, and it should
certainly not affect the merging of notes tree.
This patch adds testcases verifying the correctness of 'git notes merge'
when merging notes trees at different fanout levels.
This patch has been improved by the following contributions:
- Junio C Hamano: Portability: Don't string-compare 'wc -l' output
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new strategy is similar to "concatenate", but in addition to
concatenating the two note candidates, this strategy sorts the resulting
lines, and removes duplicate lines from the result. This is equivalent to
applying the "cat | sort | uniq" shell pipeline to the two note candidates.
This strategy is useful if the notes follow a line-based format where one
wants to avoid duplicate lines in the merge result.
Note that if either of the note candidates contain duplicate lines _prior_
to the merge, these will also be removed by this merge strategy.
The patch also contains tests and documentation for the new strategy.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When manually resolving a notes merge, if the merging ref has moved since
the merge started, we should fail to complete the merge, and alert the user
to what's going on.
This situation may arise if you start a 'git notes merge' which results in
conflicts, and you then update the current notes ref (using for example
'git notes add/copy/amend/edit/remove/prune', 'git update-ref', etc.),
before you get around to resolving the notes conflicts and calling
'git notes merge --commit'.
We detect this situation by comparing the first parent of the partial merge
commit (which was created when the merge started) to the current value of the
merging notes ref (pointed to by the .git/NOTES_MERGE_REF symref).
If we don't fail in this situation, the notes merge commit would overwrite
the updated notes ref, thus losing the changes that happened in the meantime.
The patch includes a testcase verifying that we fail correctly in this
situation.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This brings notes merge in line with regular merge's behaviour.
This patch has been improved by the following contributions:
- Ævar Arnfjörð Bjarmason: Don't use C99 comments.
Thanks-to: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the notes merge conflicts in .git/NOTES_MERGE_WORKTREE have been
resolved, we need to record a new notes commit on the appropriate notes
ref with the resolved notes.
This patch implements 'git notes merge --commit' which the user should
run after resolving conflicts in the notes merge worktree. This command
finalizes the notes merge by recombining the partial notes tree from
part 1 with the now-resolved conflicts in the notes merge worktree in a
merge commit, and updating the appropriate ref to this merge commit.
In order to correctly finalize the merge, we need to keep track of three
things:
- The partial merge result from part 1, containing the auto-merged notes.
This is now stored into a ref called .git/NOTES_MERGE_PARTIAL.
- The unmerged notes. These are already stored in
.git/NOTES_MERGE_WORKTREE, thanks to part 1.
- The notes ref to be updated by the finalized merge result. This is now
stored in a symref called .git/NOTES_MERGE_REF.
In addition to "git notes merge --commit", which uses the above details
to create the finalized notes merge commit, this patch also implements
"git notes merge --reset", which aborts the ongoing notes merge by simply
removing the files/directory described above.
FTR, "git notes merge --commit" reuses "git notes merge --reset" to remove
the information described above (.git/NOTES_MERGE_*) after the notes merge
have been successfully finalized.
The patch also contains documentation and testcases for the two new options.
This patch has been improved by the following contributions:
- Ævar Arnfjörð Bjarmason: Fix nonsense sentence in --commit description
- Sverre Rabbelier: Rename --reset to --abort
Thanks-to: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Thanks-to: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Conflicts (that are to be resolved manually) are written into a special-
purpose working tree, located at .git/NOTES_MERGE_WORKTREE. Within this
directory, conflicting notes entries are stored (with conflict markers
produced by ll_merge()) using the SHA1 of the annotated object. The
.git/NOTES_MERGE_WORKTREE directory will only contain the _conflicting_
note entries. The non-conflicting note entries (aka. the partial merge
result) are stored in 'local_tree', and the SHA1 of the resulting commit
is written to 'result_sha1'. The return value from notes_merge() is -1.
The user is told to edit the files within the .git/NOTES_MERGE_WORKTREE
directory in order to resolve the conflicts.
The patch also contains documentation and testcases for the correct setup
of .git/NOTES_MERGE_WORKTREE.
The next part will recombine the partial notes merge result with the
resolved conflicts in .git/NOTES_MERGE_WORKTREE to produce the complete
merge result.
This patch has been improved by the following contributions:
- Jonathan Nieder: Use trace_printf(...) instead of OUTPUT(o, 5, ...)
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new -s/--strategy command-line option to 'git notes merge' allow the user
to choose how notes merge conflicts should be resolved. There are four valid
strategies to choose from:
1. "manual" (the default): This will let the user manually resolve conflicts.
This option currently fails with an error message. It will be implemented
properly in future patches.
2. "ours": This automatically chooses the local version of a conflict, and
discards the remote version.
3. "theirs": This automatically chooses the remote version of a conflict, and
discards the local version.
4. "union": This automatically resolves the conflict by appending the remote
version to the local version.
The strategies are implemented using the combine_notes_* functions from the
notes.h API.
The patch also includes testcases verifying the correct implementation of
these strategies.
This patch has been improved by the following contributions:
- Jonathan Nieder: Future-proof by always checking add_note() return value
- Stephen Boyd: Use test_commit
- Stephen Boyd: Use correct option name
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This continuation of the 'git notes merge' implementation teaches notes-merge
to properly do real merges between notes trees: Two diffs are performed, one
from $base to $remote, and another from $base to $local. The paths in each
diff are normalized to SHA1 object names. The two diffs are then consolidated
into a single list of change pairs to be evaluated. Each change pair consist
of:
- The annotated object's SHA1
- The $base SHA1 (i.e. the common ancestor notes for this object)
- The $local SHA1 (i.e. the current notes for this object)
- The $remote SHA1 (i.e. the to-be-merged notes for this object)
From the pair ($base -> $local, $base -> $remote), we can determine the merge
result using regular 3-way rules. If conflicts are encountered in this
process, we fail loudly and exit (conflict handling to be added in a future
patch), If we can complete the merge without conflicts, the resulting
notes tree is committed, and the current notes ref updated.
The patch includes added testcases verifying that we can successfully do real
conflict-less merges.
This patch has been improved by the following contributions:
- Jonathan Nieder: Future-proof by always checking add_note() return value
- Stephen Boyd: Use test_commit
- Jonathan Nieder: Use trace_printf(...) instead of OUTPUT(o, 5, ...)
- Junio C Hamano: fixup minor style issues
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Stephen Boyd <bebarino@gmail.com>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This initial implementation of 'git notes merge' only handles the trivial
merge cases (i.e. where the merge is either a no-op, or a fast-forward).
The patch includes testcases for these trivial merge cases.
Future patches will extend the functionality of 'git notes merge'.
This patch has been improved by the following contributions:
- Stephen Boyd: Simplify argc logic
- Stephen Boyd: Use test_commit
- Ævar Arnfjörð Bjarmason: Don't use C99 comments.
- Jonathan Nieder: Add constants for common verbosity values
- Jonathan Nieder: Use trace_printf(...) instead of OUTPUT(o, 5, ...)
- Jonathan Nieder: Remove extraneous show() function
- Jonathan Nieder: Clarify handling of empty/missing notes ref in notes_merge()
- Junio C Hamano: fixup minor style issues
Thanks-to: Stephen Boyd <bebarino@gmail.com>
Thanks-to: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using combine_notes_concatenate() to concatenate notes, it currently
ensures exactly one newline character between the given notes. However,
when using builtin/notes.c:create_note() to concatenate notes (e.g. by
'git notes append'), it adds a newline character to the trailing newline
of the preceding notes object, thus resulting in _two_ newlines (aka. a
blank line) separating contents of the two notes.
This patch brings combine_notes_concatenate() into consistency with
builtin/notes.c:create_note(), by ensuring exactly _two_ newline characters
between concatenated notes.
The patch also changes a few notes-related selftests accordingly.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rest of the file uses tabs for indenting. Fix the one function
that doesn't.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the authentification initialisation to percent-decode username
and password for HTTP URLs.
Signed-off-by: Gabriel Corona <gabriel.corona@enst-bretagne.fr>
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test for HTTP authentication and proper percent-decoding of the
userinfo (username and password) part of the URL.
Signed-off-by: Gabriel Corona <gabriel.corona@enst-bretagne.fr>
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A user may want different pager settings or even a
different pager for various subcommands (e.g., because they
use different less settings for "log" vs "diff", or because
they have a pager that interprets only log output but not
other commands).
This patch extends the pager.<cmd> syntax to support not
only boolean to-page-or-not-to-page, but also to specify a
pager just for a specific command.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We explicitly document "0" and "1" as synonyms for "false"
and "true" in boolean config options. However, we don't
actually handle those values in git_config_maybe_bool.
In most cases this works fine, as we call git_config_bool,
which in turn calls git_config_bool_or_int, which in turn
calls git_config_maybe_bool. Values of 0/1 are considered
"not bool", but their integer values end up being converted
to the corresponding boolean values.
However, the log.decorate code looks for maybe_bool
explicitly, so that it can fall back to the "short" and
"full" strings. It does not handle 0/1 at all, and considers
them invalid values.
We cannot simply add 0/1 support to git_config_maybe_bool.
That would confuse git_config_bool_or_int, which may want to
distinguish the integer values "0" and "1" from bools.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An aborted merge prints the list of rejected paths as part of the
error message. Since commit f66caaf9 (do not overwrite files in
leading path), some of those paths do not have static buffers, so
we have to keep a copy. Use string_list's to accomplish this.
This changes the order of the list to the order in which the paths
are processed. Previously, it was reversed.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case HEAD does not point to a valid commit yet, merge is
implemented as a hard reset. This will cause untracked files to be
overwritten.
Instead, assume the empty tree for HEAD and do a regular merge. An
untracked file will cause the merge to abort and do nothing. If no
conflicting files are present, the merge will have the same effect
as a hard reset.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change submodule tests that piped to diff(1) to use test_cmp. The
resulting unified diff is easier to read.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split the "message in editor has initial comment" test into three
tests. The motivation is to be able to only skip the middle part under
NO_GETTEXT_POISON.
In addition the return value of 'git tag' was being returned. We now
check that it's non-zero. I used ! instead of test_must_fail so that
the GIT_EDITOR variable was only used in this command invocation, and
because the surrounding tests use this style.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new boolean "fetchRecurseSubmodules" config option controls the
behavior for "git fetch" and "git pull". It specifies if these commands
should recurse into submodules and fetch new commits there too and can be
set separately for each submodule.
In the .gitmodules file "submodule.<name>.fetchRecurseSubmodules" entries
are read before looking for them in .git/config. Thus settings found in
.git/config will override those from .gitmodules, thereby allowing the
user to ignore settings given by the remote side while also letting
upstream set reasonable defaults for those users who don't have special
needs.
This configuration can be overridden by the command line option
"--[no-]recurse-submodules" of "git fetch" and "git pull".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new boolean option can be used to override the default for "git
fetch" and "git pull", which is to not recurse into populated submodules
and fetch all new commits there too.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Until now you had to call "git submodule update" (without -N|--no-fetch
option) or something like "git submodule foreach git fetch" to fetch
new commits in populated submodules from their remote.
This could lead to "(commits not present)" messages in the output of
"git diff --submodule" (which is used by "git gui" and "gitk") after
fetching or pulling new commits in the superproject and is an obstacle for
implementing recursive checkout of submodules. Also "git submodule
update" cannot fetch changes when disconnected, so it was very easy to
forget to fetch the submodule changes before disconnecting only to
discover later that they are needed.
This patch adds the "--recurse-submodules" option to recursively fetch
each populated submodule from the url configured in the .git/config of the
submodule at the end of each "git fetch" or during "git pull" in the
superproject. The submodule paths are taken from the index.
The hidden option "--submodule-prefix" is added to "git fetch" to be able
to print out the full paths of nested submodules.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an initial --in-reply-to is supplied, make it apply only to the
first message; --[no-]chain-reply-to setting are honored by second and
subsequent messages; this is also how the git-format-patch option with
the same name behaves.
Moreover, when $initial_reply_to is asked to the user interactively it
is asked as the "Message-ID to be used as In-Reply-To for the _first_
email", this makes the user think that the second and subsequent
patches are not using it but are considered as replies to the first
message or chained according to the --[no-]chain-reply setting.
Look at the v2 series in the illustration to see what the new behavior
ensures:
(before the patch) | (after the patch)
[PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation | [PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation
This is the typical behaviour we want when we send a series with cover
letter in reply to some discussion, the new patch series should appear
as a separate subtree in the discussion.
Also update the documentation on --in-reply-to to describe the new
behavior.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have always been creating rfc1991 signatures for users with "rfc1991"
in their gpg config but failed to recognize them (tag -l -n largenumber)
and verify them (tag -v, verify-tag).
Make good use of the refactored signature detection and let us recognize
and verify those signatures also.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, git expects "-----BEGIN PGP SIGNATURE-----" at the beginning of a
signature. But gpg uses "MESSAGE" instead of "SIGNATURE" when used with
the "rfc1991" option. This leads to git's failing to verify it's own
signed tags, among other problems.
Add tests for all code paths (tag -v, tag -l -n largenumber, tag -f
without -m) where signature detection matters.
Reported-by: Stephan Hugel <urschrei@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A stat-dirty index is not a detail that ought to concern the operator
of porcelain such as "git cherry-pick".
Without this change, a cherry-pick after copying a worktree with rsync
errors out with a misleading message.
$ git cherry-pick build/top
error: Your local changes to 'file.h' would be overwritten by merge. Aborting.
Please, commit your changes or stash them before you can merge.
Noticed-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some patches have a timezone formatted like '-08:00' instead of
'-0800' in their ---/+++ lines (e.g. http://lwn.net/Articles/131729/).
Take this into account when searching for the start of the timezone
(which is the end of the filename).
This does not actually affect the outcome of patching unless (1) a
file being patched has a non-' ' whitespace character (e.g., tab) in
its filename, or (2) the patch is whitespace-damaged, so the tab
between filename and timestamp has been replaced with spaces.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use test_might_fail instead of ignoring the exit status from git
config --unset, and let the exit status propagate past rm -f (which
does not fail on ENOENT). Otherwise bugs that lead git config to
crash would not be detected when this test runs.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The same code to check the position of HEAD is used by several
tests in this script. Factor it out as a function and simplify it.
Noticed using an &&-chaining tester, because the current code
does not propagate the precise exit status from errors.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a comment describing the setup in t3404 to its --help output.
This should make it easier to decide where to put new functions
without disrupting the flow of the file or obstructing the description
of the test setup.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow test_commit failures in loop iterations before the last one to
cause the test assertion to fail.
More importantly, avoiding these loops makes the test a little
simpler to read and decreases the vertical screen footprint of
the setup test assertion by one line.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the test_expect_code helper instead of open-coding it.
The main behavior change is to print the command and actual exit
status when the test fails. More importantly, this would make it
easier to add commands before "git notes show" as part of the
same test assertion if needed.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As t/README explains:
When a gitcommand dies due to a segfault, test_must_fail
diagnoses it as an error; "! git <command>" treats it as
just another expected failure, which would let such a bug
go unnoticed.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse --parseopt exits with code 129 (usage error) when asked
to dump usage with -h on behalf of another command. Scripts can
take advantage of this to avoid trying to parse usage information
as though it were the regular output from some git command.
Noticed with an &&-chaining tester.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using 'return' in an attempt to end a test assertion can have
unpredictable results (probably escaping from test_run_ and breaking
its bookkeeping). Redo the control flow using helpers like
test_expect_code and git diff --exit-code, so each test assertion can
follow the usual form
command that should succeed &&
command that should succeed &&
command that should succeed &&
...
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some tests check their output with code like the following:
test "$(git ls-files -u B | wc -l)" -eq 3 || {
echo "BAD: should have left stages for B"
return 1
}
The verbose failure condition is used because test, unlike
diff, does not print any useful information about the
nature of the failure when it fails.
Introduce a test_line_count function to help. If used like
git ls-files -u B >output &&
test_line_count -eq 3 output
it will produce output like
test_line_count: line count for output !-eq 3
100644 b023018cabc396e7692c70bbf5784a93d3f738ab 2 hi.c
100644 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 3 hi.c
on failure.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Same rules as before: this patch only adds " &&" to the end of
some lines in the test suite.
Intended to be applied on top of or squashed with the last
batch if they look okay.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Breaks in a test assertion's && chain can potentially hide
failures from earlier commands in the chain.
Commands intended to fail should be marked with !, test_must_fail, or
test_might_fail. The examples in this patch do not require that.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support lines of the form "fixup! 7a235b" that specify an exact commit
in addition to the normal "squash! Old commit message" form.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current behvaior of --autosquash can duplicate fixup!/squash! lines
if they match multiple commits, and it can also apply them to commits
that come after them in the todo list. Even more oddly, a commit that
looks like "fixup! fixup!" will match itself and be duplicated in the
todo list.
Change the todo list rearranging to mark all commits as used as soon
as they are emitted, and to avoid emitting a fixup/squash commit if the
commit has already been marked as used.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit c84de70 (excluded_1(): support exclude files in index -
2009-08-20) tries to work around the fact that there is no
directory/file information in index entries, therefore
EXC_FLAG_MUSTBEDIR match would fail.
Unfortunately the workaround is flawed. This fixes it.
Reported-by: Thomas Rinderknecht <thomasr@sailguy.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1. When --in-reply-to gives $reply_to, the first one becomes a reply to
that message, with or without --chain-reply-to.
2. When --chain-reply-to is in effect, all the messages are strung
together to form a single chain. The first message may be in reply to
the $reply_to given by --in-reply-to command line option (see
previous), or the root of the discussion thread. The second one is a
response to the first one, and the third one is a response to the
second one, etc.
3. When --chain-reply-to is not in effect:
a. When --in-reply-to is used, too, the second and the subsequent ones
become replies to $reply_to. Together with the first rule, all
messages become replies to $reply_to given by --in-reply-to.
b. When --in-reply-to is not used, presumably the second and
subsequent ones become replies to the first one, which would be the
root.
The documentation is reasonably clear about the 1., 2. and 3a. above, I
think, even though I do not think 3b. is clearly specified.
The two tests added by this patch at least documents what happens between
these two options.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7500: test expected behavior of commit --squash
t3415: test interaction of commit --squash with rebase --autosquash
t3900: test commit --squash with i18n encodings
Signed-off-by: Pat Notz <patnotz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7500: test expected behavior of commit --fixup
t3415: test interaction of commit --fixup with rebase --autosquash
t3900: test commit --fixup with i18n encodings
Signed-off-by: Pat Notz <patnotz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recursive invocations of submodule update/status preserve all arguments,
so executing
git submodule update --recursive -- foo
attempts to recursively update a submodule named "foo".
Naturally, this fails as one cannot have an infinitely-deep stack of
submodules each containing a submodule named "foo". The desired behavior
is instead to update foo and then recursively update all submodules
inside of foo.
This commit accomplishes that by only saving the flags for use in the
recursive invocation.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell variables only hold strings, not lists of parameters,
so $orig_args after
orig_args="$@"
fails to remember where each parameter starts and ends, if
some include whitespace. So
git submodule update \
--reference='/var/lib/common objects.git' \
--recursive --init
becomes
git submodule update --reference=/var/lib/common \
objects.git --recursive --init
in the inner repositories. Use "git rev-parse --sq-quote" to
save parameters in quoted form ready for evaluation by the
shell, avoiding this problem.
Helped-By: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(Just like we did for documentation already)
In the process, we change "non-remote branch" to "branch outside the
refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch".
The new formulation actually corresponds to how the code detects this
case (i.e. prefixcmp(refname, "refs/remotes")).
Also, we use 'remote-tracking branch' in generated merge messages (by
merge an fmt-merge-msg).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To complement the straightforward perl application in previous patch,
this adds a few manual changes.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
