Teach commands in the "log" family to optionally pay attention to
the mailmap.
* ap/log-mailmap:
log --use-mailmap: optimize for cases without --author/--committer search
log: add log.mailmap configuration option
log: grep author/committer using mailmap
test: add test for --use-mailmap option
log: add --use-mailmap option
pretty: use mailmap to display username and email
mailmap: add mailmap structure to rev_info and pp
mailmap: simplify map_user() interface
mailmap: remove email copy and length limitation
Use split_ident_line to parse author and committer
string-list: allow case-insensitive string list
This header not only declares but also defines the contents of the
array that holds the list of command names and help text. Do not
include it in multiple places to waste text space.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for a pre-push hook which can be used to determine if the
set of refs to be pushed is suitable for the target repository. The
hook is run with two arguments specifying the name and location of the
destination repository.
Information about what is to be pushed is provided by sending lines of
the following form to the hook's standard input:
<local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
If the hook exits with a non-zero status, the push will be aborted.
This will allow the script to determine if the push is acceptable based
on the target repository and branch(es), the commits which are to be
pushed, and even the source branches in some cases.
Signed-off-by: Aaron Schrab <aaron@schrab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resetting with paths, we no longer require a commit argument, but
only a tree-ish. Update the documentation and synopsis accordingly.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tracking system recognise
a token of #<bugid> form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a choice between
- Don't do it. Avoid such a line by rewrapping or indenting; and
- Use --cleanup=whitespace but remove all the hint lines we add.
Give them a way to set a custom comment char, e.g.
$ git -c core.commentchar="%" commit
so that they do not have to do either of the two workarounds.
[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consumers of the dir.c traversal API should avoid assuming knowledge
of the internal implementation of exclude_list_groups. Therefore
when adding items to an exclude list, it should be accessed via the
pointer returned from add_exclude_list(), rather than by referencing
a location within dir.exclude_list_groups[EXC_CMDL].
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
2009-05-20), resetting with paths is much faster than resetting
without paths. Some timings for the linux-2.6 repo to illustrate this
(best of five, warm cache):
reset reset .
real 0m0.219s 0m0.080s
user 0m0.140s 0m0.040s
sys 0m0.070s 0m0.030s
These two commands should do the same thing, so instead of having the
user type the trailing " ." to get the faster do_diff_cache()-based
implementation, always use it when doing a mixed reset, with or
without paths (so "git reset $rev" would also be faster).
Timing "git reset" shows that it indeed becomes as fast as
"git reset ." after this patch.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users seem to think, knowingly or not, that being on an unborn
branch is like having a commit with an empty tree checked out, but
when run on an unborn branch, "git reset" currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Instead of making users figure out that they should run
git rm --cached -r .
, let's teach "git reset" without a revision argument, when on an
unborn branch, to behave as if the user asked to reset to an empty
tree. Don't take the analogy with an empty commit too far, though, but
still disallow explictly referring to HEAD in "git reset HEAD".
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting with paths does not update HEAD and there is nothing else
that a commit should be needed for. Relax the argument parsing so only
a tree is required.
The sha1 is only passed to read_from_tree(), which already only
requires a tree.
The "rev" variable we pass to run_add_interactive() will resolve to a
tree. This is fine since interactive_reset only needs the parameter to
be a treeish and doesn't use it for display purposes.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that there is only one caller left to the single-line method
update_index_refresh(), inline it.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By not returning from inside the "if (pathspec)" block, we can let the
pathspec-aware and pathspec-less code share a bit more, making it
easier to make future changes that should affect both cases. This also
highlights the similarity between read_from_tree() and reset_index().
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When doing a mixed reset without paths, the index is locked, read,
reset, and written back as part of the actual reset operation (in
reset_index()). Then, when showing the list of worktree modifications,
we lock the index again, refresh it, and write it.
Change this so we only write the index once, making "git reset" a
little faster. It does mean that the index lock will be held a little
longer, but the difference is small compared to the time spent
refreshing the index.
There is one minor functional difference: We used to say "Could not
write new index file." if the first write failed, and "Could not
refresh index" if the second write failed. Now, we will only use the
first message.
This speeds up "git reset" a little on the linux-2.6 repo (best of
five, warm cache):
Before After
real 0m0.239s 0m0.214s
user 0m0.160s 0m0.130s
sys 0m0.070s 0m0.080s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In preparation for the/a following patch, move the locking, writing
and committing of the index file out of update_index_refresh(). The
code duplication caused will soon be taken care of. What remains of
update_index_refresh() is just one line, but it is still called from
two places, so let's leave it for now.
In the process, we expose and fix the minor UI bug that makes us print
"Could not refresh index" when we fail to write the index file when
invoked with a pathspec. Copy the error message from the pathspec-less
codepath ("Could not write new index file.").
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The final part of cmd_reset() essentially looks like:
if (pathspec) {
...
read_from_tree(...);
} else {
...
reset_index(...);
update_index_refresh(...);
...
}
where read_from_tree() internally also calls
update_index_refresh(). Move the call to update_index_refresh() out of
read_from_tree for symmetry with the 'else' block, making
read_from_tree() and reset_index() closer in functionality.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The switch statement towards the end of reset.c is missing case arms
for KEEP and MERGE for no obvious reason, and soon the only non-empty
case arm will be the one for HARD. So let's proactively replace it by
if-else, which will let us move one if statement out without leaving
funny-looking left-overs.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If writing or committing the new index file fails, we print "Could not
write new index file." followed by "Could not reset index file to
revision $rev.". The first message seems to imply the second, so print
only the first message.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reset --keep" calls reset_index_file() twice, first doing a
two-way merge to the target revision, updating the index and worktree,
and then resetting the index. After each call, we write the index
file.
In the unlikely event that the second call to reset_index_file()
fails, the index will have been merged to the target revision, but
HEAD will not be updated, leaving the user with a dirty index.
By moving the locking, writing and committing out of
reset_index_file() and into the caller, we can avoid writing the index
twice, thereby making the sure we don't end up in the half-way reset
state. As a bonus, we speed up "git reset --keep" a little on the
linux-2.6 repo (best of five, warm cache):
Before After
real 0m0.315s 0m0.296s
user 0m0.290s 0m0.280s
sys 0m0.020s 0m0.010s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use a single condition to guard the call to die_if_unmerged_cache for
both --soft and --keep. This avoids the small distraction of the
precondition check from the logic following it.
Also change an instance of
if (e)
err = err || f();
to the almost as short, but clearer
if (e && !err)
err = f();
(which is equivalent since we only care whether exit code is 0)
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By extracting the code for updating the HEAD and ORIG_HEAD symbolic
references to a separate function, we declutter cmd_reset() a bit and
we make it clear that e.g. the four variables {,sha1_}{,old_}orig are
only used by this code.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Throughout most of parse_args(), the variable 'i' remains at 0. Many
references are still made to the variable even when it could only have
the value 0. This made at least me, who has relatively little
experience with C programming styles, think that parts of the function
was meant to be part of a loop. To avoid such confusion, remove the
variable and also the 'argc' parameter and check for NULL trailing
argv instead.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Declutter cmd_reset() a bit by moving out the argument parsing to its
own function.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running e.g. "git reset ." in a bare repo results in an index file
being created from the HEAD commit. The differences compared to the
index are then printed as usual, but since there is no worktree, it
will appear as if all files are deleted. For example, in a bare clone
of git.git:
Unstaged changes after reset:
D .gitattributes
D .gitignore
D .mailmap
...
This happens because the check for is_bare_repository() happens after
we branch off into read_from_tree() to reset with paths. Fix by moving
the branching point after the check.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We use the path arguments in two places in reset.c: in
interactive_reset() and read_from_tree(). Both of these call
get_pathspec(), so we pass the (prefix, argv) pair to both
functions. Move the call to get_pathspec() out of these methods, for
two reasons: 1) One argument is simpler than two. 2) It lets us use
the (arguably clearer) "if (pathspec)" in place of "if (i < argc)".
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reset $pathspec" currently exits with a non-zero exit code if the
worktree is dirty after resetting, which is inconsistent with reset
without pathspec, and it makes it harder to know whether the command
really failed. Change it to exit with code 0 regardless of whether the
worktree is dirty so that non-zero indicates an error.
This makes the 4 "disambiguation" test cases in t7102 clearer since
they all used to "fail", 3 of which "failed" due to changes in the
work tree. Now only the ambiguous one fails.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 34110cd (Make 'unpack_trees()' have a separate source and
destination index, 2008-03-06), the index no longer gets clobbered by
do_diff_cache() and we can remove the code for discarding and
re-reading it.
There are two paths to update_index_refresh() from cmd_reset(), but on
both paths, either read_cache() or read_cache_unmerged() will have
been called, so the call to read_cache() in this method is redundant
(although practically free).
This speeds up "git reset -- ." a little on the linux-2.6 repo (best
of five, warm cache):
Before After
real 0m0.093s 0m0.080s
user 0m0.040s 0m0.020s
sys 0m0.050s 0m0.050s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create find_hook() function to determine if a given hook exists and is
executable. If it is, the path to the script will be returned,
otherwise NULL is returned.
This encapsulates the tests that are used to check for the existence of
a hook in one place, making it easier to modify those checks if that is
found to be necessary. This also makes it simple for places that can
use a hook to check if a hook exists before doing, possibly lengthy,
setup work which would be pointless if no such hook is present.
The returned value is left as a static value from get_pathname() rather
than a duplicate because it is anticipated that the return value will
either be used as a boolean, immediately added to an argv_array list
which would result in it being duplicated at that point, or used to
actually run the command without much intervening work. Callers which
need to hold onto the returned value for a longer time are expected to
duplicate the return value themselves.
Signed-off-by: Aaron Schrab <aaron@schrab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(1) Only print out the names of the files and directories that got
actually deleted. Also do not mention that we are not removing
directories when the user did not ask us to do so with '-d'.
(2) Show ignore message for skipped untracked git repositories.
Consider the following repo layout:
test.git/
|-- tracked_dir/
| |-- some_tracked_file
| |-- some_untracked_file
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| |-- frotz.tx
|-- untracked_some.git/
|-- some.txt
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/
Removing untracked_some.git/
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
to run in both dry_run and delete modes with the delete logic as
follows:
(a) Check if the current directory to be deleted is an untracked
git repository. If it is and --force --force option is not set
do not touch this directory, print ignore message, set dir_gone
flag to false for the caller and return.
(b) Otherwise for each item in current directory:
(i) If current directory cannot be accessed, print warning,
set dir_gone flag to false and return.
(ii) If the item is a subdirectory recurse into it,
check for the returned value of the dir_gone flag.
If the subdirectory is gone, add the name of the deleted
directory to a list of successfully removed items 'dels'.
Else set the dir_gone flag as the current directory
cannot be removed because we have at least one subdirectory
hanging around.
(iii) If it is a file try to remove it. If success add the
file name to the 'dels' list, else print error and set
dir_gone flag to false.
(c) After we finished deleting all items in the current directory and
the dir_gone flag is still true, remove the directory itself.
If failed set the dir_gone flag to false.
(d) If the current directory cannot be deleted because the dir_gone flag
has been set to false, print out all the successfully deleted items
for this directory from the 'dels' list.
(e) We're done with the current directory, return.
(2) Modify the cmd_clean() function to:
(a) call the recursive delete function 'remove_dirs()' for each
topmost directory it wants to remove
(b) check for the returned value of dir_gone flag. If it's true
print the name of the directory as being removed.
Consider the output of the improved version:
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Skipping repository untracked_foo/frotz.git
Removing untracked_foo/bar
Removing untracked_foo/emptydir
Skipping repository untracked_some.git/
Now it displays only the file and directory names that got actually
deleted and shows the name of the untracked git repositories it ignored.
Reported-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created. This
was most visible when interrupting a submodule update.
* jl/interrupt-clone-remove-separate-git-dir:
clone: support atomic operation with --separate-git-dir
"git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* jc/maint-fmt-merge-msg-no-edit-lose-credit:
merge --no-edit: do not credit people involved in the side branch
"git apply" misbehaved when fixing whitespace breakages by removing
excess trailing blank lines.
* jc/apply-trailing-blank-removal:
apply.c:update_pre_post_images(): the preimage can be truncated
Update the disused merge-tree proof-of-concept code.
* jc/merge-blobs:
merge-tree: fix d/f conflicts
merge-tree: add comments to clarify what these functions are doing
merge-tree: lose unused "resolve_directories"
merge-tree: lose unused "flags" from merge_list
Which merge_file() function do you mean?
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
* jc/format-patch-reroll:
format-patch: give --reroll-count a short synonym -v
format-patch: document and test --reroll-count
format-patch: add --reroll-count=$N option
get_patch_filename(): split into two functions
get_patch_filename(): drop "just-numbers" hack
get_patch_filename(): simplify function signature
builtin/log.c: stop using global patch_suffix
builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* ap/merge-stop-at-prepare-commit-msg-failure:
merge: Honor prepare-commit-msg return code
Earlier, dc87183 (use GIT_CONFIG only in "git config", not other
programs, 2008-06-30) made sure that the environment variable is
never used outside "git config", but "git clone", after creating a
directory for the new repository and until the init_db() function
populates its .git/ directory, exported the variable for no good
reason. No hook will run from init_db() and more importantly no
hook can run until init_db() finishes creation of the new
repository, so it cannot be used by any invocation of "git config"
by definition.
Stop doing the useless export/unexport.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can do --depth=2147483647 (*) for restoring complete repo
now. But it's hard to remember. Any other numbers larger than the
longest commit chain in the repository would also do, but some
guessing may be involved. Make easy-to-remember --unshallow an alias
for --depth=2147483647.
Make upload-pack recognize this special number as infinite depth. The
effect is essentially the same as before, except that upload-pack is
more efficient because it does not have to traverse to the bottom
anymore.
The chance of a user actually wanting exactly 2147483647 commits
depth, not infinite, on a repository with a history that long, is
probably too small to consider. The client can learn to add or
subtract one commit to avoid the special treatment when that actually
happens.
(*) This is the largest positive number a 32-bit signed integer can
contain. JGit and older C Git store depth as "int" so both are OK
with this number. Dulwich does not support shallow clone.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --separate-git-dir option was introduced to make it simple to put
the git directory somewhere outside the worktree, for example when
cloning a repository for use as a submodule.
It was not intended for use when creating a bare repository. In that
case there is no worktree and it is more natural to directly clone the
repository and create a .git file as separate steps:
git clone --bare /path/to/repo.git bar.git
printf 'gitdir: bar.git\n' >foo.git
Forbid the combination, making the command easier to explain.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git clone --separate-git-dir" is interrupted, we failed to
remove the real location we created the repository.
* jl/interrupt-clone-remove-separate-git-dir:
clone: support atomic operation with --separate-git-dir
Refactor and generally clean up the directory traversal API
implementation.
* as/dir-c-cleanup:
dir.c: rename free_excludes() to clear_exclude_list()
dir.c: refactor is_path_excluded()
dir.c: refactor is_excluded()
dir.c: refactor is_excluded_from_list()
dir.c: rename excluded() to is_excluded()
dir.c: rename excluded_from_list() to is_excluded_from_list()
dir.c: rename path_excluded() to is_path_excluded()
dir.c: rename cryptic 'which' variable to more consistent name
Improve documentation and comments regarding directory traversal API
api-directory-listing.txt: update to match code
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit", which will be discarded
anyway.
* jc/maint-fmt-merge-msg-no-edit-lose-credit:
merge --no-edit: do not credit people involved in the side branch
Teach "log.mailmap" configuration variable to turn "--use-mailmap"
option on to "git log", "git show" and "git whatchanged".
The "--no-use-mailmap" option from the command line can countermand
the setting.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --use-mailmap option to log commands. It allows to display
names from mailmap file when displaying logs, whatever the format
used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simplify map_user(), mostly to avoid copies of string buffers. It
also simplifies caller functions.
map_user() directly receive pointers and length from the commit buffer
as mail and name. If mapping of the user and mail can be done, the
pointer is updated to a new location. Lengths are also updated if
necessary.
The caller of map_user() can then copy the new email and name if
necessary.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach various forms of "format-patch" command line to identify what
branch the patches are taken from, so that the branch description
is picked up in more cases.
* nd/maint-branch-desc-doc:
format-patch: pick up branch description when no ref is specified
format-patch: pick up correct branch name from symbolic ref
t4014: a few more tests on cover letter using branch description
branch: delete branch description if it's empty
config.txt: a few lines about branch.<name>.description
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook. t7505 may want a general clean-up but that is
a different topic.
* ap/merge-stop-at-prepare-commit-msg-failure:
merge: Honor prepare-commit-msg return code
Currently blame.c::get_acline(), pretty.c::pp_user_info() and
shortlog.c::insert_one_record() are parsing author name, email, time
and tz themselves.
Use ident.c::split_ident_line() for better code reuse.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
* jc/apply-trailing-blank-removal:
apply.c:update_pre_post_images(): the preimage can be truncated
This will be reused by a new git check-ignore command.
Also document validate_pathspec().
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extract the body of the for loop in treat_gitlinks() into a separate
check_path_for_gitlink() function so that it can be reused elsewhere.
This paves the way for a new check-ignore sub-command.
Also document treat_gitlinks().
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perform the following function renames to make it explicit that these
pathspec handling functions are for matching against the index, rather
than against a tree or the working directory.
- fill_pathspec_matches() -> add_pathspec_matches_against_index()
- find_used_pathspec() -> find_pathspecs_matching_against_index()
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extract the following functions from builtin/add.c to pathspec.c, in
preparation for reuse by a new git check-ignore command:
- fill_pathspec_matches()
- find_used_pathspec()
The functions being extracted are not changed in any way, except
removal of the 'static' qualifier.
Also add comments documenting these newly public functions,
including clarifications that they operate on the index.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'argc' argument passed to validate_pathspec() was never used.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For exclude patterns read in from files, the filename is stored in the
exclude list, and the originating line number is stored in the
individual exclude (counting starting at 1).
For exclude patterns provided on the command line, a string describing
the source of the patterns is stored in the exclude list, and the
sequence number assigned to each exclude pattern is negative, with
counting starting at -1. So for example the 2nd pattern provided via
--exclude would be numbered -2. This allows any future consumers of
that data to easily distinguish between exclude patterns from files
vs. from the CLI.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously each exclude_list could potentially contain patterns
from multiple sources. For example dir->exclude_list[EXC_FILE]
would typically contain patterns from .git/info/exclude and
core.excludesfile, and dir->exclude_list[EXC_DIRS] could contain
patterns from multiple per-directory .gitignore files during
directory traversal (i.e. when dir->exclude_stack was more than
one item deep).
We split these composite exclude_lists up into three groups of
exclude_lists (EXC_CMDL / EXC_DIRS / EXC_FILE as before), so that each
exclude_list now contains patterns from a single source. This will
allow us to cleanly track the origin of each pattern simply by adding
a src field to struct exclude_list, rather than to struct exclude,
which would make memory management of the source string tricky in the
EXC_DIRS case where its contents are dynamically generated.
Similarly, by moving the filebuf member from struct exclude_stack to
struct exclude_list, it allows us to track and subsequently free
memory buffers allocated during the parsing of all exclude files,
rather than only tracking buffers allocated for files in the EXC_DIRS
group.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Require "-f" for push to update a tag, even if it is a fast-forward.
* cr/push-force-tag-update:
push: allow already-exists advice to be disabled
push: rename config variable for more general use
push: cleanup push rules comment
push: clarify rejection of update to non-commit-ish
push: require force for annotated tags
push: require force for refs under refs/tags/
push: flag updates that require force
push: keep track of "update" state separately
push: add advice for rejected tag reference
push: return reject reasons as a bitset
Various updates to fast-export used in the context of the remote
helper interface.
* fc/fast-export-fixes:
fast-export: make sure updated refs get updated
fast-export: don't handle uninteresting refs
fast-export: fix comparison in tests
fast-export: trivial cleanup
remote-testgit: implement the "done" feature manually
remote-testgit: report success after an import
remote-testgit: exercise more features
remote-testgit: cleanup tests
remote-testgit: remove irrelevant test
remote-testgit: remove non-local functionality
Add new simplified git-remote-testgit
Rename git-remote-testgit to git-remote-testpy
remote-helpers: fix failure message
remote-testgit: fix direction of marks
fast-export: avoid importing blob marks
Optimize matching paths with common forms of pathspecs that contain
wildcard characters.
* nd/pathspec-wildcard:
tree_entry_interesting: do basedir compare on wildcard patterns when possible
pathspec: apply "*.c" optimization from exclude
pathspec: do exact comparison on the leading non-wildcard part
pathspec: save the non-wildcard length part
Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
git clone supports the --separate-git-dir option to create the git dir
outside the work tree. But when that option is used, the git dir won't be
deleted in case the clone fails like it would be without this option. This
makes clone lose its atomicity as in case of a failure a partly set up git
dir is left behind. A real world example where this leads to problems is
when "git submodule update" fails to clone a submodule and later calls to
"git submodule update" stumble over the partially set up git dir and try
to revive the submodule from there, which then fails with a not very user
friendly error message.
Fix that by updating the junk_git_dir variable (used to remember if and
what git dir should be removed in case of failure) to the new value given
with the --seperate-git-dir option. Also add a test for this to t5600 (and
while at it fix the former last test to not cd into a directory to test
for its existence but use "test -d" instead).
Reported-by: Manlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
As I do not think of a reason why users would want to tell the
command to be "verbose", I think this should be OK.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
make "git commit" and "git merge" consistent, because a merge that
required user assistance has to be concluded with "git commit", but
back then only "git commit" triggered prepare-commit-msg hook.
When it added a call to run the prepare-commit-msg hook, however, it
forgot to check the exit code from the hook like "git commit" does,
and ended up replacing one inconsistency with another.
When prepare-commit-msg hook that is run from "git merge" exits with
a non-zero status, abort the commit.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_branch_name() assumes to take refs/heads/<branch>. But we also
have symbolic refs, such as HEAD, that can point to a valid branch in
refs/heads and do not follow refs/heads/<branch> syntax. Remove the
assumption and apply normal ref resolution. After all it would be
confusing if rev machinery resolves a ref in one way and
find_branch_name() another.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
* sp/shortlog-missing-lf:
strbuf_add_wrapped*(): Remove unused return value
shortlog: fix wrapping lines of wraplen
The credit lines "By" and "Via" to credit authors and committers for
their contributions on the side branch are meant as a hint to the
integrator to decide whom to mention in the log message text. After
the integrator saves the message in the editor, they are meant to go
away and that is why they are commented out.
When a merge is recorded without editing the generated message,
however, its contents do not go through the normal stripspace()
and these lines are left in the merge.
Stop producing them when we know the merge is going to be recorded
without editing, i.e. when --no-edit is given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Start adopting clearer names for exclude functions. This 'is_*'
naming pattern for functions returning booleans was agreed here:
http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=204924
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit documented two known breakages revolving around
a case where one side flips a tree into a blob (or vice versa),
where the original code simply gets confused and feeds a mixture of
trees and blobs into either the recursive merge-tree (and recursing
into the blob will fail) or three-way merge (and merging tree contents
together with blobs will fail).
Fix it by feeding trees (and only trees) into the recursive
merge-tree machinery and blobs (and only blobs) into the three-way
content level merge machinery separately; when this happens, the
entire merge has to be marked as conflicting at the structure level.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename the "branch1" parameter given to resolve() to "ours", to
clarify what is going on. Also, annotate the unresolved_directory()
function with some comments to show what decisions are made in each
step, and highlight two bugs that need to be fixed.
Add two tests to t4300 to illustrate these bugs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --reroll-count=$N option, when given a positive integer:
- Adds " v$N" to the subject prefix specified. As the default
subject prefix string is "PATCH", --reroll-count=2 makes it
"PATCH v2".
- Prefixes "v$N-" to the names used for output files. The cover
letter, whose name is usually 0000-cover-letter.patch, becomes
v2-0000-cover-letter.patch when given --reroll-count=2.
This allows users to use the same --output-directory for multiple
iterations of the same series, without letting the output for a
newer round overwrite output files from the earlier rounds. The
user can incorporate materials from earlier rounds to update the
newly minted iteration, and use "send-email v2-*.patch" to send out
the patches belonging to the second iteration easily.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function switched between two operating modes depending on the
NULL-ness of its two parameters, as a hacky way to share small part
of implementation, sacrificing cleanliness of the API.
Implement "fmt_output_subject()" function that takes a subject
string and gives the name for the output file, and on top of it,
implement "fmt_output_commit()" function that takes a commit and
gives the name for the output file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function chooses from three operating modes (format using the
subject, the commit, or just number) based on NULL-ness of two of
its parameters, which is an ugly hack for sharing only a bit of
code.
Separate out the "just numbers" part out to the callers.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most functions that emit to a strbuf take the strbuf as their first
parameter; make this function follow suit.
The serial number of the patch being emitted (nr) and suffix used
for patch filename (suffix) are both recorded in rev_info; drop
these separate parameters and pass the rev_info directly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The suffix for the output filename is found in rev->patch_suffix; do
not keep using the global that is only used to parse the command
line and configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently it gets the size of an otherwise unrelated, unused variable
instead of the expected struct size.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A recent commit [1] fixed a off-by-one wrapping error. As a
side-effect, the conditional in add_wrapped_shortlog_msg() to decide
whether to append a newline needs to be removed. The function
should always append a newline, which was the case before the
off-by-one fix, because strbuf_add_wrapped_text() never returns a
value of wraplen; when it returns wraplen, the string does not end
with a newline, so this caller needs to add one anyway.
[1] 14e1a4e1ff utf8: fix off-by-one
wrapping of text
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are two different static functions and one global function,
all of them called "merge_file()", with different signatures and
purposes. Rename them all to reduce confusion in "git grep" output:
* Rename the static one in merge-index to "merge_one_path(const char
*path)" as that function is about asking an external command to
resolve conflicts in one path.
* Rename the global one in merge-file.c that is only used by
merge-tree to "merge_blobs()", as the function takes three blobs and
returns the merged result only in-core, without doing anything to
the filesystem.
* Rename the one in merge-recursive to "merge_one_file()", just to be
fair.
Also rename merge-file.[ch] to merge-blobs.[ch].
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* jc/same-encoding:
reencode_string(): introduce and use same_encoding()
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice. Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter. This behavior is oriented to
branches which are expected to move with commits. Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections are for branches, just
tell the user the reference already exists.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
General clean-ups in various areas, originally written to support a
patch that later turned out to be unneeded.
* jk/send-email-sender-prompt:
t9001: check send-email behavior with implicit sender
t: add tests for "git var"
ident: keep separate "explicit" flags for author and committer
ident: make user_ident_explicitly_given static
t7502: factor out autoident prerequisite
test-lib: allow negation of prerequisites
Finishing touches to "git rm $submodule" that removes the working
tree of a submodule.
* jl/submodule-rm:
Teach rm to remove submodules when given with a trailing '/'
Setting 'commit' to 'commit' is a no-op. It might have been there to
avoid a compiler warning, but if so, it was the compiler to blame, and
it's certainly not there any more.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that was previously stored by fast-import.
There is no point in one tool saving blobs, and the other not, but for
now let's just check in fast-export that the objects are indeed commits.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Doing a "git rm submod/" on a submodule results in an error:
fatal: pathspec 'submod/' did not match any files
This is really inconvenient as e.g. using TAB completion in a shell on a
submodule automatically adds the trailing '/' when it completes the path
of the submodule directory. The user has then to remove the '/' herself to
make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so
there is no reason why that shouldn't work for submodules too.
Teach git rm to not error out when a '/' is appended to the path of a
submodule. Achieve this by chopping off trailing slashes from the path
names given if they represent directories. Add tests to make sure that
logic only applies to directories and not to files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Drop duplicate detection from "git-config --get"; this lets it
better match the internal config callbacks, which clears up some
corner cases with includes.
* jk/config-ignore-duplicates:
builtin/config.c: Fix a sparse warning
git-config: use git_config_with_options
git-config: do not complain about duplicate entries
git-config: collect values instead of immediately printing
git-config: fix regexp memory leaks on error conditions
git-config: remove memory leak of key regexp
t1300: test "git config --get-all" more thoroughly
t1300: remove redundant test
t1300: style updates
"git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* cn/config-missing-path:
config: don't segfault when given --path with a missing value
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
* kb/preload-index-more:
update-index/diff-index: use core.preloadindex to improve performance
We mark pathspec with wildcards with the field use_wildcard. We
could do better by saving the length of the non-wildcard part, which
can be used for optimizations such as f9f6e2c (exclude: do strcmp as
much as possible before fnmatch - 2012-06-07).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM instead.
* rs/branch-del-symref:
branch: show targets of deleted symrefs, not sha1s
branch: skip commit checks when deleting symref branches
branch: delete symref branch, not its target
branch: factor out delete_branch_config()
branch: factor out check_branch_commit()
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* nd/grep-true-path:
grep: stop looking at random places for .gitattributes
When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed. In case of an error however, trying to do
this will cause the program to be killed, as it's pointing to memory
in the stack.
Detect the error and return immediately to avoid freeing or accessing
the uninitialed memory in the stack.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We keep track of whether the user ident was given to us
explicitly, or if we guessed at it from system parameters
like username and hostname. However, we kept only a single
variable. This covers the common cases (because the author
and committer will usually come from the same explicit
source), but can miss two cases:
1. GIT_COMMITTER_* is set explicitly, but we fallback for
GIT_AUTHOR. We claim the ident is explicit, even though
the author is not.
2. GIT_AUTHOR_* is set and we ask for author ident, but
not committer ident. We will claim the ident is
implicit, even though it is explicit.
This patch uses two variables instead of one, updates both
when we set the "fallback" values, and updates them
individually when we read from the environment.
Rather than keep user_ident_sufficiently_given as a
compatibility wrapper, we update the only two callers to
check the committer_ident, which matches their intent and
what was happening already.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we switch to a new branch using checkout, we usually output a
message indicating what happened. However, when we switch from an unborn
branch to a new branch, we do not print anything, which may leave the
user wondering what happened.
The reason is that the unborn branch is a special case (see abe1998),
and does not follow the usual switch_branches code path. Let's add a
similar informational message to the special case to match the usual
code path.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Emit the notes attached to the commit in "format-patch --notes"
output after three-dashes.
* jc/prettier-pretty-note:
format-patch: add a blank line between notes and diffstat
Doc User-Manual: Patch cover letter, three dashes, and --notes
Doc format-patch: clarify --notes use case
Doc notes: Include the format-patch --notes option
Doc SubmittingPatches: Mention --notes option after "cover letter"
Documentation: decribe format-patch --notes
format-patch --notes: show notes after three-dashes
format-patch: append --signature after notes
pretty_print_commit(): do not append notes message
pretty: prepare notes message at a centralized place
format_note(): simplify API
pretty: remove reencode_commit_message()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* jc/same-encoding:
reencode_string(): introduce and use same_encoding()
Conflicts:
builtin/mailinfo.c
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
* jh/symbolic-ref-d:
git symbolic-ref --delete $symref
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Jeff King <peff@peff.net>
Code cleanups so that libgit.a does not depend on anything in the
builtin/ directory.
* nd/builtin-to-libgit:
fetch-pack: move core code to libgit.a
fetch-pack: remove global (static) configuration variable "args"
send-pack: move core code to libgit.a
Move setup_diff_pager to libgit.a
Move print_commit_list to libgit.a
Move estimate_bisect_steps to libgit.a
Move try_merge_command and checkout_fast_forward to libgit.a
Callers of reencode_string() that re-encodes a string from one
encoding to another all used ad-hoc way to bypass the case where the
input and the output encodings are the same. Some did strcmp(),
some did strcasecmp(), yet some others when converting to UTF-8 used
is_encoding_utf8().
Introduce same_encoding() helper function to make these callers use
the same logic. Notably, is_encoding_utf8() has a work-around for
common misconfiguration to use "utf8" to name UTF-8 encoding, which
does not match "UTF-8" hence strcasecmp() would not consider the
same. Make use of it in this helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'update-index --refresh' and 'diff-index' (without --cached) don't honor
the core.preloadindex setting yet. Porcelain commands using these (such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't preload index status if we don't
access the working copy (--cached).
Results with msysgit on WebKit repo (2GB in 200k files):
| update-index | diff-index | rebase
----------------+--------------+------------+---------
msysgit-v1.8.0 | 9.157s | 10.536s | 42.791s
+ preloadindex | 9.157s | 10.536s | 28.725s
+ this patch | 2.329s | 2.752s | 15.152s
+ fscache [1] | 0.731s | 1.171s | 8.877s
[1] https://github.com/kblees/git/tree/kb/fscache-v3
Thanks-to: Albert Krawczyk <pro-logic@optusnet.com.au>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Jeff King <peff@peff.net>
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
* rs/branch-del-symref:
branch: show targets of deleted symrefs, not sha1s
branch: skip commit checks when deleting symref branches
branch: delete symref branch, not its target
branch: factor out delete_branch_config()
branch: factor out check_branch_commit()
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
* nd/status-long:
status: add --long output format option
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* nd/grep-true-path:
grep: stop looking at random places for .gitattributes
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it;
the latter part teaches log to respect the grep.* configuration.
* jc/grep-pcre-loose-ends:
log: honor grep.* configuration
log --grep: accept --basic-regexp and --perl-regexp
log --grep: use the same helper to set -E/-F options as "git grep"
revisions: initialize revs->grep_filter using grep_init()
grep: move pattern-type bits support to top-level grep.[ch]
grep: move the configuration parsing logic to grep.[ch]
builtin/grep.c: make configuration callback more reusable
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
* jl/submodule-rm:
submodule: teach rm to remove submodules unless they contain a git directory
fetch_pack() is used by transport.c, part of libgit.a while it stays
in builtin/fetch-pack.c. Move it to fetch-pack.c so that we won't get
undefined reference if a program that uses libgit.a happens to pull it
in.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
This helps removes the hack in fetch_pack() that copies my_args to args.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
send_pack() is used by transport.c, part of libgit.a while it stays in
builtin/send-pack.c. Move it to send-pack.c so that we won't get
undefined reference if a program that uses libgit.a happens to pull it
in.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
This is used by diff-no-index.c, part of libgit.a while it stays in
builtin/diff.c. Move it to diff.c so that we won't get undefined
reference if a program that uses libgit.a happens to pull it in.
While at it, move check_pager from git.c to pager.c. It makes more
sense there and pager.c is also part of libgit.a
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
This is used by bisect.c, part of libgit.a while it stays in
builtin/rev-list.c. Move it to commit.c so that we won't get undefined
reference if a program that uses libgit.a happens to pull it in.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
This function is used by bisect.c, part of libgit.a while
estimate_bisect_steps stays in builtin/rev-list.c. Move it to bisect.a
so we won't have undefine reference if a standalone program that uses
libgit.a happens to pull it in.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
These functions are called in sequencer.c, which is part of
libgit.a. This makes libgit.a potentially require builtin/merge.c for
external git commands.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Sparse issues an "Using plain integer as NULL pointer" warning while
checking a 'struct strbuf_list' initializer expression. The initial
field of the struct has pointer type, but the initializer expression
is given as '{0}'. In order to suppress the warning, we simply replace
the initializer with '{NULL}'.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jeff King <peff@peff.net>
Speeds up "git upload-pack" (what is invoked by "git fetch" on the
other side of the connection) by reducing the cost to advertise the
branches and tags that are available in the repository.
* jk/peel-ref:
upload-pack: use peel_ref for ref advertisements
peel_ref: check object type before loading
peel_ref: do not return a null sha1
peel_ref: use faster deref_tag_noverify
The git-config command has always implemented its own file
lookup and parsing order. This was necessary because its
duplicate-entry handling did not match the way git's
internal callbacks worked. Now that this is no longer the
case, we are free to reuse the existing parsing code.
This saves us a few lines of code, but most importantly, it
means that the logic for which files are examined is
contained only in one place and cannot diverge.
Signed-off-by: Jeff King <peff@peff.net>
If git-config is asked for a single value, it will complain
and exit with an error if it finds multiple instances of
that value. This is unlike the usual internal config
parsing, however, which will generally overwrite previous
values, leaving only the final one. For example:
[set a multivar]
$ git config user.email one@example.com
$ git config --add user.email two@example.com
[use the internal parser to fetch it]
$ git var GIT_AUTHOR_IDENT
Your Name <two@example.com> ...
[use git-config to fetch it]
$ git config user.email
one@example.com
error: More than one value for the key user.email: two@example.com
This overwriting behavior is critical for the regular
parser, which starts with the lowest-priority file (e.g.,
/etc/gitconfig) and proceeds to the highest-priority file
($GIT_DIR/config). Overwriting yields the highest priority
value at the end.
Git-config solves this problem by implementing its own
parsing. It goes from highest to lowest priorty, but does
not proceed to the next file if it has seen a value.
So in practice, this distinction never mattered much,
because it only triggered for values in the same file. And
there was not much point in doing that; the real value is in
overwriting values from lower-priority files.
However, this changed with the implementation of config
include files. Now we might see an include overriding a
value from the parent file, which is a sensible thing to do,
but git-config will flag as a duplication.
This patch drops the duplicate detection for git-config and
switches to a pure-overwrite model (for the single case;
--get-all can still be used if callers want to do something
more fancy).
As is shown by the modifications to the test suite, this is
a user-visible change in behavior. An alternative would be
to just change the include case, but this is much cleaner
for a few reasons:
1. If you change the include case, then to what? If you
just stop parsing includes after getting a value, then
you will get a _different_ answer than the regular
config parser (you'll get the first value instead of
the last value). So you'd want to implement overwrite
semantics anyway.
2. Even though it is a change in behavior for git-config,
it is bringing us in line with what the internal
parsers already do.
3. The file-order reimplementation is the only thing
keeping us from sharing more code with the internal
config parser, which will help keep differences to a
minimum.
Going under the assumption that the primary purpose of
git-config is to behave identically to how git's internal
parsing works, this change can be seen as a bug-fix.
Signed-off-by: Jeff King <peff@peff.net>
This is a refactor that will allow us to more easily tweak
the behavior for multi-valued variables, and it will
ultimately allow us to remove a lot git-config's custom code
in favor of the regular git_config code.
It does mean we're no longer streaming, and we're storing
more in memory for the --get-all case, but in practice it is
a tiny amount of data, and the results are instantaneous.
Signed-off-by: Jeff King <peff@peff.net>
The get_value function has a goto label for cleaning up on
errors, but it only cleans up half of what the function
might allocate. Let's also clean up the key and regexp
variables there.
Note that we need to take special care when compiling the
regex fails to clean it up ourselves, since it is in a
half-constructed state (we would want to free it, but not
regfree it).
Similarly, we fix git_config_parse_key to return NULL when
it fails, not a pointer to some already-freed memory.
Signed-off-by: Jeff King <peff@peff.net>
Teach symbolic-ref to delete symrefs by adding the -d/--delete option to
git-symbolic-ref. Both proper and dangling symrefs are deleted by this
option, but other refs - or anything else that is not a symref - is not.
The symref deletion is performed by first verifying that we are given a
proper symref, and then invoking delete_ref() on it with the REF_NODEREF
flag.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You can currently set the output format to --short or
--porcelain. There is no --long, because we default to it
already. However, you may want to override an alias that
uses "--short" to get back to the default.
This requires a little bit of refactoring, because currently
we use STATUS_FORMAT_LONG internally to mean the same as
"the user did not specify anything". By expanding the enum
to include STATUS_FORMAT_NONE, we can distinguish between
the implicit and explicit cases. This effects these
conditions:
1. The user has asked for NUL termination. With NONE, we
currently default to turning on the porcelain mode.
With an explicit --long, we would in theory use NUL
termination with the long mode, but it does not support
it. So we can just complain and die.
2. When an output format is given to "git commit", we
default to "--dry-run". This behavior would now kick in
when "--long" is given, too.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git branch reports the abbreviated hash of the head commit of
a deleted branch to make it easier for a user to undo the
operation. For symref branches this doesn't help. Print the
symref target instead for them.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before a branch is deleted, we check that it points to a valid
commit. With -d we also check that the commit is a merged; this
check is not done with -D.
The reason for that is that commits pointed to by branches should
never go missing; if they do then something broke and it's better
to stop instead of adding to the mess. And a non-merged commit
may contain changes that are worth preserving, so we require the
stronger option -D instead of -d to get rid of them.
If a branch consists of a symref, these concerns don't apply.
Deleting such a branch can't make a commit become unreferenced,
so we don't need to check if it is merged, or even if it is
actually a valid commit. Skip them in that case. This allows
us to delete dangling symref branches.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a branch that is to be deleted happens to be a symref to another
branch, the current code removes the targeted branch instead of the
one it was called for.
Change this surprising behaviour and delete the symref branch
instead.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Provide a small helper function for deleting branch config sections.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the code to perform checks on the tip commit of a branch
to its own function.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function has only two callsites, and is a thin wrapper whose
usefulness is dubious. When the caller needs to learn the log
output encoding, it should be able to do so by directly calling
get_log_output_encoding() and calling the underlying
logmsg_reencode() with it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
grep searches for .gitattributes using "name" field in struct
grep_source but that field is not real on-disk path name. For example,
"grep pattern rev" fills the field with "rev:path", and Git looks for
.gitattributes in the (non-existent but exploitable) path "rev:path"
instead of "path".
This patch passes real paths down to grep_source_load_driver() when:
- grep on work tree
- grep on the index
- grep a commit (or a tag if it points to a commit)
so that these cases look up .gitattributes at proper paths.
.gitattributes lookup is disabled in all other cases.
Initial-work-by: Jeff King <peff@peff.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now the grep_config() callback is reusable from other configuration
callbacks, call it from git_log_config() so that grep.patterntype
and friends can be used with the commands in the "git log" family.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Switching between -E/-G/-P/-F correctly needs a lot more than just
flipping opt->regflags bit these days, and we have a nice helper
function buried in builtin/grep.c for the sole use of "git grep".
Extract it so that "log --grep" family can also use it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration handling is a library-ish part of this program,
that is not specific to "git grep" command. It should be reusable
by "log" and others.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The grep_config() function takes one instance of grep_opt as its
callback parameter, and populates it by running git_config().
This has three practical implications:
- You have to have an instance of grep_opt already when you call
the configuration, but that is not necessarily always true. You
may be trying to initialize the grep_filter member of rev_info,
but are not ready to call init_revisions() on it yet.
- It is not easy to enhance grep_config() in such a way to make it
cascade to other callback functions to grab other variables in
one call of git_config(); grep_config() can be cascaded into from
other callbacks, but it has to be at the leaf level of a cascade.
- If you ever need to use more than one instance of grep_opt, you
will have to open and read the configuration file(s) every time
you initialize them.
Rearrange the configuration mechanism and model it after how diff
configuration variables are handled. An early call to git_config()
reads and remembers the values taken from the configuration in the
default "template", and a separate call to grep_init() uses this
template to instantiate a grep_opt.
The next step will be to move some of this out of this file so that
the other user of the grep machinery (i.e. "log") can use it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git status" honored the ignore=dirty settings in .gitmodules but
"git commit" didn't.
* os/commit-submodule-ignore:
commit: pay attention to submodule.$name.ignore in .gitmodules
"git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser
when run over the smart-http protocol.
* jk/receive-pack-unpack-error-to-pusher:
receive-pack: drop "n/a" on unpacker errors
receive-pack: send pack-processing stderr over sideband
receive-pack: redirect unpack-objects stdout to /dev/null
A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".
* rt/maint-clone-single:
clone --single: limit the fetch refspec to fetched branch
A patch attached as application/octet-stream (e.g. not text/*) were
mishandled, not correctly honoring Content-Transfer-Encoding
(e.g. base64).
* lt/mailinfo-handle-attachment-more-sanely:
mailinfo: don't require "text" mime type for attachments
The idea of the peel_ref function is to dereference tag
objects recursively until we hit a non-tag, and return the
sha1. Conceptually, it should return 0 if it is successful
(and fill in the sha1), or -1 if there was nothing to peel.
However, the current behavior is much more confusing. For a
regular loose ref, the behavior is as described above. But
there is an optimization to reuse the peeled-ref value for a
ref that came from a packed-refs file. If we have such a
ref, we return its peeled value, even if that peeled value
is null (indicating that we know the ref definitely does
_not_ peel).
It might seem like such information is useful to the caller,
who would then know not to bother loading and trying to peel
the object. Except that they should not bother loading and
trying to peel the object _anyway_, because that fallback is
already handled by peel_ref. In other words, the whole point
of calling this function is that it handles those details
internally, and you either get a sha1, or you know that it
is not peel-able.
This patch catches the null sha1 case internally and
converts it into a -1 return value (i.e., there is nothing
to peel). This simplifies callers, which do not need to
bother checking themselves.
Two callers are worth noting:
- in pack-objects, a comment indicates that there is a
difference between non-peelable tags and unannotated
tags. But that is not the case (before or after this
patch). Whether you get a null sha1 has to do with
internal details of how peel_ref operated.
- in show-ref, if peel_ref returns a failure, the caller
tries to decide whether to try peeling manually based on
whether the REF_ISPACKED flag is set. But this doesn't
make any sense. If the flag is set, that does not
necessarily mean the ref came from a packed-refs file
with the "peeled" extension. But it doesn't matter,
because even if it didn't, there's no point in trying to
peel it ourselves, as peel_ref would already have done
so. In other words, the fallback peeling is guaranteed
to fail.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A patch attached as application/octet-stream (e.g. not text/*) were
mishandled, not correctly honoring Content-Transfer-Encoding
(e.g. base64).
* lt/mailinfo-handle-attachment-more-sanely:
mailinfo: don't require "text" mime type for attachments
"gc --auto" notified the user that auto-packing has triggered even
under the "--quiet" option.
* tu/gc-auto-quiet:
silence git gc --auto --quiet output
"git status" honored the ignore=dirty settings in .gitmodules but
"git commit" didn't.
* os/commit-submodule-ignore:
commit: pay attention to submodule.$name.ignore in .gitmodules
Send errors from "unpack-objects" and "index-pack" back to the "git
push" over the git and smart-http protocols, just like it is done
for a push over the ssh protocol.
* jk/receive-pack-unpack-error-to-pusher:
receive-pack: drop "n/a" on unpacker errors
receive-pack: send pack-processing stderr over sideband
receive-pack: redirect unpack-objects stdout to /dev/null
Running "git fetch" in a repository made with "git clone --single"
slurps all the branches, defeating the point of "--single".
* rt/maint-clone-single:
clone --single: limit the fetch refspec to fetched branch
Currently "git am" does insane things if the mbox it is given contains
attachments with a MIME type that aren't "text/*".
In particular, it will still decode them, and pass them "one line at a
time" to the mail body filter, but because it has determined that they
aren't text (without actually looking at the contents, just at the mime
type) the "line" will be the encoding line (eg 'base64') rather than a
line of *content*.
Which then will cause the text filtering to fail, because we won't
correctly notice when the attachment text switches from the commit message
to the actual patch. Resulting in a patch failure, even if patch may be a
perfectly well-formed attachment, it's just that the message type may be
(for example) "application/octet-stream" instead of "text/plain".
Just remove all the bogus games with the message_type. The only difference
that code creates is how the data is passed to the filter function
(chunked per-pred-code line or per post-decode line), and that difference
is *wrong*, since chunking things per pre-decode line can never be a
sensible operation, and cannot possibly matter for binary data anyway.
This code goes all the way back to March of 2007, in commit 87ab799234
("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
pass random mbox contents to git. However, the pre-decode vs post-decode
logic really shouldn't matter even for that case, and more importantly, "I
fed git am crap" is not a valid reason to break *real* patch attachments.
If somebody really cares, and determines that some attachment is binary
data (by looking at the data, not the MIME-type), the whole attachment
should be dismissed, rather than fed in random-sized chunks to
"handle_filter()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-log-grep-all-match-1:
grep.c: make two symbols really file-scope static this time
t7810-grep: test --all-match with multiple --grep and --author options
t7810-grep: test interaction of multiple --grep and --author options
t7810-grep: test multiple --author with --all-match
t7810-grep: test multiple --grep with and without --all-match
t7810-grep: bring log --grep tests in common form
grep.c: mark private file-scope symbols as static
log: document use of multiple commit limiting options
log --grep/--author: honor --all-match honored for multiple --grep patterns
grep: show --debug output only once
grep: teach --debug option to dump the parse tree
Currently using "git rm" on a submodule - populated or not - fails with
this error:
fatal: git rm: '<submodule path>': Is a directory
This made sense in the past as there was no way to remove a submodule
without possibly removing unpushed parts of the submodule's history
contained in its .git directory too, so erroring out here protected the
user from possible loss of data.
But submodules cloned with a recent git version do not contain the .git
directory anymore, they use a gitfile to point to their git directory
which is safely stored inside the superproject's .git directory. The work
tree of these submodules can safely be removed without losing history, so
let's teach git to do so.
Using rm on an unpopulated submodule now removes the empty directory from
the work tree and the gitlink from the index. If the submodule's directory
is missing from the work tree, it will still be removed from the index.
Using rm on a populated submodule using a gitfile will apply the usual
checks for work tree modification adapted to submodules (unless forced).
For a submodule that means that the HEAD is the same as recorded in the
index, no tracked files are modified and no untracked files that aren't
ignored are present in the submodules work tree (ignored files are deemed
expendable and won't stop a submodule's work tree from being removed).
That logic has to be applied in all nested submodules too.
Using rm on a submodule which has its .git directory inside the work trees
top level directory will just error out like it did before to protect the
repository, even when forced. In the future git could either provide a
message informing the user to convert the submodule to use a gitfile or
even attempt to do the conversion itself, but that is not part of this
change.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --quiet is requested, gc --auto should not display messages unless
there is an error.
Signed-off-by: Tobias Ulmer <tobiasu@tmux.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git am" is fed an input that has multiple "Content-type: ..."
header, it did not grok charset= attribute correctly.
* jc/maint-mailinfo-mime-attr:
mailinfo: do not concatenate charset= attribute values from mime headers
Even during a conflicted merge, "git blame $path" always meant to
blame uncommitted changes to the "working tree" version; make it
more useful by showing cleanly merged parts as coming from the other
branch that is being merged.
This incidentally fixes an unrelated problem on a case insensitive
filesystem, where "git blame MAKEFILE" run in a history that has
"Makefile" but not "MAKEFILE" did not say "No such file MAKEFILE in
HEAD" but pretended as if "MAKEFILE" was a newly added file.
* jc/maint-blame-no-such-path:
blame: allow "blame file" in the middle of a conflicted merge
blame $path: avoid getting fooled by case insensitive filesystems
"git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but combination "--all --tags" makes
much less sense than "--all --no-tags").
* dj/fetch-all-tags:
fetch --all: pass --tags/--no-tags through to each remote
submodule: use argv_array instead of hand-building arrays
fetch: use argv_array instead of hand-building arrays
argv-array: fix bogus cast when freeing array
argv-array: add pop function
"git status" does not list a submodule with uncommitted working tree
files as modified when "submodule.$name.ignore" is set to "dirty" in
in-tree ".gitmodules" file. Both status and commit honor the setting
in $GIT_DIR/config, but "commit" does not pick it up from .gitmodules,
which is inconsistent.
Teach "git commit" to pay attention to the setting in .gitmodules as
well.
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you know your history did not have renames, or if you care only
about the history after a large rename that happened some time ago,
"git blame --no-follow $path" is a way to tell the command not to
bother about renames.
When you use -C, the lines that came from the renamed file will
still be found without the whole-file rename detection, so it is not
all that interesting either way, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output from git push currently looks like this:
$ git push dest HEAD
fatal: [some message from index-pack]
error: unpack failed: index-pack abnormal exit
To dest
! [remote rejected] HEAD -> master (n/a (unpacker error))
That n/a is meant to be "the per-ref status is not
available" but the nested parentheses just make it look
ugly. Let's turn the final line into just:
! [remote rejected] HEAD -> master (unpacker error)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The unpack-objects command should not generally produce any
output on stdout. However, if it's given extra input after
the packfile, it will spew the remainder to stdout. When
called by receive-pack, this means we will break protocol,
since our stdout is connected to the remote send-pack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned ref instead
to correct this.
That means:
If "--single" is used without "--branch" or "--mirror", the
fetch refspec covers the branch on which remote's HEAD points to.
If "--single" is used with "--branch", it'll cover only the branch
specified in the "--branch" option.
If "--single" is combined with "--mirror", then it'll cover all
refs of the cloned repository.
If "--single" is used with "--branch" that specifies a tag, then
it'll cover only the ref for this tag.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a long-standing bug in "git log --grep" when multiple "--grep"
are used together with "--all-match" and "--author" or "--committer".
* jc/maint-log-grep-all-match:
t7810-grep: test --all-match with multiple --grep and --author options
t7810-grep: test interaction of multiple --grep and --author options
t7810-grep: test multiple --author with --all-match
t7810-grep: test multiple --grep with and without --all-match
t7810-grep: bring log --grep tests in common form
grep.c: mark private file-scope symbols as static
log: document use of multiple commit limiting options
log --grep/--author: honor --all-match honored for multiple --grep patterns
grep: show --debug output only once
grep: teach --debug option to dump the parse tree
Turn many file-scope private symbols to static to reduce the
global namespace contamination.
* jc/make-static:
sequencer.c: mark a private file-scope symbol as static
ident.c: mark private file-scope symbols as static
trace.c: mark a private file-scope symbol as static
wt-status.c: mark a private file-scope symbol as static
read-cache.c: mark a private file-scope symbol as static
strbuf.c: mark a private file-scope symbol as static
sha1-array.c: mark a private file-scope symbol as static
symlinks.c: mark private file-scope symbols as static
notes.c: mark a private file-scope symbol as static
rerere.c: mark private file-scope symbols as static
graph.c: mark private file-scope symbols as static
diff.c: mark a private file-scope symbol as static
commit.c: mark a file-scope private symbol as static
builtin/notes.c: mark file-scope private symbols as static
After "git cherry-pick -s" gave control back to the user asking
help to resolve conflicts, concluding "git commit" needs to be run
with "-s" if the user wants to sign it off, but the command should
be able to remember that.
* mv/cherry-pick-s:
cherry-pick: don't forget -s on failure
The status report from "git fetch", when messages like 'up-to-date'
are translated, did not align the branch names well.
* nd/fetch-status-alignment:
fetch: align per-ref summary report in UTF-8 locales
The attribute system may be asked for a path that itself or its
leading directories no longer exists in the working tree, and it is
fine if we cannot open .gitattribute file in such a case. Failure
to open per-directory .gitattributes with error status other than
ENOENT and ENOTDIR should be diagnosed.
* jk/config-warn-on-inaccessible-paths:
attr: failure to open a .gitattributes file is OK with ENOTDIR
warn_on_inaccessible(): a helper to warn on inaccessible paths
attr: warn on inaccessible attribute files
gitignore: report access errors of exclude files
config: warn on inaccessible files
* maint:
t/perf: add "trash directory" to .gitignore
Add missing -z to git check-attr usage text for consistency with man page
git-jump: ignore (custom) prefix in diff mode
Documentation: indent-with-non-tab uses "equivalent tabs" not 8
completion: add --no-edit to git-commit
Code simplification and clarification.
* mh/fetch-filter-refs:
test-string-list.c: Fix some sparse warnings
fetch-pack: eliminate spurious error messages
cmd_fetch_pack(): simplify computation of return value
fetch-pack: report missing refs even if no existing refs were received
cmd_fetch_pack(): return early if finish_connect() fails
filter_refs(): simplify logic
filter_refs(): build refs list as we go
filter_refs(): delete matched refs from sought list
fetch_pack(): update sought->nr to reflect number of unique entries
filter_refs(): do not check the same sought_pos twice
Change fetch_pack() and friends to take string_list arguments
fetch_pack(): reindent function decl and defn
Rename static function fetch_pack() to http_fetch_pack()
t5500: add tests of fetch-pack --all --depth=N $URL $REF
t5500: add tests of error output for missing refs
"git blame MAKEFILE" run in a history that has "Makefile" but not
"MAKEFILE" should say "No such file MAKEFILE in HEAD", but got
confused on a case insensitive filesystem and failed to do so.
Even during a conflicted merge, "git blame $path" always meant to
blame uncommitted changes to the "working tree" version; make it
more useful by showing cleanly merged parts as coming from the other
branch that is being merged.
* jc/maint-blame-no-such-path:
blame: allow "blame file" in the middle of a conflicted merge
blame $path: avoid getting fooled by case insensitive filesystems
"Content-type: text/plain; charset=UTF-8" header should not appear
twice in the input, but it is always better to gracefully deal with
such a case. The current code concatenates the value to the values
we have seen previously, producing nonsense such as "utf8UTF-8".
Instead of concatenating, forget the previous value and use the last
value we see.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We strip the prefix from "Re: subject" and also from a less common
"re: subject", but left even less common "RE: subject" intact.
* jc/mailinfo-RE:
mailinfo: strip "RE: " prefix
* mz/cherry-pick-cmdline-order:
cherry-pick/revert: respect order of revisions to pick
demonstrate broken 'git cherry-pick three one two'
teach log --no-walk=unsorted, which avoids sorting
fetch does printf("%-*s", width, "foo") where "foo" can be a utf-8
string, but width is in bytes, not columns. For ASCII it's fine as one
byte takes one column. For utf-8, this may result in misaligned ref
summary table.
Introduce gettext_width() function that returns the string length in
columns (currently only supports utf-8 locales). Make the code use
TRANSPORT_SUMMARY(x) where the length is compensated properly in
non-English locales.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option parsing of "git checkout" had error checking, dwim and
defaulting missing options, all mixed in the code, and issuing an
appropriate error message with useful context was getting harder.
Reorganize the code and allow giving a proper diagnosis when the
user says "git checkout -b -t foo bar" (e.g. "-t" is not a good name
for a branch).
* nd/checkout-option-parsing-fix:
checkout: reorder option handling
checkout: move more parameters to struct checkout_opts
checkout: pass "struct checkout_opts *" as const pointer
"git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but combination "--all --tags" makes
much less sense than "--all --no-tags").
* dj/fetch-all-tags:
fetch --all: pass --tags/--no-tags through to each remote
* rj/path-cleanup:
Call mkpathdup() rather than xstrdup(mkpath(...))
Call git_pathdup() rather than xstrdup(git_path("..."))
path.c: Use vsnpath() in the implementation of git_path()
path.c: Don't discard the return value of vsnpath()
path.c: Remove the 'git_' prefix from a file scope function
When threaded grep is in effect, the patterns are duplicated and
recompiled for each thread. Avoid "--debug" output during the
recompilation so that the output is given once instead of "1+nthreads"
times.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "grep" allows complex boolean expressions to be formed to match
each individual line with operators like --and, '(', ')' and --not.
Introduce the "--debug" option to show the parse tree to help people
who want to debug and enhance it.
Also "log" learns "--grep-debug" option to do the same. The command
line parser to the log family is a lot more limited than the general
"git grep" parser, but it has special handling for header matching
(e.g. "--author"), and a parse tree is valuable when working on it.
Note that "--all-match" is *not* any individual node in the parse
tree. It is an instruction to the evaluator to check all the nodes
in the top-level backbone have matched and reject a document as
non-matching otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case 'git cherry-pick -s <commit>' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message. If there is no such line, then add it before the
the Conflicts: line.
Signed-off-by: Miklos Vajna <vmiklos@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply -p0" did not parse pathnames on "diff --git" line
correctly. This caused patches that had pathnames in no other
places to be mistakenly rejected (most notably, binary patch that
does not rename nor change mode). Textual patches, renames or mode
changes have preimage and postimage pathnames in different places in
a form that can be parsed unambiguously and did not suffer from this
problem.
* jc/apply-binary-p0:
apply: compute patch->def_name correctly under -p0
"git log .." errored out saying it is both rev range and a path when
there is no disambiguating "--" is on the command line. Update the
command line parser to interpret ".." as a path in such a case.
* jc/dotdot-is-parent-directory:
specifying ranges: we did not mean to make ".." an empty set
"git for-each-ref" did not honor multiple "--sort=<key>" arguments
correctly.
* kk/maint-for-each-ref-multi-sort:
for-each-ref: Fix sort with multiple keys
t6300: test sort with multiple keys
It used to be that if "--all", "--depth", and also explicit references
were sought, then the explicit references were not handled correctly
in filter_refs() because the "--all --depth" code took precedence over
the explicit reference handling, and the explicit references were
never noted as having been found. So check for explicitly sought
references before proceeding to the "--all --depth" logic.
This fixes two test cases in t5500.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set the final value at initialization rather than initializing it then
sometimes changing it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the logic without changing the behavior.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simplify flow within loop: first decide whether to keep the reference,
then keep/free it. This makes it clearer that each ref has exactly
two possible destinies, and removes duplication of the code for
appending the reference to the linked list.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of temporarily storing matched refs to temporary array
"return_refs", simply append them to newlist as we go. This changes
the order of references in newlist to strictly sorted if "--all" and
"--depth" and named references are all specified, but that usage is
broken anyway (see the last two tests in t5500).
This changes the last test in t5500 from segfaulting into just
emitting a spurious error (this will be fixed in a moment).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove any references that are available from the remote from the
sought list (rather than overwriting their names with NUL characters,
as previously). Mark matching entries by writing a non-NULL pointer
to string_list_item::util during the iteration, then use
filter_string_list() later to filter out the entries that have been
marked.
Document this aspect of fetch_pack() in a comment in the header file.
(More documentation is obviously still needed.)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch_pack() removes duplicates from the "sought" list, thereby
shrinking the list. But previously, the caller was not informed about
the shrinkage. This would cause a spurious error message to be
emitted by cmd_fetch_pack() if "git fetch-pack" is called with
duplicate refnames.
Instead, remove duplicates using string_list_remove_duplicates(),
which adjusts sought->nr to reflect the new length of the list.
The last test of t5500 inexplicably *required* "git fetch-pack" to
fail when fetching a list of references that contains duplicates;
i.e., it insisted on the buggy behavior. So change the test to expect
the correct behavior.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once a match has been found at sought_pos, the entry is zeroed and no
future attempts will match that entry. So increment sought_pos to
avoid checking against the zeroed-out entry during the next iteration.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of juggling <nr_heads,heads> (sometimes called
<nr_match,match>), pass around the list of references to be sought in
a single string_list variable called "sought". Future commits will
make more use of string_list functionality.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git blame file" has always meant "find the origin of each line of
the file in the history leading to HEAD, oh by the way, blame the
lines that are modified locally to the working tree".
This teaches "git blame" that during a conflicted merge, some
uncommitted changes may have come from the other history that is
being merged.
The verify_working_tree_path() function introduced in the previous
patch to notice a typo in the filename (primarily on case insensitive
filesystems) has been updated to allow a filename that does not exist
in HEAD (i.e. the tip of our history) as long as it exists one of the
commits being merged, so that a "we deleted, the other side modified"
case tracks the history of the file in the history of the other side.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout operates in three different modes. On top of that it tries to
be smart by guessing the branch name for switching. This results in
messy option handling code. This patch reorders it so that
- cmd_checkout() is responsible for parsing, preparing input and
determining mode
- Code of each mode is in checkout_paths() and checkout_branch(),
where sanity checks are performed
Another slight improvement is always print branch name (or commit
name) when printing errors related ot them. This helps catch the case
where an option is mistaken as branch/commit.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use argv-array API in "git fetch" implementation.
* jk/argv-array:
submodule: use argv_array instead of hand-building arrays
fetch: use argv_array instead of hand-building arrays
argv-array: fix bogus cast when freeing array
argv-array: add pop function
Optimise the "merge-base" computation a bit, and also update its
users that do not need the full merge-base information to call a
cheaper subset.
* jc/merge-bases:
reduce_heads(): reimplement on top of remove_redundant()
merge-base: "--is-ancestor A B"
get_merge_bases_many(): walk from many tips in parallel
in_merge_bases(): use paint_down_to_common()
merge_bases_many(): split out the logic to paint history
in_merge_bases(): omit unnecessary redundant common ancestor reduction
http-push: use in_merge_bases() for fast-forward check
receive-pack: use in_merge_bases() for fast-forward check
in_merge_bases(): support only one "other" commit
"git show --format='%ci'" did not give timestamp correctly for
commits created without human readable name on "committer" line.
* jc/maint-ident-missing-human-name:
split_ident_line(): make best effort when parsing author/committer line
* jc/capabilities:
fetch-pack: mention server version with verbose output
parse_feature_request: make it easier to see feature values
fetch-pack: do not ask for unadvertised capabilities
do not send client agent unless server does first
send-pack: fix capability-sending logic
include agent identifier in capability string
"git blame MAKEFILE" run in a history that has "Makefile" but not
MAKEFILE can get confused on a case insensitive filesystem, because
the check we run to see if there is a corresponding file in the
working tree with lstat("MAKEFILE") succeeds. In addition to that
check, we have to make sure that the given path also exists in the
commit we start digging history from (i.e. "HEAD").
Note that this reveals the breakage in a test added in cd8ae20
(git-blame shouldn't crash if run in an unmerged tree, 2007-10-18),
which expects the entire merge-in-progress path to be blamed to the
working tree when it did not exist in our tree. As it is clear in
the log message of that commit, the old breakage was that it was
causing an internal error and the fix was about avoiding it.
Just check that the command does not die an uncontrolled death. For
this particular case, the blame should fail, as the history for the
file in that contents has not been committed yet at the point in the
test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch --set-upstream origin/master" is a common mistake to
create a local branch 'origin/master' and set it to integrate with
the current branch. With a plan to deprecate this option, introduce
"git branch (-u|--set-upstream-to) origin/master" that sets the
current branch to integrate with 'origin/master' remote tracking
branch.
* cn/branch-set-upstream-to:
branch: deprecate --set-upstream and show help if we detect possible mistaken use
branch: add --unset-upstream option
branch: introduce --set-upstream-to
"git cherry-pick A C B" used to replay changes in A and then B and
then C if these three commits had committer timestamps in that
order, which is not what the user who said "A C B" naturally expects.
* mz/cherry-pick-cmdline-order:
cherry-pick/revert: respect order of revisions to pick
demonstrate broken 'git cherry-pick three one two'
teach log --no-walk=unsorted, which avoids sorting
We tried to bend backwards to allow "--quiet" to be a synonym as
"-s" when given as e.g. "git show --quiet", but did not quite
succeed.
* jk/maint-quiet-is-synonym-to-s-in-log:
log: fix --quiet synonym for -s
"git prune" without "-v" used to warn about leftover temporary
files (which is an indication of an earlier aborted operation).
* bc/prune-info:
prune.c: only print informational message in show_only or verbose mode
* maint-1.7.11:
Almost 1.7.11.6
gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO
rebase -i: use full onto sha1 in reflog
sh-setup: protect from exported IFS
receive-pack: do not leak output from auto-gc to standard output
t/t5400: demonstrate breakage caused by informational message from prune
setup: clarify error messages for file/revisions ambiguity
send-email: improve RFC2047 quote parsing
fsck: detect null sha1 in tree entries
do not write null sha1s to on-disk index
diff: do not use null sha1 as a sentinel value
When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
* bc/receive-pack-stdout-protection:
receive-pack: do not leak output from auto-gc to standard output
t/t5400: demonstrate breakage caused by informational message from prune
"git diff" had a confusion between taking data from a path in the
working tree and taking data from an object that happens to have
name 0{40} recorded in a tree.
* jk/maint-null-in-trees:
fsck: detect null sha1 in tree entries
do not write null sha1s to on-disk index
diff: do not use null sha1 as a sentinel value
We already strip the more common Re: and re:, and we do not often
see RE: from saner MUA, but this prefix does exist and gets used
from time to time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output from "git branch -v" contains "(no branch)" that could be
localized, but the code to align it along with the names of branches
were counting in bytes, not in display columns.
* nd/branch-v-alignment:
branch -v: align even when branch names are in UTF-8
"git apply -p0" did not parse pathnames on "diff --git" line
correctly. This caused patches that had pathnames in no other
places to be mistakenly rejected (most notably, binary patch that
does not rename nor change mode). Textual patches, renames or
mode changes have preimage and postimage pathnames in different
places in a form that can be parsed unambiguously and did not suffer
from this problem.
* jc/apply-binary-p0:
apply: compute patch->def_name correctly under -p0
"git log .." errored out saying it is both rev range and a path when
there is no disambiguating "--" is on the command line. Update the
command line parser to interpret ".." as a path in such a case.
* jc/dotdot-is-parent-directory:
specifying ranges: we did not mean to make ".." an empty set
A lot of i18n mark-up for the help text from "git <cmd> -h".
* nd/i18n-parseopt-help: (66 commits)
Use imperative form in help usage to describe an action
Reduce translations by using same terminologies
i18n: write-tree: mark parseopt strings for translation
i18n: verify-tag: mark parseopt strings for translation
i18n: verify-pack: mark parseopt strings for translation
i18n: update-server-info: mark parseopt strings for translation
i18n: update-ref: mark parseopt strings for translation
i18n: update-index: mark parseopt strings for translation
i18n: tag: mark parseopt strings for translation
i18n: symbolic-ref: mark parseopt strings for translation
i18n: show-ref: mark parseopt strings for translation
i18n: show-branch: mark parseopt strings for translation
i18n: shortlog: mark parseopt strings for translation
i18n: rm: mark parseopt strings for translation
i18n: revert, cherry-pick: mark parseopt strings for translation
i18n: rev-parse: mark parseopt strings for translation
i18n: reset: mark parseopt strings for translation
i18n: rerere: mark parseopt strings for translation
i18n: status: mark parseopt strings for translation
i18n: replace: mark parseopt strings for translation
...
When looking for $HOME/.gitconfig etc., it is OK if we cannot read
them because they do not exist, but we did not diagnose existing
files that we cannot read.
* jk/config-warn-on-inaccessible-paths:
warn_on_inaccessible(): a helper to warn on inaccessible paths
attr: warn on inaccessible attribute files
gitignore: report access errors of exclude files
config: warn on inaccessible files
"git for-each-ref" did not currectly support more than one --sort
option.
* kk/maint-for-each-ref-multi-sort:
for-each-ref: Fix sort with multiple keys
t6300: test sort with multiple keys
Teach "git commit" and "git commit-tree" the "we are told to use
utf-8 in log message, but this does not look like utf-8---attempt to
pass it through convert-from-latin1-to-utf8 and see if it makes
sense" heuristics "git mailinfo" already uses.
* lt/commit-tree-guess-utf-8:
commit/commit-tree: correct latin1 to utf-8
While looking for a way to expand the URL of a remote
that uses a 'url.<name>.insteadOf' config option I stumbled
over the undocumented '--get-url' option of 'git ls-remote'.
This adds some minimum documentation for that option.
And while at it, also add that option to the '-h' output.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.
Reported-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Dan Johnson <ComputerDruid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All remote subcommands are spelled out words except 'rm'. 'rm', being a
popular UNIX command name, may mislead users that there are also 'ls' or
'mv'. Use 'remove' to fit with the rest of subcommands.
'rm' is still supported and used in the test suite. It's just not
widely advertised.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In addition to updating the xstrdup(mkpath(...)) call sites with
mkpathdup(), we also fix a memory leak (in merge_3way()) caused by
neglecting to free the memory allocated to the 'base_name' variable.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In addition to updating the two xstrdup(git_path("...")) call sites
with git_pathdup(), we also fix a memory leak by freeing the memory
allocated to the ADD_EDIT.patch 'file' in the edit_patch() function.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git cherry-pick" by default stops when it sees a commit without any
log message. The "--allow-empty-message" option can be used to
silently proceed.
* cw/cherry-pick-allow-empty-message:
cherry-pick: add --allow-empty-message option
The exit status code from "git config" was way overspecified while
being incorrect. Update the implementation to give the documented
status for a case that was documented, and introduce a new code for
"all other errors".
* jc/maint-config-exit-status:
config: "git config baa" should exit with status 1
fetch_populated_submodules() allocates the full argv array it uses to
recurse into the submodules from the number of given options plus the six
argv values it is going to add. It then initializes it with those values
which won't change during the iteration and copies the given options into
it. Inside the loop the two argv values different for each submodule get
replaced with those currently valid.
However, this technique is brittle and error-prone (as the comment to
explain the magic number 6 indicates), so let's replace it with an
argv_array. Instead of replacing the argv values, push them to the
argv_array just before the run_command() call (including the option
separating them) and pop them from the argv_array right after that.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fetch invokes itself recursively when recursing into
submodules or handling "fetch --multiple". In both cases, it
builds the child's command line by pushing options onto a
statically-sized array. In both cases, the array is
currently just big enough to handle the largest possible
case. However, this technique is brittle and error-prone, so
let's replace it with a dynamic argv_array.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits made by ancient version of Git allowed committer without
human readable name, like this (00213b17c in the kernel history):
tree 6947dba41f8b0e7fe7bccd41a4840d6de6a27079
parent 352dd1df32e672be4cff71132eb9c06a257872fe
author Petr Baudis <pasky@ucw.cz> 1135223044 +0100
committer <sam@mars.ravnborg.org> 1136151043 +0100
kconfig: Remove support for lxdialog --checklist
...
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
When fed such a commit, --format='%ci' fails to parse it, and gives
back an empty string. Update the split_ident_line() to be a bit
more lenient when parsing, but make sure the caller that wants to
pick up sane value from its return value does its own validation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many scripted Porcelain commands, we find this idiom:
if test "$(git rev-parse --verify A)" = "$(git merge-base A B)"
then
... A is an ancestor of B ...
fi
But you do not have to compute exact merge-base only to see if A is
an ancestor of B. Give them a more direct way to use the underlying
machinery.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for "cherry-pick" and in reverse chronological order for
"revert". This matches the order in which one would usually give them
on the command line, making this bug somewhat hard to notice. Still,
it has been reported at least once before [1].
It seems like the chronological sorting happened by accident because
the revision walker has traditionally always sorted commits in reverse
chronological order when rev_info.no_walk was enabled. In the case of
'git revert B A' where B is newer than A, this sorting is a no-op. For
'git cherry-pick A B', the sorting would reverse the arguments, but
because the sequencer also flips the rev_info.reverse flag when
picking (as opposed to reverting), the end result is a chronological
order. The rev_info.reverse flag was probably flipped so that the
revision walker emits B before C in 'git cherry-pick A..C'; that it
happened to effectively undo the unexpected sorting done when not
walking, was probably a coincidence that allowed this bug to happen at
all.
Fix the bug by telling the revision walker not to sort the commits
when not walking. The only case we want to reverse the order is now
when cherry-picking and walking revisions (rev_info.no_walk = 0).
[1] http://thread.gmane.org/gmane.comp.version-control.git/164794
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This interface is error prone, and a better one (--set-upstream-to)
exists. Add a message listing the alternatives and suggest how to fix
a --set-upstream invocation in case the user only gives one argument
which causes a local branch with the same name as a remote-tracking
one to be created. The typical case is
git branch --set-upstream origin/master
when the user meant
git branch --set-upstream master origin/master
assuming that the current branch is master. Show a message telling the
user how to undo their action and get what they wanted. For the
command above, the message would be
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch origin/master set up to track local branch master.
If you wanted to make 'master' track 'origin/master', do this:
git branch -d origin/master
git branch --set-upstream-to origin/master
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have ways of setting the upstream information, but if we want to
unset it, we need to resort to modifying the configuration manually.
Teach branch an --unset-upstream option that unsets this information.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some capabilities were asked by fetch-pack even when upload-pack did
not advertise that they are available. Fix fetch-pack not to do so.
* jc/capabilities:
fetch-pack: mention server version with verbose output
parse_feature_request: make it easier to see feature values
fetch-pack: do not ask for unadvertised capabilities
do not send client agent unless server does first
send-pack: fix capability-sending logic
include agent identifier in capability string
Teach "git prune" without "-v" to be silent about leftover temporary
files.
* bc/prune-info:
prune.c: only print informational message in show_only or verbose mode
Minor code clean-up on the cherry-pick codepath.
* mz/cherry-code-cleanup:
cherry: remove redundant check for merge commit
cherry: don't set ignored rev_info options
remove unnecessary parameter from get_patch_ids()
This struct contains various switches to system and it feels somewhat
safer to have the compiler reassure us that nowhere else changes it.
One field that is changed, writeout_error, is split out and passed as
another argument.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally the "--quiet" option was parsed by the
diff-option parser into the internal QUICK option. This had
the effect of silencing diff output from the log (which was
not intended, but happened to work and people started to
use it). But it also had other odd side effects at the diff
level (for example, it would suppress the second commit in
"git show A B").
To fix this, commit 1c40c36 converted log to parse-options
and handled the "quiet" option separately, not passing it
on to the diff code. However, it simply ignored the option,
which was a regression for people using it as a synonym for
"-s". Commit 01771a8 then fixed that by interpreting the
option to add DIFF_FORMAT_NO_OUTPUT to the list of output
formats.
However, that commit did not fix it in all cases. It sets
the flag after setup_revisions is called. Naively, this
makes sense because you would expect the setup_revisions
parser to overwrite our output format flag if "-p" or
another output format flag is seen.
However, that is not how the NO_OUTPUT flag works. We
actually store it in the bit-field as just another format.
At the end of setup_revisions, we call diff_setup_done,
which post-processes the bitfield and clears any other
formats if we have set NO_OUTPUT. By setting the flag after
setup_revisions is done, diff_setup_done does not have a
chance to make this tweak, and we end up with other format
options still set.
As a result, the flag would have no effect in "git log -p
--quiet" or "git show --quiet". Fix it by setting the
format flag before the call to setup_revisions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original computed merge-base between the old commit and the new
commit and checked if the old commit was a merge base between them,
in order to make sure we are fast-forwarding.
Instead, call in_merge_bases(old, new) which does the same.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In early days of its life, I planned to make it possible to compute
"is a commit contained in all of these other commits?" with this
function, but it turned out that no caller needed it.
Just make it take two commit objects and add a comment to say what
these two functions do.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"grep" learned to use a non-standard pattern type by default if a
configuration variable tells it to.
* js/grep-patterntype-config:
grep: add a grep.patternType configuration setting
When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
* bc/receive-pack-stdout-protection:
receive-pack: do not leak output from auto-gc to standard output
t/t5400: demonstrate breakage caused by informational message from prune
We do not want a link to 0{40} object stored anywhere in our objects.
* jk/maint-null-in-trees:
fsck: detect null sha1 in tree entries
do not write null sha1s to on-disk index
diff: do not use null sha1 as a sentinel value
In the next major release, we will switch "git push [$there]" that
does not say what to push from the traditional "matching" to the
updated "simple" semantics, that pushes the current branch to the
branch with the same name only when the current branch is set to
integrate with that remote branch (all other cases will error out).
* mm/push-default-switch-warning:
push: start warning upcoming default change for push.default
Branch names are usually in ASCII so they are not the problem. The
problem most likely comes from "(no branch)" translation, which is
in UTF-8 and makes display-width calculation just wrong. Clarify
this by renaming the field "len" in struct ref_item to "width", as
it stores the display-width and is used to compute the width of the
screen needed to show the names of all the branches, and compute the
display width using utf8_strwidth(), not byte-length with strlen().
Update document to mention the fact that we may want ref names in
UTF-8. Encodings that produce invalid UTF-8 are safe as utf8_strwidth()
falls back to strlen(). The ones that incidentally produce valid UTF-8
sequences will cause misalignment.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back when "git apply" was written, we made sure that the user can
skip more than the default number of path components (i.e. 1) by
giving "-p<n>", but the logic for doing so was built around the
notion of "we skip N slashes and stop". This obviously does not
work well when running under -p0 where we do not want to skip any,
but still want to skip SP/HT that separates the pathnames of
preimage and postimage and want to reject absolute pathnames.
Stop using "stop_at_slash()", and instead introduce a new helper
"skip_tree_prefix()" with similar logic but works correctly even for
the -p0 case.
This is an ancient bug, but has been masked for a long time because
most of the patches are text and have other clues to tell us the
name of the preimage and the postimage.
Noticed by Colin McCabe.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Either end of revision range operator can be omitted to default to HEAD,
as in "origin.." (what did I do since I forked) or "..origin" (what did
they do since I forked). But the current parser interprets ".." as an
empty range "HEAD..HEAD", and worse yet, because ".." does exist on the
filesystem, we get this annoying output:
$ cd Documentation/howto
$ git log .. ;# give me recent commits that touch Documentation/ area.
fatal: ambiguous argument '..': both revision and filename
Use '--' to separate filenames from revisions
Surely we could say "git log ../" or even "git log -- .." to disambiguate,
but we shouldn't have to.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstream already exists, we can't simply change its
behaviour. To work around this, introduce --set-upstream-to which
accepts a compulsory argument indicating what the new upstream branch
should be and one optinal argument indicating which branch to change,
defaulting to HEAD.
The new options allows us to type
git branch --set-upstream-to origin/master
to set the current branch's upstream to be origin's master.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Somewhere in help usage, we use both "message" and "msg", "command"
and "cmd", "key id" and "key-id". This patch makes all help text from
parseopt use the first form. Clearer and 3 fewer strings for
translators.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a line in the message is not a valid utf-8, "git mailinfo"
attempts to convert it to utf-8 assuming the input is latin1 (and
punt if it does not convert cleanly). Using the same heuristics in
"git commit" and "git commit-tree" lets the editor output be in
latin1 to make the overall system more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before reading a config file, we check "!access(path, R_OK)"
to make sure that the file exists and is readable. If it's
not, then we silently ignore it.
For the case of ENOENT, this is fine, as the presence of the
file is optional. For other cases, though, it may indicate a
configuration error (e.g., not having permissions to read
the file). Let's print a warning in these cases to let the
user know.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation, only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fetch-pack's verbose mode is more of a debugging mode (and
in fact takes two "-v" arguments to trigger via the
porcelain layer). Let's mention the server version as
another possible item of interest.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the same spirit as the previous fix, stop asking for thin-pack, no-progress
and include-tag capabilities when the other end does not claim to support them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ff5effdf taught both clients and servers of the git protocol
to send an "agent" capability that just advertises their version for
statistics and debugging purposes. The protocol-capabilities.txt
document however indicates that the client's advertisement is
actually a response, and should never include capabilities not
mentioned in the server's advertisement.
Adding the unconditional advertisement in the server programs was
OK, then, but the clients broke the protocol. The server
implementation of git-core itself does not care, but at least one
does: the Google Code git server (or any server using Dulwich), will
hang up with an internal error upon seeing an unknown capability.
Instead, each client must record whether we saw an agent string from
the server, and respond with its agent only if the server mentioned
it first.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we have capabilities to send to the server, we send the
regular "want" line followed by a NUL, then the
capabilities; otherwise, we do not even send the NUL.
However, when checking whether we want to send the "quiet"
capability, we check args->quiet, which is wrong. That flag
only tells us whether the client side wanted to be quiet,
not whether the server supports it (originally, in c207e34f,
it meant both; however, that was later split into two flags
by 01fdc21f).
We still check the right flag when actually printing
"quiet", so this could only have two effects:
1. We might send the trailing NUL when we do not otherwise
need to. In theory, an antique pre-capability
implementation of git might choke on this (since the
client is instructed never to respond with capabilities
that the server has not first advertised).
2. We might also want to send the quiet flag if the
args->progress flag is false, but this code path would
not trigger in that instance.
In practice, it almost certainly never matters. The
report-status capability dates back to 2005. Any real-world
server is going to advertise that, and we will always
respond with at least that capability.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git prune" reports removal of loose object files that are no longer
necessary only under the "-v" option, but unconditionally reports
removal of temporary files that are no longer needed.
The original thinking was that the presence of a leftover temporary
file should be an unusual occurrence that may indicate an earlier
failure of some sort, and the user may want to be reminded of it.
Removing an unnecessary loose object file, on the other hand, is
just part of the normal operation. That is why the former is always
printed out and the latter only when -v is used.
But neither report is particularly useful. Hide both of these
behind the "-v" option for consistency.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The standard output channel of receive-pack is a structured protocol
channel, and subprocesses must never be allowed to leak anything
into it by writing to their standard output.
Use RUN_COMMAND_STDOUT_TO_STDERR option to run_command_v_opt() just
like we do when running hooks to prevent output from "gc" leaking to
the standard output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scripts such as "git rebase -i" cannot currently cherry-pick commits
which have an empty commit message, as git cherry-pick calls git
commit without the --allow-empty-message option.
Add an --allow-empty-message option to git cherry-pick which is passed
through to git commit, so this behaviour can be overridden.
Signed-off-by: Chris Webb <chris@arachsys.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It hasn't been used since 2006, as of commit 3cd4f5e8
"git-apply --binary: clean up and prepare for --reverse"
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of having the client advertise a particular version
number in the git protocol, we have managed extensions and
backwards compatibility by having clients and servers
advertise capabilities that they support. This is far more
robust than having each side consult a table of
known versions, and provides sufficient information for the
protocol interaction to complete.
However, it does not allow servers to keep statistics on
which client versions are being used. This information is
not necessary to complete the network request (the
capabilities provide enough information for that), but it
may be helpful to conduct a general survey of client
versions in use.
We already send the client version in the user-agent header
for http requests; adding it here allows us to gather
similar statistics for non-http requests.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff_setup_done() has historically returned an error code, but lost
the last nonzero return in 943d5b7 (allow diff.renamelimit to be set
regardless of -M/-C, 2006-08-09). The callers were in a pretty
confused state: some actually checked for the return code, and some
did not.
Let it return void, and patch all callers to take this into account.
This conveniently also gets rid of a handful of different(!) error
messages that could never be triggered anyway.
Note that the function can still die().
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The grep.extendedRegexp configuration setting enables the -E flag on grep
by default but there are no equivalents for the -G, -F and -P flags.
Rather than adding an additional setting for grep.fooRegexp for current
and future pattern matching options, add a grep.patternType setting that
can accept appropriate values for modifying the default grep pattern
matching behavior. The current values are "basic", "extended", "fixed",
"perl" and "default" for setting -G, -E, -F, -P and the default behavior
respectively.
When grep.patternType is set to a value other than "default", the
grep.extendedRegexp setting is ignored. The value of "default" restores
the current default behavior, including the grep.extendedRegexp
behavior.
Signed-off-by: J Smith <dark.panda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit-tree" learned a more natural "-p <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
* kk/maint-commit-tree:
Revert "git-commit-tree(1): update synopsis"
commit-tree: resurrect command line parsing updates
We instead failed with an undocumented exit status 255.
Also define a "catch-all" status and document it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore
the commit if that is the case. Instead, set rev_info.max_parents to
1 and let the revision traversal code handle it for us.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since cherry was built-in in e827633 (Built-in cherry,
2006-10-24), it has set a bunch of options on the the rev_info that
are only used while outputting a patch. But since the built-in cherry
command never needs to output any patch (it uses add_commit_patch_id
and has_commit_patch_id instead), these options are just distractions,
so remove them.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_patch_ids() takes an already initialized rev_info and a
prefix. The prefix is used when initalizing a second rev_info. Since
the initialized rev_info already has a prefix and the prefix never
changes, we can use the prefix from the initialized rev_info to
initialize the second rev_info.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git checkout <branchname>" to come back from a detached HEAD state
incorrectly computed reachability of the detached HEAD, resulting in
unnecessary warnings.
* jk/maint-checkout-orphan-check-fix:
checkout: don't confuse ref and object flags
When we are leaving a detached HEAD, we do a revision traversal to
check whether we are orphaning any commits, marking the commit we're
leaving as the start of the traversal, and all existing refs as
uninteresting.
Prior to commit 468224e5, we did so by calling for_each_ref, and
feeding each resulting refname to setup_revisions. Commit 468224e5
refactored this to simply mark the pending objects, saving an extra
lookup.
However, it confused the "flags" parameter to the each_ref_fn
clalback, which is about the flags we found while looking up the ref
with the object flag. Because REF_ISSYMREF ("this ref is a symbolic
ref, e.g. refs/remotes/origin/HEAD") happens to be the same bit
pattern as SEEN ("we have picked this object up from the pending
list and moved it to revs.commits list"), we incorrectly reported
that a commit previously at the detached HEAD will become
unreachable if the only ref that can reach the commit happens to be
pointed at by a symbolic ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit --amend" let the user edit the log message and then died
when the human-readable committer name was given insufficiently by
getpwent(3).
* jk/maint-commit-check-committer-early:
commit: check committer identity more strictly
Split lower bits of ce_flags field and creates a new ce_namelen
field in the in-core index structure.
* tg/ce-namelen-field:
Strip namelen out of ce_flags into a ce_namelen field
The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about salvaging the work from .git/COMMIT_EDITMSG.
The early check for committer ident does not use the
IDENT_STRICT flag, meaning that it would not find an empty
name field. The motivation was presumably because we did not
want to be too restrictive, as later calls might be more lax
(for example, when we create the reflog entry, we do not
care too much about a real name). However, because
commit_tree will always get a strict identity to put in the
commit object itself, there is no point in being lax only to
die later (and in fact it is harmful, because the user will
have wasted time typing their commit message).
Incidentally, this bug was masked prior to 060d4bb, as the
initial loose call would taint the later strict call. So the
commit would succeed (albeit with a bogus committer line in
the commit object), and nobody noticed that our early check
did not match the later one.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A handful of files and directories we create had tighter than
necessary permission bits when the user wanted to have group
writability (e.g. by setting "umask 002").
* ar/clone-honor-umask-at-top:
add: create ADD_EDIT.patch with mode 0666
rerere: make rr-cache fanout directory honor umask
Restore umasks influence on the permissions of work tree created by clone
"commit --amend" used to refuse amending a commit with an empty log
message, with or without "--allow-empty-message".
* cw/amend-commit-without-message:
Allow edit of empty message with commit --amend
"git commit --amend --only --" was meant to allow "Clever" people to
rewrite the commit message without making any change even when they
have already changes for the next commit added to their index, but
it never worked as advertised since it was introduced in 1.3.0 era.
* jk/maint-commit-amend-only-no-paths:
commit: fix "--amend --only" with no pathspec
"git show"'s auto-walking behaviour was an unreliable and
unpredictable hack; it now behaves just like "git log" does when it
walks.
* tr/maint-show-walk:
show: fix "range implies walking"
Demonstrate git-show is broken with ranges
"git fast-export" produced an input stream for fast-import without
properly quoting pathnames when they contain SPs in them.
* js/fast-export-paths-with-spaces:
fast-export: quote paths with spaces
"git checkout --detach", when you are still on an unborn branch,
should be forbidden, but it wasn't.
* cw/no-detaching-an-unborn:
git-checkout: disallow --detach on unborn branch
Teaches the object name parser things like a "git describe" output
is always a commit object, "A" in "git log A" must be a committish,
and "A" and "B" in "git log A...B" both must be committish, etc., to
prolong the lifetime of abbreviated object names.
* jc/sha1-name-more: (27 commits)
t1512: match the "other" object names
t1512: ignore whitespaces in wc -l output
rev-parse --disambiguate=<prefix>
rev-parse: A and B in "rev-parse A..B" refer to committish
reset: the command takes committish
commit-tree: the command wants a tree and commits
apply: --build-fake-ancestor expects blobs
sha1_name.c: add support for disambiguating other types
revision.c: the "log" family, except for "show", takes committish
revision.c: allow handle_revision_arg() to take other flags
sha1_name.c: introduce get_sha1_committish()
sha1_name.c: teach lookup context to get_sha1_with_context()
sha1_name.c: many short names can only be committish
sha1_name.c: get_sha1_1() takes lookup flags
sha1_name.c: get_describe_name() by definition groks only commits
sha1_name.c: teach get_short_sha1() a commit-only option
sha1_name.c: allow get_short_sha1() to take other flags
get_sha1(): fix error status regression
sha1_name.c: restructure disambiguation of short names
sha1_name.c: correct misnamed "canonical" and "res"
...
79a9312 (commit-tree: update the command line parsing, 2011-11-09)
updated the command line parser to understand the usual "flags first
and then non-flag arguments" order, in addition to the original and
a bit unusual "tree comes first and then zero or more -p <parent>".
Unfortunately, ba3c69a (commit: teach --gpg-sign option, 2011-10-05)
broke it by mistake. Resurrect it, and protect the feature with a
test from future breakages.
Noticed by Keshav Kini
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When $HOME is unset, home_config_paths fails and returns NULL pointers
for user_config and xdg_config. Valgrind complains with Syscall param
access(pathname) points to unaddressable byte(s).
Don't call blindly access() on these variables, but test them for
NULL-ness before.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The streaming index-pack introduced in 1.7.11 had a data corruption
bug, and this should fix it.
* jk/index-pack-streaming-fix:
index-pack: loop while inflating objects in unpack_data
"git commit --amend --only --" was meant to allow "Clever" people to
rewrite the commit message without making any change even when they
have already changes for the next commit added to their index, but
it never worked as advertised since it was introduced in 1.3.0 era.
* jk/maint-commit-amend-only-no-paths:
commit: fix "--amend --only" with no pathspec
"commit --amend" used to refuse amending a commit with an empty log
message, with or without "--allow-empty-message".
* cw/amend-commit-without-message:
Allow edit of empty message with commit --amend
A handful of files and directories we create had tighter than
necessary permission bits when the user wanted to have group
writability (e.g. by setting "umask 002").
* ar/clone-honor-umask-at-top:
add: create ADD_EDIT.patch with mode 0666
rerere: make rr-cache fanout directory honor umask
Restore umasks influence on the permissions of work tree created by clone
"git apply" learned to wiggle the base version and perform three-way
merge when a patch does not exactly apply to the version you have.
* jc/apply-3way:
apply: tests for the --3way option
apply: document --3way option
apply: allow rerere() to work on --3way results
apply: register conflicted stages to the index
apply: --3way with add/add conflict
apply: move verify_index_match() higher
apply: plug the three-way merge logic in
apply: fall back on three-way merge
apply: accept -3/--3way command line option
apply: move "already exists" logic to check_to_create()
apply: move check_to_create_blob() closer to its sole caller
apply: further split load_preimage()
apply: refactor "previous patch" logic
apply: split load_preimage() helper function out
apply: factor out checkout_target() helper function
apply: refactor read_file_or_gitlink()
apply: clear_image() clears things a bit more
apply: a bit more comments on PATH_TO_BE_DELETED
apply: fix an incomplete comment in check_patch()
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.
I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.
* tb/sanitize-decomposed-utf-8-pathname:
git on Mac OS and precomposed unicode
Fixes "git show"'s auto-walking behaviour, and make it behave just
like "git log" does when it walks.
* tr/maint-show-walk:
show: fix "range implies walking"
Demonstrate git-show is broken with ranges
"git blame" did not try to make sure that the abbreviated commit
object names in its output are unique.
* jc/maint-blame-unique-abbrev:
blame: compute abbreviation width that ensures uniqueness
On Cygwin, the platform pread(2) is not thread safe, just like our own
compat/ emulation, and cannot be used in the index-pack program.
Makefile variable NO_THREAD_SAFE_PREAD can be defined to avoid use of
this function in a threaded program.
* rj/platform-pread-may-be-thread-unsafe:
index-pack: Disable threading on cygwin
"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.
* nd/clone-single-fix:
clone: fix ref selection in --single-branch --branch=xxx
"git add" allows adding a regular file to the path where a submodule
used to exist, but "git update-index" did not allow an equivalent
operation to Porcelain writers.
* hv/submodule-update-nuke-submodules:
update-index: allow overwriting existing submodule index entries
"git diff --no-index" did not work with pagers correctly.
* jk/diff-no-index-pager:
do not run pager with diff --no-index --quiet
fix pager.diff with diff --no-index
"git diff COPYING HEAD:COPYING" gave a nonsense error message that
claimed that the treeish HEAD did not have COPYING in it.
* mm/verify-filename-fix:
verify_filename(): ask the caller to chose the kind of diagnosis
sha1_name: do not trigger detailed diagnosis for file arguments
"git ls-files --exclude=t -i" did not consider anything under t/ as
excluded, as it did not pay attention to exclusion of leading paths
while walking the index. Other two users of excluded() are also
updated.
* jc/ls-files-i-dir:
dir.c: make excluded() file scope static
unpack-trees.c: use path_excluded() in check_ok_to_remove()
builtin/add.c: use path_excluded()
path_excluded(): update API to less cache-entry centric
ls-files -i: micro-optimize path_excluded()
ls-files -i: pay attention to exclusion of leading paths
Strip the name length from the ce_flags field and move it
into its own ce_namelen field in struct cache_entry. This
will both give us a tiny bit of a performance enhancement
when working with long pathnames and is a refactoring for
more readability of the code.
It enhances readability, by making it more clear what
is a flag, and where the length is stored and make it clear
which functions use stages in comparisions and which only
use the length.
It also makes CE_NAMEMASK private, so that users don't
mistakenly write the name length in the flags.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the unpack_data function is given a consume() callback,
it unpacks only 64K of the input at a time, feeding it to
git_inflate along with a 64K output buffer. However,
because we are inflating, there is a good chance that the
output buffer will fill before consuming all of the input.
In this case, we need to loop on git_inflate until we have
fed the whole input buffer, feeding each chunk of output to
the consume buffer.
The current code does not do this, and as a result, will
fail the loop condition and trigger a fatal "serious inflate
inconsistency" error in this case.
While we're rearranging the loop, let's get rid of the
extra last_out pointer. It is meant to point to the
beginning of the buffer that we feed to git_inflate, but in
practice this is always the beginning of our same 64K
buffer, because:
1. At the beginning of the loop, we are feeding the
buffer.
2. At the end of the loop, if we are using a consume()
function, we reset git_inflate's pointer to the
beginning of the buffer. If we are not using a
consume() function, then we do not care about the value
of last_out at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should be letting the user's umask take care of
restricting permissions. Even though this is a temporary
file and probably nobody would notice, this brings us in
line with other temporary file creations in git (e.g.,
choosing "e"dit from git-add--interactive).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option allows you to feed an ambiguous prefix and enumerate
all the objects that share it as a prefix of their object names.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is not strictly correct, in that resetting selected index
entries from corresponding paths out of a given tree without moving
HEAD is a valid operation, and in such case a tree-ish would suffice.
But the existing code already requires a committish in the codepath,
so let's be consistent with it for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "index" line read from the patch to reconstruct a partial
preimage tree records the object names of blob objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a field to setup_revision_opt structure and allow these callers
to tell the setup_revisions command parsing machinery that short SHA1
it encounters are meant to name committish.
This step does not go all the way to connect the setup_revisions()
to sha1_name.c yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing "cant_be_filename" that tells the function that the
caller knows the arg is not a path (hence it does not have to be
checked for absense of the file whose name matches it) is made into
a bit in the flag word.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function takes user input string and returns the object name
(binary SHA-1) with mode bits and path when the object was looked
up in a tree.
Additionally give hints to help disambiguation of abbreviated object
names when the caller knows what it is looking for.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we have all the necessary logic to fall back on three-way merge when
the patch does not cleanly apply, insert the conflicted entries to the
index as appropriate. This obviously triggers only when the "--index"
option is used.
When we fall back to three-way merge and some of the merges fail, just
like the case where the "--reject" option was specified and we had to
write some "*.rej" files out for unapplicable patches, exit the command
with non-zero status without showing the diffstat and summary. Otherwise
they would make the list of problematic paths scroll off the display.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch wants to create a path, but we already have it in our
current state, pretend as if the patch and we independently added
the same path and cause add/add conflict, so that the user can
resolve it just like "git merge" in the same situation.
For that purpose, implement load_current() in terms of the
load_patch_target() helper introduced earlier to read the current
contents from the path given by patch->new_name (patch->old_name is
NULL for a creation patch).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch does not apply to what we have, but we know the preimage the
patch was made against, we apply the patch to the preimage to compute what
the patch author wanted the result to look like, and attempt a three-way
merge between the result and our version, using the intended preimage as
the base version.
When we are applying the patch using the index, we would additionally need
to add the object names of these three blobs involved in the merge, which
is not yet done in this step, but we add a field to "struct patch" so that
later write-out step can use it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Grab the preimage blob the patch claims to be based on out of the object
store, apply the patch, and then call three-way-merge function. This step
still does not plug the actual three-way merge logic yet, but we are
getting there.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Begin teaching the three-way merge fallback logic "git am -3" uses
to the underlying "git apply". It only implements the command line
parsing part, and does not do anything interesting yet, other than
making sure that "--reject" and "--3way" are not given together, and
making "--3way" imply "--index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The check_to_create_blob() function used to check only the case
where we are applying to the working tree. Rename the function to
check_to_create() and make it also responsible for checking the case
where we apply to the index. Also make its caller responsible for
issuing an error message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
load_preimage() is very specific to grab the current contents for
the path given by patch->old_name. Split the logic that grabs the
contents for a path out of it into a separate load_patch_target()
function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to grab the result of application of a previous patch in the
input was mixed with error message generation for a case where a later
patch tries to modify contents of a path that has been removed.
The same code is duplicated elsewhere in the code. Introduce a helper
to clarify what is going on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Given a patch for a single path, the function apply_data() reads the
preimage in core, and applies the change represented in the patch.
Separate out the first part that reads the preimage into a separate
helper function load_preimage().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch wants to touch a path, if the path exists in the index
but is missing in the working tree, "git apply --index" checks out
the file to the working tree from the index automatically and then
applies the patch.
Split this logic out to a separate helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reading a blob out of the object store does not have to require that the
caller has a cache entry for it.
Create a read_blob_object() helper function that takes the object name and
mode, and use it to reimplement the original function as a thin wrapper to
it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The clear_image() function did not clear the line table in the image
structure; this does not matter for the current callers, as the function
is only called from the codepaths that deal with binary patches where the
line table is never populated, and the codepaths that do populate the line
table free it themselves.
But it will start to matter when we introduce a codepath to retry a failed
patch, so make sure it clears and frees everything.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code is littered with to_be_deleted() whose purpose is not so clear.
Describe where it matters. Also remove an extra space before "#define"
that snuck in by mistake at 7fac0ee (builtin-apply: keep information about
files to be deleted, 2009-04-11).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This check is not only about type-change (for which it would be
sufficient to check only was_deleted()) but is also about a swap
rename. Otherwise to_be_deleted() check is not justified.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original version of the git-clone just used mkdir(1) to create
the working directories. The version rewritten in C creates all
directories inside the working tree by using the mode argument of
0777 when calling mkdir(2) to let the umask take effect.
But the top-level directory of the working tree is created by
passing the mode argument of 0755 to mkdir(2), which results in an
overly tight restriction if the user wants to make directories group
writable with a looser umask like 002.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit --amend" used on a commit with an empty message fails
unless -m is given, whether or not --allow-empty-message is
specified.
Allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later
if an empty message is saved from the editor (this check was
already necessary to prevent a non-empty commit message being edited
to an empty one).
Add a test for --amend --edit of an empty commit message which fails
without this fix, as it's a rare case that won't get frequently
tested otherwise.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git help -w $cmd" can show HTML version of documentation for
"git-$cmd" by setting help.htmlpath to somewhere other than the
default location where the build procedure installs them locally;
the variable can even point at a http:// URL.
* cw/help-over-network:
Allow help.htmlpath to be a URL prefix
Add config variable to set HTML path for git-help --web
"git fast-export" produced an input stream for fast-import without
properly quoting pathnames when they contain SPs in them.
* js/fast-export-paths-with-spaces:
fast-export: quote paths with spaces
"git checkout --detach", when you are still on an unborn branch,
should be forbidden, but it wasn't.
* cw/no-detaching-an-unborn:
git-checkout: disallow --detach on unborn branch
Expose the credential API to scripted Porcelain writers.
* mm/credential-plumbing:
git-remote-mediawiki: update comments to reflect credential support
git-remote-mediawiki: add credential support
git credential fill: output the whole 'struct credential'
add 'git credential' plumbing command
"git blame" did not try to make sure the abbreviated commit object
names in its output are unique.
* jc/maint-blame-unique-abbrev:
blame: compute abbreviation width that ensures uniqueness
On Cygwin, the platform pread(3) is not thread safe, just like our
own compat/ emulation, and cannot be used in the index-pack program.
* rj/platform-pread-may-be-thread-unsafe:
index-pack: Disable threading on cygwin
Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow
the user to avoid cluttering $HOME.
* mm/config-xdg:
config: write to $XDG_CONFIG_HOME/git/config file when appropriate
Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes
Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore
config: read (but not write) from $XDG_CONFIG_HOME/git/config file
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.
* nd/clone-single-fix:
clone: fix ref selection in --single-branch --branch=xxx
Julia Lawall noticed that in linux-next repository the commit object
60d5c9f5 (shown with the default abbreviation width baked into "git
blame") in output from
$ git blame -L 3675,3675 60d5c9f5b -- \
drivers/staging/brcm80211/brcmfmac/wl_iw.c
is no longer unique in the repository, which results in "short SHA1
60d5c9f5 is ambiguous".
Compute the minimum abbreviation width that ensures uniqueness when
the user did not specify the --abbrev option to avoid this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git add" allows adding a regular file to the path where a submodule
used to exist, but "git update-index" does not allow an equivalent
operation to Porcelain writers.
Setting this to a URL prefix instead of a path to a local directory allows
git-help --web to work even when HTML docs aren't locally installed, by
pointing the browser at a copy accessible on the web. For example,
[help]
format = html
htmlpath = http://git-scm.com/docs
will use the publicly available documentation on the git homepage.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If set in git-config, help.htmlpath overrides system_path(GIT_HTML_PATH)
which was compiled in. This allows users to repoint system-wide git at
their own copy of the documentation without recompiling.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A path containing a space must be quoted when used as an
argument to either the copy or rename commands (because
unlike other commands, the path is not the final thing on
the line for those commands).
Commit 6280dfdc3b (fast-export: quote paths in output,
2011-08-05) previously attempted to fix fast-export's
quoting by passing all paths through quote_c_style().
However, that function does not consider the space to be a
character which requires quoting, so let's special-case the
space inside print_path(). This will cause space-containing
paths to also be quoted in other commands where such quoting
is not strictly necessary, but it does not hurt to do so.
The test from 6280dfdc3b did not detect this because, while
it does introduce renames in the export stream, it does not
actually turn on rename detection, so they were presented as
pairs of deletions/adds. Using "-M" reveals the bug.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Cygwin implementation of pread() is not thread-safe since, just
like the emulation provided by compat/pread.c, it uses a sequence of
seek-read-seek calls. In order to avoid failues due to thread-safety
issues, commit b038a61 disables threading when NO_PREAD is defined.
(ie when using the emulation code in compat/pread.c).
We introduce a new build variable, NO_THREAD_SAFE_PREAD, which allows
use to disable the threaded index-pack code on cygwin, in addition to
the above NO_PREAD case.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
abe199808c (git checkout -b: allow switching out of an unborn branch)
introduced a bug demonstrated by
git checkout --orphan foo
git checkout --detach
git symbolic-ref HEAD
which gives 'refs/heads/(null)'.
This happens because we strbuf_addf(&branch_ref, "refs/heads/%s",
opts->new_branch) when opts->new_branch can be NULL for --detach.
Catch and forbid this case, adding a test to t2017 to catch it in
future.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of outputing only the username and password, print all the
attributes, even those that already appeared in the input.
This is closer to what the C API does, and allows one to take the exact
output of "git credential fill" as input to "git credential approve" or
"git credential reject".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The credential API is in C, and not available to scripting languages.
Expose the functionalities of the API by wrapping them into a new
plumbing command "git credentials".
In other words, replace the internal "test-credential" by an official Git
command.
Most documentation writen by: Jeff King <peff@peff.net>
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: Kim Thuat Nguyen <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: Javier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Restructure the way message strings are created, in preparation for
marking them for i18n.
* nd/i18n-misc:
rerere: remove i18n legos in result message
notes-merge: remove i18n legos in merge result message
reflog: remove i18n legos in pruning message
Teach git to write to $XDG_CONFIG_HOME/git/config if
- it already exists,
- $HOME/.gitconfig file doesn't, and
- The --global option is used.
Otherwise, write to $HOME/.gitconfig when the --global option is
given, as before.
If the user doesn't create $XDG_CONFIG_HOME/git/config, there is
absolutely no change. Users can use this new file only if they want.
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used.
Advice for users who often come back to an old version of Git: you
shouldn't create this file.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git to read the "gitconfig" information from a new location,
$XDG_CONFIG_HOME/git/config; this allows the user to avoid
cluttering $HOME with many per-application configuration files.
In the order of reading, this file comes between the global
configuration file (typically $HOME/.gitconfig) and the system wide
configuration file (typically /etc/gitconfig).
We do not write to this new location (yet).
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used. This is in line with XDG specification.
If the new file does not exist, the behavior is unchanged.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In preparation for flipping the default to the "simple" mode from
the "matching" mode that is the historical default, start warning
users when they rely on unconfigured "git push" to default to the
"matching" mode.
Also, advertise for 'simple' where 'current' and 'upstream' are advised.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- do not fetch HEAD
- do not also fetch refs following "xxx"
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 1cc8af0 "help: use HTML as the default help format on Windows"
lost the ability to make use of the help.format config value by forcing
the use of a compiled in default if no command-line argument was provided.
This commit restores the use of the help.format value if one is
available, overriding the compiled default.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to always default to "man" format even on platforms where
"man" viewer is not widely available.
* vr/help-per-platform:
help: use HTML as the default help format on Windows
"git ls-files --exclude=t -i" did not consider anything under t/
as excluded, as it did not pay attention to exclusion of leading
paths while walking the index. Other two users of excluded() are
also updated.
* jc/ls-files-i-dir:
dir.c: make excluded() file scope static
unpack-trees.c: use path_excluded() in check_ok_to_remove()
builtin/add.c: use path_excluded()
path_excluded(): update API to less cache-entry centric
ls-files -i: micro-optimize path_excluded()
ls-files -i: pay attention to exclusion of leading paths
Teaches git native protocol agents to show software version over the
wire.
* jk/version-string:
http: get default user-agent from git_user_agent
version: add git_user_agent function
move git_version_string into version.c
"git clone --local $path" started its life as an experiment to
optionally use link/copy when cloning a repository on the disk, but
we didn't deprecate it after we made the option a no-op to always
use the optimization.
The command learns "--no-local" option to turn this off, as a more
explicit alternative over use of file:// URL.
* jk/clone-local:
clone: allow --no-local to turn off local optimizations
docs/clone: mention that --local may be ignored
verify_filename() can be called in two different contexts. Either we
just tried to interpret a string as an object name, and it fails, so
we try looking for a working tree file (i.e. we finished looking at
revs that come earlier on the command line, and the next argument
must be a pathname), or we _know_ that we are looking for a
pathname, and shouldn't even try interpreting the string as an
object name.
For example, with this change, we get:
$ git log COPYING HEAD:inexistant
fatal: HEAD:inexistant: no such path in the working tree.
Use '-- <path>...' to specify paths that do not exist locally.
$ git log HEAD:inexistant
fatal: Path 'inexistant' does not exist in 'HEAD'
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-diff does not rely on the git wrapper to setup its
pager; instead, it sets it up on its own after seeing
whether --quiet or --exit-code has been specified. After
diff_no_index was split off from cmd_diff, commit b3fde6c
(git diff --no-index: default to page like other diff
frontends, 2008-05-26) duplicated the one-liner from
cmd_diff to turn on the pager.
Later, commit 8f0359f (Allow pager of diff command be
enabled/disabled, 2008-07-21) taught the the version in
cmd_diff to respect the pager.diff config, but the version
in diff_no_index was left behind. This meant that
git -c pager.diff=0 diff a b
would not use a pager, but
git -c pager.diff=0 diff --no-index a b
would. Let's fix it by factoring out a common function.
While we're there, let's update the antiquated comment,
which claims that the pager interferes with propagating the
exit code; this has not been the case since ea27a18 (spawn
pager via run_command interface, 2008-07-22).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tone down the lines that credit people involved and make them
comments, so that integrators who edit their merge messages can
still make use of the information, but lazy ones will not leave
the unverified guesses placed on the "via" line.
* jc/fmt-merge-msg-people:
fmt-merge-msg: make attribution into comment lines
In commit e01105 Linus introduced gitlinks to update-index. He explains
that he thinks it is not the right thing to replace a gitlink with
something else.
That commit is from the very first beginnings of submodule support.
Since then we have gotten a lot closer to being able to remove a
submodule without losing its history. This check prevents such a use
case, so I think this assumption has changed.
Additionally in the git add codepath we do not have such a check, so for
consistency reasons I think removing this check is the correct thing to
do.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The submaintainer credit is not something you can compute purely by
looking at the history and its shape, especially in the presense of
fast-forward merges, and this observation makes the information on
the "via" line unreliable. Let's leave the final determination of
credits up to whoever is making the merge and show them as comments.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'git help $cmd' is run without a format option (e.g. -w), the
'man' format is always used. On some platforms, however, manual page
viewers are not often available.
Introduce DEFAULT_HELP_FORMAT make variable in order to allow the
default format configurable at compile time, and set it to HTML when
compiling on Windows (but not Cygwin).
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This only happens in --ignore-missing --dry-run codepath which
presumably nobody should care, but is for completeness.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was stupid of me to make the API too much cache-entry specific;
the caller may want to check arbitrary pathname without having a
corresponding cache-entry to see if a path is ignored.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.
The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory. This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.
The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.
Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The global git_version_string currently lives in git.c, but
doesn't have anything to do with the git wrapper. Let's move
it into its own file, where it will be more appropriate to
build more version-related functions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
By René Scharfe
* rs/maint-grep-F:
grep: stop leaking line strings with -f
grep: support newline separated pattern list
grep: factor out do_append_grep_pat()
grep: factor out create_grep_pat()
"git checkout" gave progress display even when the standard error
stream was not connected to the tty, which made little sense.
By Avery Pennarun
* ap/checkout-no-progress-for-non-tty:
checkout: no progress messages if !isatty(2).
The 4th arg of "new mode (%o) of %s does not match old mode (%o)%s%s"
is blank string or string " of ". Even mark the string " of " for a
complete i18n, this message is still hard to translate right.
Split it into two slight different messages would make l10n teams happy.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is basically the same as using "file://", but is a
little less subtle for the end user. It also allows relative
paths to be specified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixes quite a lot of brokenness when ident information needs to be taken
from the system and cleans up the code.
By Jeff King
* jk/ident-gecos-strbuf: (22 commits)
format-patch: do not use bogus email addresses in message ids
ident: reject bogus email addresses with IDENT_STRICT
ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICT
format-patch: use GIT_COMMITTER_EMAIL in message ids
ident: let callers omit name with fmt_indent
ident: refactor NO_DATE flag in fmt_ident
ident: reword empty ident error message
format-patch: refactor get_patch_filename
ident: trim whitespace from default name/email
ident: use a dynamic strbuf in fmt_ident
ident: use full dns names to generate email addresses
ident: report passwd errors with a more friendly message
drop length limitations on gecos-derived names and emails
ident: don't write fallback username into git_default_name
fmt_ident: drop IDENT_WARN_ON_NO_NAME code
format-patch: use default email for generating message ids
ident: trim trailing newline from /etc/mailname
move git_default_* variables to ident.c
move identity config parsing to ident.c
fmt-merge-msg: don't use static buffer in record_person
...
The way "fetch-pack" that is given multiple references to fetch tried to
remove duplicates was very inefficient.
By Jeff King
* jk/fetch-pack-remove-dups-optim:
fetch-pack: sort incoming heads list earlier
fetch-pack: avoid quadratic loop in filter_refs
fetch-pack: sort the list of incoming refs
add sorting infrastructure for list refs
fetch-pack: avoid quadratic behavior in remove_duplicates
fetch-pack: sort incoming heads
Tighten constness of some local variables in a callchain.
By Michael Haggerty
* mh/fetch-pack-constness:
cmd_fetch_pack(): respect constness of argv parameter
cmd_fetch_pack(): combine the loop termination conditions
cmd_fetch_pack(): handle non-option arguments outside of the loop
cmd_fetch_pack(): declare dest to be const
git usually streams large blobs directly to packs. But there are cases
where git can create large loose blobs (unpack-objects or hash-object
over pipe). Or they can come from other git implementations.
core.bigfilethreshold can also be lowered down and introduce a new
wave of large loose blobs.
Use streaming interface to read/compress/write these blobs in one
go. Fall back to normal way if somehow streaming interface cannot be
used.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
When adding the information from a tag, put an empty line between the
message of the tag and the commented-out signature verification
information.
At least for the kernel workflow, I often end up re-formatting the message
that people send me in the tag data. In that situation, putting the tag
message and the tag signature verification back-to-back then means that
normal editor "reflow parapgraph" command will get confused and think that
the signature is a continuation of the last message paragraph.
So I always end up having to first add an empty line, and then go back and
reflow the last paragraph. Let's just do it in git directly.
The extra vertical space also makes the verification visually stand out
more from the user-supplied message, so it looks a bit more readable to me
too, but that may be just an odd personal preference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can ask git_committer_info to be strict about coming up
with an email, which will die automatically on a poorly
configured machine. This is better than letting invalid
message-ids into the wild.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git status --porcelain" ignored "--branch" option by mistake. The output
for "git status --branch -z" was also incorrect and did not terminate the
record for the current branch name with NUL as asked.
By Jeff King
* jk/maint-status-porcelain-z-b:
status: respect "-b" for porcelain format
status: fix null termination with "-b"
status: refactor null_termination option
commit: refactor option parsing
Callers who ask for ERROR_ON_NO_NAME are not so much
concerned that the name will be blank (because, after all,
we will fall back to using the username), but rather it is a
check to make sure that low-quality identities do not end up
in things like commit messages or emails (whereas it is OK
for them to end up in things like reflogs).
When future commits add more quality checks on the identity,
each of these callers would want to use those checks, too.
Rather than modify each of them later to add a new flag,
let's refactor the flag.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before commit 43ae9f4, we generated the tail of a message id
by calling git_committer_info and parsing the email out of
the result. 43ae9f4 changed to use ident_default_email
directly, so we didn't have to bother with parsing. As a
side effect, it meant we no longer used GIT_COMMITTER_EMAIL
at all.
In general, this is probably reasonable behavior. Either the
default email is sane on your system, or you are using
user.email to provide something sane. The exception is if
you rely on GIT_COMMITTER_EMAIL being set all the time to
override the bogus generated email.
This is unlikely to match anybody's real-life setup, but we
do use it in the test environment. And furthermore, it's
what we have always done, and the change in 43ae9f4 was
about cleaning up, not fixing any bug; we should be
conservative and keep the behavior identical.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If stderr isn't a tty, we shouldn't be printing incremental progress
messages. In particular, this affects 'git checkout -f . >&logfile'
unless you provided -q. And git-new-workdir has no way to provide -q.
It would probably be better to have progress.c check isatty(2) all the time,
but that wouldn't allow things like 'git push --progress' to force progress
reporting to on, so I won't try to solve the general case right now.
Actual fix suggested by Jeff King.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When putting whole objects in core is unavoidable, try match object
type and size first before actually inflating.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 4435968 started sorting heads fed to fetch-pack so
that later commits could use more optimized algorithms;
commit 7db8d53 switched the remove_duplicates function to
such an algorithm.
Of course, the sorting is more effective if you do it
_before_ the algorithm in question.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows caller to consume large inflated object with a fixed
amount of memory.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack_raw_entry() will not allocate and return decompressed blobs if
they are larger than core.bigFileThreshold. sha1_object() may not be
called on those objects because there's no actual content.
sha1_object() is called later on those objects, where we can safely
use get_data_from_pack() to retrieve blob content for checking.
However we always do that when we definitely need the blob
content. And we often don't.
There are two cases when we may need object content. The first case is
when we find an in-repo blob with the same SHA-1. We need to do
collision test, byte-on-byte. If this test is on, the blob must be
loaded on memory (i.e. no streaming). Normally (e.g. in
fetch/pull/clone) this does not happen because git avoid to send
objects that client already has.
The other case is when --strict is specified and the object in
question is not a blob, which can't happen in reality becase we deal
with large _blobs_ here.
Note: --verify (or git-verify-pack) a pack from current repository
will trigger collision test on every object in the pack, which
effectively disables this patch. This could be easily worked around by
setting GIT_DIR to an imaginary place with no packs.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a list of refs that we want to compare against the
"match" array. The current code searches the match list
linearly, giving quadratic behavior over the number of refs
when you want to fetch all of them.
Instead, we can compare the lists as we go, giving us linear
behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Having the list sorted means we can avoid some quadratic
algorithms when comparing lists.
These should typically be sorted already, but they do come
from the remote, so let's be extra careful. Our ref-sorting
implementation does a mergesort, so we do not have to care
about performance degrading in the common case that the list
is already sorted.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We remove duplicate entries from the list of refs we are
fed in fetch-pack. The original algorithm is quadratic over
the number of refs, but since the list is now guaranteed to
be sorted, we can do it in linear time.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no reason to preserve the incoming order of the
heads we're requested to fetch. By having them sorted, we
can replace some of the quadratic algorithms with linear
ones.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code cast away the constness of the strings passed to the
function in argument argv[], which could result in their being
modified by filter_refs(). Fix by copying reference names from argv
and putting them into our own array (similarly to how refnames passed
to stdin were already handled).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If an argument that does not start with '-' is found, the loop is
terminated. So move that check into the for-loop condition.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes it more obvious that the code is always executed unless
there is an error, and that the first initialization of nr_heads is
unnecessary.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no need for it to be non-const, and this avoids the need
for casting away the constness of an argv element.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The get_patch_filename function expects a commit argument
and uses it to get the sanitized subject line when making a
patch filename. However, we also want to use this same
function for the cover letter, which does not have a commit
object. The current solution is to create a fake commit with
the subject "cover letter". Instead, let's make the
get_patch_filename interface more flexibile, and allow
passing a direct subject.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We try to generate a sane message id for cover letters and
threading by appending some changing bits to the front of
the user's email address. The current code parses the email
out of the results of git_committer_info, but we can do this
much more easily by just calling ident_default_email
ourselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The record_person function just parses out the "name" field
of the person line in a commit and adds it to a string_list.
The only reason we need an extra buffer is that the
string_list functions require a NUL-terminated string.
Instead of the static buffer, we can just allocate a
temporary NUL-terminated copy. In addition to removing a
useless limit, this removes the only user of MAX_GITNAME
outside of ident.c.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When reading patterns from a file, we pass the lines as allocated string
buffers to append_grep_pat() and never free them. That's not a problem
because they are needed until the program ends anyway.
However, now that the function duplicates the pattern string, we can
reuse the strbuf after calling that function. This simplifies the code
a bit and plugs a minor memory leak.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The mapping that describe what ref fetched from the remote is used to
update what ref locally is called "refspec", not "respec".
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function first decides if we want to copy data taken from existing
pack verbatim or we want to encode the data ourselves for the packfile
we are creating and then carries out the decision. Separate the latter
phase into two helper functions, one for the case the data is reused,
the other for the case the data is produced anew.
A little twist is that it can later turn out that we cannot reuse the
data after we initially decide to do so; in such a case, the "reuse"
helper makes a call to "generate" helper. It is easier to follow than
the current fallback code that uses "goto" inside a single large
function.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is because all other places do "xx > big_file_threshold"
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Text from "git cmd --help" are getting prepared for i18n.
By Nguyễn Thái Ngọc Duy
* nd/i18n-parseopt:
i18n: apply: mark parseopt strings for translation
i18n: parseopt: lookup help and argument translations when showing usage
Simplifies the interface between the implementation of "blame" and
underlying xdiff engine, and removes a lot of unused or unnecessary code
from the latter.
By René Scharfe (6) and Ramsay Jones (1)
* rs/xdiff-lose-emit-func:
builtin/blame.c: Fix a "Using plain integer as NULL pointer" warning
xdiff: remove unused functions
xdiff: remove emit_func() and xdi_diff_hunks()
blame: factor out helper for calling xdi_diff()
blame: use hunk_func(), part 2
blame: use hunk_func(), part 1
xdiff: add hunk_func()
Enables threading in index-pack to resolve base data in parallel.
By Nguyễn Thái Ngọc Duy (3) and Ramsay Jones (1)
* nd/threaded-index-pack:
index-pack: disable threading if NO_PREAD is defined
index-pack: support multithreaded delta resolving
index-pack: restructure pack processing into three main functions
compat/win32/pthread.h: Add an pthread_key_delete() implementation
Gives a better DWIM behaviour for --pretty=format:%gd, "stash list", and
"log -g", depending on how the starting point ("master" vs "master@{0}" vs
"master@{now}") and date formatting options (e.g. "--date=iso") are given
on the command line.
By Jeff King (4) and Junio C Hamano (1)
* jk/maint-reflog-walk-count-vs-time:
reflog-walk: tell explicit --date=default from not having --date at all
reflog-walk: always make HEAD@{0} show indexed selectors
reflog-walk: clean up "flag" field of commit_reflog struct
log: respect date_mode_explicit with --format:%gd
t1411: add more selector index/date tests
Running "git checkout" on an unborn branch used to corrupt HEAD
(regression in 1.7.10); this makes it error out.
By Erik Faye-Lund
* ef/checkout-empty:
checkout: do not corrupt HEAD on empty repo
When checking out another commit from an already detached state, we used
to report all commits that are not reachable from any of the refs as
lossage, but some of them might be reachable from the new HEAD, and there
is no need to warn about them.
By Johannes Sixt
* js/checkout-detach-count:
checkout (detached): truncate list of orphaned commits at the new HEAD
t2020-checkout-detach: check for the number of orphaned commits
Some time ago, "git clone" lost the progress output for its "checkout"
phase; when run without any "--quiet" option, it should give progress to
the lengthy operation.
By Erik Faye-Lund
* ef/maint-clone-progress-fix:
clone: fix progress-regression
Plain gcc may not but sparse catches and complains about this sort of
stuff.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running "git checkout" on an unborn branch used to corrupt HEAD
(regression in 1.7.10); this makes it error out.
By Erik Faye-Lund
* ef/checkout-empty:
checkout: do not corrupt HEAD on empty repo
Gives a better DWIM behaviour for --pretty=format:%gd, "stash list", and
"log -g", depending on how the starting point ("master" vs "master@{0}" vs
"master@{now}") and date formatting options (e.g. "--date=iso") are given
on the command line.
By Jeff King (4) and Junio C Hamano (1)
* jk/maint-reflog-walk-count-vs-time:
reflog-walk: tell explicit --date=default from not having --date at all
reflog-walk: always make HEAD@{0} show indexed selectors
reflog-walk: clean up "flag" field of commit_reflog struct
log: respect date_mode_explicit with --format:%gd
t1411: add more selector index/date tests
Fix yet another message construction by concatenating pieces of sentenes,
which is unfriendly to i18n.
By Nguyễn Thái Ngọc Duy
* nd/i18n-branch-lego:
branch: remove lego in i18n tracking info strings
The cases "git push" fails due to non-ff can be broken into three
categories; each case is given a separate advise message.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
"git repack" used to write out unreachable objects as loose objects
when repacking, even if such loose objects will immediately pruned
due to its age.
By Jeff King
* jk/repack-no-explode-objects-from-old-pack:
gc: use argv-array for sub-commands
argv-array: add a new "pushl" method
argv-array: refactor empty_argv initialization
gc: do not explode objects which will be immediately pruned
Unlike "git rev-parse --show-cdup", "--show-prefix" did not give an
empty line when run at the top of the working tree.
By Ross Lagerwall
* rl/show-empty-prefix:
rev-parse --show-prefix: add in trailing newline
"git status --porcelain" ignored "--branch" option by mistake. The output
for "git status --branch -z" was also incorrect and did not terminate the
record for the current branch name with NUL as asked.
By Jeff King
via Jeff King
* jk/status-porcelain-z-b:
status: refactor colopts handling
status: respect "-b" for porcelain format
status: fix null termination with "-b"
status: refactor null_termination option
commit: refactor option parsing
Some time ago, "git clone" lost the progress output for its "checkout"
phase; when run without any "--quiet" option, it should give progress to
the lengthy operation.
By Erik Faye-Lund
* ef/maint-clone-progress-fix:
clone: fix progress-regression
When checking out another commit from an already detached state, we used
to report all commits that are not reachable from any of the refs as
lossage, but some of them might be reachable from the new HEAD, and there
is no need to warn about them.
By Johannes Sixt
* js/checkout-detach-count:
checkout (detached): truncate list of orphaned commits at the new HEAD
t2020-checkout-detach: check for the number of orphaned commits
"git push" over smart-http lost progress output a few releases ago.
By Jeff King
* jk/maint-push-progress:
t5541: test more combinations of --progress
teach send-pack about --[no-]progress
send-pack: show progress when isatty(2)
Use handle_split_cb() directly as hunk_func() callback, without going
through xdi_diff_hunks().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use blame_chunk_cb() directly as hunk_func() callback, without detour
through xdi_diff_hunks().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In abe1998 ("git checkout -b: allow switching out of an unborn
branch"), a code-path overly-optimisticly assumed that a
branch-name was specified. This is not always the case, and as
a result a NULL-pointer was attempted printed to .git/HEAD.
This could lead to at least two different failure modes:
1) vsnprintf formated the NULL-string as something useful (e.g
"(null)")
2) vsnprintf crashed
Neither were very convenient for formatting a new HEAD-reference.
To fix this, reintroduce some strictness so we only take this
new codepath if a banch-name was specified.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It marks the string "...inconsistent %s filename..." where %s is either
"old" or "new" from caller. Make it two strings "...inconsistent new
filename..." and "...inconsistent old filename...".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code reads the config and command-line options
into a separate "colopts" variable, and then copies the
contents of that variable into the "struct wt_status". We
can eliminate the extra variable and copy just write
straight into the wt_status struct.
This simplifies the "status" code a little bit.
Unfortunately, it makes the "commit" code one line more
complex; a side effect of the separate variable was that
"commit" did not copy the colopts variable, so any
column.status configuration had no effect.
The result still ends up cleaner, though. In the previous
version, it was unclear whether commit simply forgot to copy
the colopt variable, or whether it was intentional. Now it
explicitly turns off column options. Furthermore, if commit
later learns to respect column.status, this will make the
end result simpler. I punted on just adding that feature
now, because it was sufficiently non-obvious that it should
not go into a refactoring patch.
Signed-off-by: Jeff King <peff@peff.net>
There is no reason not to, as the user has to explicitly ask
for it, so we are not breaking compatibility by doing so. We
can do this simply by moving the "show_branch" flag into
the wt_status struct. As a bonus, this saves us from passing
it explicitly, simplifying the code.
Signed-off-by: Jeff King <peff@peff.net>
This option is passed separately to the wt_status printing
functions, whereas every other formatting option is
contained in the wt_status struct itself. Let's do the same
here, so we can avoid passing it around through the call
stack.
Signed-off-by: Jeff King <peff@peff.net>
The options are declared as a static global, but really they
need only be accessible from cmd_commit. Additionally,
declare the "struct wt_status" in cmd_commit and cmd_status
as static at the top of each function; this will let the
options lists reference them directly, which will facilitate
further cleanups.
Signed-off-by: Jeff King <peff@peff.net>
NO_PREAD simulates pread() as a sequence of seek, read, seek in
compat/pread.c. The simulation is not thread-safe because another
thread could move the file offset away in the middle of pread
operation. Do not allow threading in that case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This puts delta resolving on each base on a separate thread, one base
cache per thread. Per-thread data is grouped in struct thread_local.
When running with nr_threads == 1, no pthreads calls are made. The
system essentially runs in non-thread mode.
An experiment on a Xeon 24 core machine with git.git shows that
performance does not increase proportional to the number of cores. So
by default, we use maximum 3 cores. Some numbers with --threads from 1
to 16:
1..4
real 0m8.003s 0m5.307s 0m4.321s 0m3.830s
user 0m7.720s 0m8.009s 0m8.133s 0m8.305s
sys 0m0.224s 0m0.372s 0m0.360s 0m0.360s
5..8
real 0m3.727s 0m3.604s 0m3.332s 0m3.369s
user 0m9.361s 0m9.817s 0m9.525s 0m9.769s
sys 0m0.584s 0m0.624s 0m0.540s 0m0.560s
9..12
real 0m3.036s 0m3.139s 0m3.177s 0m2.961s
user 0m8.977s 0m10.205s 0m9.737s 0m10.073s
sys 0m0.596s 0m0.680s 0m0.684s 0m0.680s
13..16
real 0m2.985s 0m2.894s 0m2.975s 0m2.971s
user 0m9.825s 0m10.573s 0m10.833s 0m11.361s
sys 0m0.788s 0m0.732s 0m0.904s 0m1.016s
On an Intel dual core and linux-2.6.git
1..4
real 2m37.789s 2m7.963s 2m0.920s 1m58.213s
user 2m28.415s 2m52.325s 2m50.176s 2m41.187s
sys 0m7.808s 0m11.181s 0m11.224s 0m10.731s
Thanks Ramsay Jones for troubleshooting and support on MinGW platform.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The second pass in parse_pack_objects() are split into
resolve_deltas(). The final phase, fixing thin pack or just seal the
pack, is now in conclude_pack() function. Main pack processing is now
a sequence of these functions:
- parse_pack_objects() reads through the input pack
- resolve_deltas() makes sure all deltas can be resolved
- conclude_pack() seals the output pack
- write_idx_file() writes companion index file
- final() moves the pack/index to proper place
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 5bd631b3 ("clone: support multiple levels of verbosity"), the
default behavior to show progress of the implicit checkout in
the clone-command regressed so that progress was only shown if
the verbose-option was specified.
Fix this by making option_verbosity == 0 output progress as well.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git checkout switches from a detached HEAD to any other commit, then
all orphaned commits were listed in a warning:
Warning: you are leaving 2 commits behind...:
a5e5396 another fixup
6aa1af6 fixup foo
But if the new commit is actually one from this list (6aa1af6 in this
example), then the list in the warning can be truncated at the new HEAD,
because history beginning at HEAD is not "left behind". This makes it so.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we show a reflog selector (e.g., via "git log -g"), we
perform some DWIM magic: while we normally show the entry's
index (e.g., HEAD@{1}), if the user has given us a date
with "--date", then we show a date-based select (e.g.,
HEAD@{yesterday}).
However, we don't want to trigger this magic if the
alternate date format we got was from the "log.date"
configuration; that is not sufficiently strong context for
us to invoke this particular magic. To fix this, commit
f4ea32f (improve reflog date/number heuristic, 2009-09-24)
introduced a "date_mode_explicit" flag in rev_info. This
flag is set only when we see a "--date" option on the
command line, and we a vanilla date to the reflog code if
the date was not explicit.
Later, commit 8f8f547 (Introduce new pretty formats %g[sdD]
for reflog information, 2009-10-19) added another way to
show selectors, and it did not respect the date_mode_explicit
flag from f4ea32f.
This patch propagates the date_mode_explicit flag to the
pretty-print code, which can then use it to pass the
appropriate date field to the reflog code. This brings the
behavior of "%gd" in line with the other formats, and means
that its output is independent of any user configuration.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Octopus merge strategy did not reduce heads that are recorded in the final
commit correctly.
By Junio C Hamano (4) and Michał Kiedrowicz (1)
* jc/merge-reduce-parents-early:
fmt-merge-msg: discard needless merge parents
builtin/merge.c: reduce parents early
builtin/merge.c: collect other parents early
builtin/merge.c: remove "remoteheads" global variable
merge tests: octopus with redundant parents
The command line parser choked "git cherry-pick $name" when $name can be
both revision name and a pathname, even though $name can never be a path
in the context of the command.
By Clemens Buchacher
* cb/cherry-pick-rev-path-confusion:
cherry-pick: do not expect file arguments
The report from "git fetch" said "new branch" even for a non branch ref.
By Marc Branchaud
* mb/fetch-call-a-non-branch-a-ref:
fetch: describe new refs based on where it came from
fetch: Give remote_ref to update_local_ref() as well
"git push" over smart-http lost progress output and this resurrects it.
By Jeff King
* jk/maint-push-progress:
t5541: test more combinations of --progress
teach send-pack about --[no-]progress
send-pack: show progress when isatty(2)
A couple of commands learn --column option to produce columnar output.
By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1)
* nd/columns:
tag: add --column
column: support piping stdout to external git-column process
status: add --column
branch: add --column
help: reuse print_columns() for help -a
column: add dense layout support
t9002: work around shells that are unable to set COLUMNS to 1
column: add columnar layout
Stop starting pager recursively
Add column layout skeleton and git-column
Many error/warning messages had extra trailing newlines that are
unnecessary.
By Pete Wyckoff
* pw/message-cleanup:
remove blank filename in error message
remove superfluous newlines in error messages
Fix some constructs that build messages meant for i18n by concatenating
pieces of strings.
By Ævar Arnfjörð Bjarmason
* ab/i18n:
git-commit: remove lego in i18n messages
git-commit: remove lego in i18n messages
git-branch: remove lego in i18n messages
More message strings marked for i18n.
By Nguyễn Thái Ngọc Duy (10) and Jonathan Nieder (1)
* nd/i18n:
help: replace underlining "help -a" headers using hyphens with a blank line
i18n: bundle: mark strings for translation
i18n: index-pack: mark strings for translation
i18n: apply: update say_patch_name to give translators complete sentence
i18n: apply: mark strings for translation
i18n: remote: mark strings for translation
i18n: make warn_dangling_symref() automatically append \n
i18n: help: mark strings for translation
i18n: mark relative dates for translation
strbuf: convenience format functions with \n automatically appended
Makefile: feed all header files to xgettext
New users tend to work on one branch at a time and push the result
out. The current and upstream modes of push is a more suitable default
mode than matching mode for these people, but neither is surprise-free
depending on how the project is set up. Introduce a "simple" mode that
is a subset of "upstream" but only works when the branch is named the same
between the remote and local repositories.
The plan is to make it the new default when push.default is not
configured.
By Matthieu Moy (5) and others
* mm/simple-push:
push.default doc: explain simple after upstream
push: document the future default change for push.default (matching -> simple)
t5570: use explicit push refspec
push: introduce new push.default mode "simple"
t5528-push-default.sh: add helper functions
Undocument deprecated alias 'push.default=tracking'
Documentation: explain push.default option a bit more
Trivially shrinks the on-disk size of the index file to save both I/O and
checksum overhead.
The topic should give a solid base to build on further updates, with the
code refactoring in its earlier parts, and the backward compatibility
mechanism in its later parts.
* jc/index-v4:
index-v4: document the entry format
unpack-trees: preserve the index file version of original
update-index: upgrade/downgrade on-disk index version
read-cache.c: write prefix-compressed names in the index
read-cache.c: read prefix-compressed names in index on-disk version v4
read-cache.c: move code to copy incore to ondisk cache to a helper function
read-cache.c: move code to copy ondisk to incore cache to a helper function
read-cache.c: report the header version we do not understand
read-cache.c: make create_from_disk() report number of bytes it consumed
read-cache.c: allow unaligned mapping of the index file
cache.h: hide on-disk index details
varint: make it available outside the context of pack
When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl, may
fail to hold all of them. Now such an internal invocation can feed the
references through the standard input of "fetch-pack".
By Ivan Todoroski
* it/fetch-pack-many-refs:
remote-curl: main test case for the OS command line overflow
fetch-pack: test cases for the new --stdin option
remote-curl: send the refs to fetch-pack on stdin
fetch-pack: new --stdin option to read refs from stdin
Conflicts:
t/t5500-fetch-pack.sh
"git fetch" that recurses into submodules on demand did not check if it
needs to go into submodules when non branches (most notably, tags) are
fetched.
By Jens Lehmann
* jl/maint-submodule-recurse-fetch:
submodules: recursive fetch also checks new tags for submodule commits
"git blame" started missing quite a few changes from the origin since we
stopped using the diff minimalization by default in v1.7.2 era.
Teach "--minimal" option to "git blame" to work around this regression.
* jc/maint-blame-minimal:
blame: accept --need-minimal
The send_pack function gets a "progress" flag saying "yes,
definitely show progress" or "no, definitely do not show
progress". This gets set properly by transport_push when
send_pack is called directly.
However, when the send-pack command is executed separately
(as it is for the remote-curl helper), there is no way to
tell it "definitely do this". As a result, we do not
properly respect "git push --no-progress" for smart-http
remotes; you will still get progress if stderr is a tty.
This patch teaches send-pack --progress and --no-progress,
and teaches remote-curl to pass the appropriate option to
override send-pack's isatty check. This fixes the
--no-progress case above, and as a bonus, also makes "git
push --progress" work when stderr is not a tty.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The send_pack_args struct has two verbosity flags: "quiet"
and "progress". Originally, if "quiet" was set, we would
tell pack-objects explicitly to be quiet, and if "progress"
was set, we would tell it to show progress. Otherwise, we
told it neither, and it relied on isatty(2) to make the
decision itself.
However, commit 01fdc21 changed the meaning of these
variables. Now both "quiet" and "!progress" instruct us to
tell pack-objects to be quiet (and a non-zero "progress"
means the same as before). This works well for transports
which call send_pack directly, as the transport code copies
transport->progress into send_pack_args->progress, and they
both have the same meaning.
However, the code path of calling "git send-pack" was left
behind. It always sets "progress" to 0, and thus always
tells pack-objects to be quiet. We can work around this by
checking isatty(2) ourselves in the cmd_send_pack code path,
restoring the original behavior of the send-pack command.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The error handling routines add a newline. Remove
the duplicate ones in error messages.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git rebase" learned to optionally keep commits that do not introduce
any change in the original history.
By Neil Horman
* nh/empty-rebase:
git-rebase: add keep_empty flag
git-cherry-pick: Add test to validate new options
git-cherry-pick: Add keep-redundant-commits option
git-cherry-pick: add allow-empty option
Change the "Please enter the commit message for your changes." and the
subsequent blurb of text not to be split up. This makes translating it
much easier.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the whence_s() function and messages that depend on it, in favor of
messages that use either "merge" or "cherry-pick" directly.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of making translators translate "remote " and then using
"%sbranch" where "%s" is either "remote " or "" just split the two up
into separate messages. This makes the translation of this section of
git-branch much less confusing.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid writing out unreachable objects as loose objects when repacking,
if such loose objects will immediately pruned due to its age anyway.
By Jeff King
* jk/repack-no-explode-objects-from-old-pack:
gc: use argv-array for sub-commands
argv-array: add a new "pushl" method
argv-array: refactor empty_argv initialization
gc: do not explode objects which will be immediately pruned
Octopus merge strategy did not reduce heads that are recorded in the
final commit correctly.
By Junio C Hamano (4) and Michał Kiedrowicz (1)
* jc/merge-reduce-parents-early:
fmt-merge-msg: discard needless merge parents
builtin/merge.c: reduce parents early
builtin/merge.c: collect other parents early
builtin/merge.c: remove "remoteheads" global variable
merge tests: octopus with redundant parents
The command line parser choked "git cherry-pick $name" when $name can be
both revision name and a pathname, even though $name can never be a path
in the context of the command.
The issue the patch addresses is real, but the way it is implemented felt
unnecessarily invasive a bit. It may be cleaner for this caller to add
the "--" to the end of the argv_array it passes to setup_revisions().
By Clemens Buchacher
* cb/cherry-pick-rev-path-confusion:
cherry-pick: do not expect file arguments
"help -a" also respects column.ui (and column.help if presents)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A column option string consists of many token separated by either
a space or a comma. A token belongs to one of three groups:
- enabling: always, never and auto
- layout mode: currently plain (which does not layout at all)
- other future tuning flags
git-column can be used to pipe output to from a command that wants
column layout, but not to mess with its own output code. Simpler output
code can be changed to use column layout code directly.
Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The report from "git fetch" said "new branch" even for a non branch
ref.
By Marc Branchaud
* mb/fetch-call-a-non-branch-a-ref:
fetch: describe new refs based on where it came from
fetch: Give remote_ref to update_local_ref() as well
The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch is
set to push to a remote different from $there, used to push to $there
using the upstream information to a remote unreleated to $there.
* jc/push-upstream-sanity:
push: error out when the "upstream" semantics does not make sense
Rename detection logic used to match two empty files as renames during
merge-recursive, leading unnatural mismerges.
By Jeff King
* jk/diff-no-rename-empty:
merge-recursive: don't detect renames of empty files
teach diffcore-rename to optionally ignore empty content
make is_empty_blob_sha1 available everywhere
drop casts from users EMPTY_TREE_SHA1_BIN
When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty message",
which was utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
"git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do so
when the end user overrode the authorship via the "GIT_AUTHOR_NAME"
environment variable.
* jc/commit-hook-authorship:
commit: pass author/committer info to hooks
t7503: does pre-commit-hook learn authorship?
ident.c: add split_ident_line() to parse formatted ident line
We used to underline a header text, like this:
This is a header
----------------
content...
But calculating text length so that the dashes align with the text
could get complicated because the text could be in any charset in
translated Git.
There is no point to use this pseudo underline; simply a blank
line would do and it even makes it easier to read:
This is a header
content...
While at it, give translators more context to translate, e.g.
e.g. "git commands available..." instead of "%s available..."
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git push" without argument, we want to allow Git to do
something simple to explain and safe. push.default=matching is unsafe
when used to push to shared repositories, and hard to explain to
beginners in some contexts. It is debatable whether 'upstream' or
'current' is the safest or the easiest to explain, so introduce a new
mode called 'simple' that is the intersection of them: push to the
upstream branch, but only if it has the same name remotely. If not, give
an error that suggests the right command to push explicitely to
'upstream' or 'current'.
A question is whether to allow pushing when no upstream is configured. An
argument in favor of allowing the push is that it makes the new mode work
in more cases. On the other hand, refusing to push when no upstream is
configured encourages the user to set the upstream, which will be
beneficial on the next pull. Lacking better argument, we chose to deny
the push, because it will be easier to change in the future if someone
shows us wrong.
Original-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This helps remove \n from translatable strings
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also marks most common commands' synopsis for translation
so that "git help" gives a friendly listing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl,
may fail to hold all of them. Now such an internal invocation can feed
the references through the standard input of "fetch-pack".
By Ivan Todoroski
* it/fetch-pack-many-refs:
remote-curl: main test case for the OS command line overflow
fetch-pack: test cases for the new --stdin option
remote-curl: send the refs to fetch-pack on stdin
fetch-pack: new --stdin option to read refs from stdin
"git push --recurse-submodules" learns to optionally look into the
histories of submodules bound to the superproject and push them out.
By Heiko Voigt
* hv/submodule-recurse-push:
push: teach --recurse-submodules the on-demand option
Refactor submodule push check to use string list instead of integer
Teach revision walking machinery to walk multiple times sequencially
"git fetch" that recurses into submodules on demand did not check if
it needs to go into submodules when non branches (most notably, tags)
are fetched.
By Jens Lehmann
* jl/maint-submodule-recurse-fetch:
submodules: recursive fetch also checks new tags for submodule commits
"git blame" started missing quite a few changes from the origin since we
stopped using the diff minimalization by default in v1.7.2 era.
* jc/maint-blame-minimal:
blame: accept --need-minimal
Valgrind reports quite a lot of discarded memory inside apply.
Fix them, audit and document the buffer ownership rules.
By Junio C Hamano (8) and Jared Hance (1)
* jh/apply-free-patch:
apply: document buffer ownership rules across functions
apply: tighten constness of line buffer
apply: drop unused macro
apply: free unused fragments for submodule patch
apply: free patch->result
apply: release memory for fn_table
apply: free patch->{def,old,new}_name fields
apply: rename free_patch() to free_patch_list()
apply: do not leak patches and fragments
"git rev-parse --show-prefix" emitted nothing when run at the
top-level of the working tree, while "git rev-parse --show-cdup" gave
an empty line. Make them consistent.
By Ross Lagerwall
* rl/show-empty-prefix:
rev-parse --show-prefix: add in trailing newline
Adds some subcommands that were not listed in "git remote --help"
usage strings.
As an independent follow-up, we may want to rethink how the overall
usage string and subcommand usage strings are maintained.
By Michael Schubert
* ms/remote-usage-string:
remote: update builtin usage
Break down the cases in which "git push" fails due to non-ff into
three categories, and give separate advise messages for each case.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
Fix broken 'push to upstream' implementation. "git push $there" without
refspec, when the current branch is set to push to a remote different from
$there, used to push to $there using the upstream information to a remote
unreleated to $there.
* jc/push-upstream-sanity:
push: error out when the "upstream" semantics does not make sense
The "fmt-merge-msg" command learns to list the primary contributors
involved in the side topic you are merging.
* jc/fmt-merge-msg-people:
fmt-merge-msg: show those involved in a merged series
This is used by "git pull" to construct a merge message from list of
remote refs. When pulling redundant set of refs, however, it did not
filter them even though the merge itself discards them as unnecessary.
Teach the command to do the same for consistency.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gc executes many sub-commands. The argument list for
some of these is constant, but for others we add more
arguments at runtime. The latter is implemented by allocating
a constant extra number of NULLs, and either using a custom
append function, or just referencing unused slots by number.
As of commit 7e52f56, which added two new arguments, it is
possible to exceed the constant number of slots for "repack"
by running "git gc --aggressive", causing "git gc" to die.
This patch converts all of the static argv lists to use
argv-array. In addition to fixing the overflow caused by
7e52f56, it has a few advantages:
1. We can drop the custom append function (which,
incidentally, had an off-by-one error exacerbating the
static limit).
2. We can drop the ugly magic numbers used when adding
arguments to "prune".
3. Adding further arguments will be easier; you can just
add new "push" calls without worrying about increasing
any static limits.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.
The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.
And obviously the known-to-be-broken test in t6028 is now fixed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the code around to populate remoteheads list early in the process
before any decision regarding twohead vs octopus and fast-forwardness is
made.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
update_local_ref() used to say "[new branch]" when we stored a new ref
outside refs/tags/ hierarchy, but the message is more about what we
fetched, so use the refname at the origin to make that decision.
Also, only call a new ref a "branch" if it's under refs/heads/.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way, the function can look at the remote side to adjust the
informational message it gives.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git commit --template F" errors out because the user did not touch
the message, it claimed that it aborts due to "empty message", which was
utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
Even with "-q"uiet option, "checkout" used to report setting up tracking.
Also "branch" learns "-q"uiet option to squelch informational message.
By Jeff King
* jk/branch-quiet:
teach "git branch" a --quiet option
checkout: suppress tracking message with "-q"
Forbids rename detection logic from matching two empty files as renames
during merge-recursive to prevent mismerges.
By Jeff King
* jk/diff-no-rename-empty:
merge-recursive: don't detect renames of empty files
teach diffcore-rename to optionally ignore empty content
make is_empty_blob_sha1 available everywhere
drop casts from users EMPTY_TREE_SHA1_BIN
"git commit --author=$name" did not tell the name that was being recorded
in the resulting commit to hooks, even though it does do so when the end
user overrode the authorship via the "GIT_AUTHOR_NAME" environment
variable.
* jc/commit-hook-authorship:
commit: pass author/committer info to hooks
t7503: does pre-commit-hook learn authorship?
ident.c: add split_ident_line() to parse formatted ident line
Use API to read blob data in smaller chunks in more places to reduce the
memory footprint.
By Nguyễn Thái Ngọc Duy (6) and Junio C Hamano (1)
* nd/stream-more:
update-server-info: respect core.bigfilethreshold
fsck: use streaming API for writing lost-found blobs
show: use streaming API for showing blobs
parse_object: avoid putting whole blob in core
cat-file: use streaming API to print blobs
Add more large blob test cases
streaming: make streaming-write-entry to be more reusable
If a commit-ish passed to cherry-pick or revert happens to have a file
of the same name, git complains that the argument is ambiguous and
advises to use '--'. To make things worse, the '--' argument is removed
by parse_options, und so passing '--' has no effect.
Instead, always interpret cherry-pick/revert arguments as revisions.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 88a21979c (fetch/pull: recurse into submodules when necessary) all
fetched commits are examined if they contain submodule changes (unless
configuration or command line options inhibit that). If a newly recorded
submodule commit is not present in the submodule, a fetch is run inside
it to download that commit.
Checking new refs was done in an else branch where it wasn't executed for
tags. This normally isn't a problem because tags are only fetched with
the branches they live on, then checking the new commits in the fetched
branches for submodule commits will also process all tags. But when a
specific tag is fetched (or the refspec contains refs/tags/) commits only
reachable by tags won't be searched for submodule commits, which is a bug.
Fix that by moving the code outside the if/else construct to handle new
tags just like any other ref. The performance impact of adding tags that
most of the time lie on a branch which is checked anyway for new submodule
commit should be minimal, as since 6859de4 (fetch: avoid quadratic loop
checking for updated submodules) all ref-tips are collected first and then
fed to a single rev-list.
Spotted-by: Jeff King <peff@peff.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In general, the private functions in this file were not very
much documented; even though what each of them do is reasonably
self explanatory, the ownership rules for various buffers and
data structures were not very obvious.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These point into a single line in the patch text we read from
the input, and they are not used to modify it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git cherry-pick fails when picking a non-ff commit that is empty. The advice
given with the failure is that a git-commit --allow-empty should be issued to
explicitly add the empty commit during the cherry pick. This option allows a
user to specify before hand that they want to keep the empty commit. This
eliminates the need to issue both a cherry pick and a commit operation.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between v1.7.1 and v1.7.2, 582aa00bdf switched the default "diff"
invocation not to use XDF_NEED_MINIMAL, but this breaks "git blame"
rather badly.
Allow the command line option to ask for an extra careful matching.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we pack everything into one big pack with "git repack
-Ad", any unreferenced objects in to-be-deleted packs are
exploded into loose objects, with the intent that they will
be examined and possibly cleaned up by the next run of "git
prune".
Since the exploded objects will receive the mtime of the
pack from which they come, if the source pack is old, those
loose objects will end up pruned immediately. In that case,
it is much more efficient to skip the exploding step
entirely for these objects.
This patch teaches pack-objects to receive the expiration
information and avoid writing these objects out. It also
teaches "git gc" to pass the value of gc.pruneexpire to
repack (which in turn learns to pass it along to
pack-objects) so that this optimization happens
automatically during "git gc" and "git gc --auto".
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print out a trailing newline when --show-prefix is run with cwd
at the top level of the tree which results in an empty prefix.
Behavior is now like --show-cdup.
Fixes an expected failure in t1501.
Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add missing options "--tags|--no-tags" and "--push".
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/cache-tree:
t0090: be prepared that 'wc -l' writes leading blanks
reset: update cache-tree data when appropriate
commit: write cache-tree data when writing index anyway
Refactor cache_tree_update idiom from commit
Test the current state of the cache-tree optimization
Add test-scrap-cache-tree
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the "--index-version <n>" parameter, write the index out in the
specified version. With this, an index file that is written in newer
format (say v4) can be downgraded to be read by older versions of Git.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a remote repo has too many tags (or branches), cloning it over the
smart HTTP transport can fail because remote-curl.c puts all the refs
from the remote repo on the fetch-pack command line. This can make the
command line longer than the global OS command line limit, causing
fetch-pack to fail.
This is especially a problem on Windows where the command line limit is
orders of magnitude shorter than Linux. There are already real repos out
there that msysGit cannot clone over smart HTTP due to this problem.
Here is an easy way to trigger this problem:
git init too-many-refs
cd too-many-refs
echo bla > bla.txt
git add .
git commit -m test
sha=$(git rev-parse HEAD)
tag=$(perl -e 'print "bla" x 30')
for i in `seq 50000`; do
echo $sha refs/tags/$tag-$i >> .git/packed-refs
done
Then share this repo over the smart HTTP protocol and try cloning it:
$ git clone http://localhost/.../too-many-refs/.git
Cloning into 'too-many-refs'...
fatal: cannot exec 'fetch-pack': Argument list too long
50k tags is obviously an absurd number, but it is required to
demonstrate the problem on Linux because it has a much more generous
command line limit. On Windows the clone fails with as little as 500
tags in the above loop, which is getting uncomfortably close to the
number of tags you might see in real long lived repos.
This is not just theoretical, msysGit is already failing to clone our
company repo due to this. It's a large repo converted from CVS, nearly
10 years of history.
Four possible solutions were discussed on the Git mailing list (in no
particular order):
1) Call fetch-pack multiple times with smaller batches of refs.
This was dismissed as inefficient and inelegant.
2) Add option --refs-fd=$n to pass a an fd from where to read the refs.
This was rejected because inheriting descriptors other than
stdin/stdout/stderr through exec() is apparently problematic on Windows,
plus it would require changes to the run-command API to open extra
pipes.
3) Add option --refs-from=$tmpfile to pass the refs using a temp file.
This was not favored because of the temp file requirement.
4) Add option --stdin to pass the refs on stdin, one per line.
In the end this option was chosen as the most efficient and most
desirable from scripting perspective.
There was however a small complication when using stdin to pass refs to
fetch-pack. The --stateless-rpc option to fetch-pack also uses stdin for
communication with the remote server.
If we are going to sneak refs on stdin line by line, it would have to be
done very carefully in the presence of --stateless-rpc, because when
reading refs line by line we might read ahead too much data into our
buffer and eat some of the remote protocol data which is also coming on
stdin.
One way to solve this would be to refactor get_remote_heads() in
fetch-pack.c to accept a residual buffer from our stdin line parsing
above, but this function is used in several places so other callers
would be burdened by this residual buffer interface even when most of
them don't need it.
In the end we settled on the following solution:
If --stdin is specified without --stateless-rpc, fetch-pack would read
the refs from stdin one per line, in a script friendly format.
However if --stdin is specified together with --stateless-rpc,
fetch-pack would read the refs from stdin in packetized format
(pkt-line) with a flush packet terminating the list of refs. This way we
can read the exact number of bytes that we need from stdin, and then
get_remote_heads() can continue reading from the same fd without losing
a single byte of remote protocol data.
This way the --stdin option only loses generality and scriptability when
used together with --stateless-rpc, which is not easily scriptable
anyway because it also uses pkt-line when talking to the remote server.
Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).
This was because the original template support was done by piggybacking on
the check to detect an empty log message. Split the codepaths into two
independent checks to clarify the error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored. However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using this option git will search for all submodules that
have changed in the revisions to be send. It will then try to
push the currently checked out branch of each submodule.
This helps when a user has finished working on a change which
involves submodules and just wants to push everything in one go.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We simply discarded the fragments that we are not going to use upon seeing
a patch to update the submodule commit bound at path that we have not
checked out.
Free these fragments, not to leak them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
v1.7.9-8-g270a344 (config: stop using config_exclusive_filename) replaced
config_exclusive_filename with given_config_file. In one case this
resulted in a self-assignment, which is reported by clang as a warning.
Remove the useless code.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is by far the largest piece of data, much larger than the patch and
fragment structures or the three name fields in the patch structure.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fn_table is used to record the result of earlier patch application in
case a hand-crafted input file contains multiple patches to the same file.
Both its string key (filename) and the contents are borrowed from "struct
patch" that represents the previous application in the same apply_patch()
call, and they do not leak, but the table itself was not freed properly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were all allocated in the heap by parsing the header parts of the
patch, but we did not bother to free them. Some used to share the memory
(e.g. copying def_name to old_name) so this is not just the matter of
adding three calls to free().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages. This
patch provides a "-q" option to do so.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like the "switched to..." message (which is already
suppressed by "-q"), this message is purely informational.
Let's silence it if the user asked us to be quiet.
This patch is slightly more than a one-liner, because we
have to teach create_branch to propagate the flag all the
way down to install_branch_config.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.
Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As we already walk the history of the branch that gets merged to
come up with a short log, let's label it with names of the primary
authors, so that the user who summarizes the merge can easily give
credit to them in the log message.
Also infer the names of "lieutents" to help integrators at higher
level of the food-chain to give credit to them, by counting:
* The committer of the 'tip' commit that is merged
* The committer of merge commits that are merged
Often the first one gives the owner of the history being pulled, but
his last pull from his sublieutenants may have been a fast-forward,
in which case the first one would not be. The latter rule will
count the integrator of the history, so together it might be a
reasonable heuristics.
There are two special cases:
- The "author" credit is omitted when the series is written solely
by the same author who is making the merge. The name can be seen
on the "Author" line of the "git log" output to view the log
message anyway.
- The "lieutenant" credit is omitted when there is only one key
committer in the merged branch and it is the committer who is
making the merge. Typically this applies to the case where the
developer merges his own branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git tag -s" honored "gpg.program" configuration variable since
1.7.9, but "git tag -v" and "git verify-tag" didn't.
By Alex Zepeda
* az/verify-tag-use-gpg-config:
verify-tag: Parse GPG configuration options.
When lying the author name via GIT_AUTHOR_NAME environment variable
to "git commit", the hooks run by the command saw it and could act
on the name that will be recorded in the final commit. When the user
uses the "--author" option from the command line, the command should
give the same information to the hook, and back when "git command"
was a scripted Porcelain, it did set the environment variable and
hooks can learn the author name from it.
However, when the command was reimplemented in C, the rewritten code
was not very faithful to the original, and hooks stopped getting the
authorship information given with "--author". Fix this by exporting
the necessary environment variables.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify verify-tag to load relevant GPG variables from the git
configuratio file. This allows git tag -v to use an alternative
GPG binary in the same way that git tag -s does.
Signed-off-by: Alex Zepeda <alex@inferiorhumanorgans.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the while loop inside apply_patch, patch and fragments are
dynamically allocated with a calloc. However, only unused patches
are actually freed and the rest are left to leak. Since a list is
actively built up consisting of the used patches, they can simply be
iterated and freed at the end of the function.
In addition, the text in fragments were not freed, primarily because
they mostly point into a patch text that is freed as a whole. But
there are some cases where new piece of memory is allocated and
pointed by a fragment (namely, when handling a binary patch).
Introduce a free_patch bitfield to mark each fragment if its text
needs to be freed, and free patches, fragments and fragment text
that need to be freed when we are done with the input.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both git-prune and git-repack (and thus, git-gc) try to rmdir while
holding a DIR* handle on the directory. This can leave dangling
empty directories in the .git/objects on platforms where directory
cannot be removed while they are open.
First call closedir() and then rmdir(); that is more logical ordering.
Reported-by: John Chen <john0312@gmail.com>
Reported-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Improved-and-Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command indirectly calls check_sha1_signature() (add_info_ref ->
deref_tag -> parse_object -> ..) , which may put whole blob in memory
if the blob's size is under core.bigfilethreshold. As config is not
read, the threshold is always 512MB. Respect user settings here.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1)
* zj/diff-stat-dyncol:
: This breaks tests. Perhaps it is not worth using the decimal-width stuff
: for this series, at least initially.
diff --stat: add config option to limit graph width
diff --stat: enable limiting of the graph part
diff --stat: add a test for output with COLUMNS=40
diff --stat: use a maximum of 5/8 for the filename part
merge --stat: use the full terminal width
log --stat: use the full terminal width
show --stat: use the full terminal width
diff --stat: use the full terminal width
diff --stat: tests for long filenames and big change counts
Config option diff.statGraphWidth=<width> is equivalent to
--stat-graph-width=<width>, except that the config option is ignored
by format-patch.
For the graph-width limiting to be usable, it should happen
'automatically' once configured, hence the config option.
Nevertheless, graph width limiting only makes sense when used on a
wide terminal, so it should not influence the output of format-patch,
which adheres to the 80-column standard.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make merge --stat behave like diff --stat and use the full terminal
width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make log --stat behave like diff --stat and use the full terminal
width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make show --stat behave like diff --stat and use the full terminal
width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Default to the real terminal width for diff --stat output, instead
of the hard-coded 80 columns.
Some projects (especially in Java), have long filename paths, with
nested directories or long individual filenames. When files are
renamed, the filename part in stat output can be almost useless. If
the middle part between { and } is long (because the file was moved to
a completely different directory), then most of the path would be
truncated.
It makes sense to detect and use the full terminal width and display
full filenames if possible.
The are commands like diff, show, and log, which can adapt the output
to the terminal width. There are also commands like format-patch,
whose output should be independent of the terminal width. Since it is
safer to use the 80-column default, the real terminal width is only
used if requested by the calling code by setting diffopts.stat_width=-1.
Normally this value is 0, and can be set by the user only to a
non-negative value, so -1 is safe to use internally.
This patch only changes the diff builtin to use the full terminal width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default output from "fsck" is often overwhelmed by informational
message on dangling objects, especially if you do not repack often, and a
real error can easily be buried.
Add "--no-dangling" option to omit them, and update the user manual to
demonstrate its use.
Based on a patch by Clemens Buchacher, but reverted the part to change
the default to --no-dangling, which is unsuitable for the first patch.
The usual three-step procedure to break the backward compatibility over
time needs to happen on top of this, if we were to go in that direction.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
PARSE_OPT_NEGHELP is confusing because short options defined with that
flag do the opposite of what the helptext says. It is also not needed
anymore now that options starting with no- can be negated by removing
that prefix. Convert its only two users to OPT_NEGBIT() and OPT_BOOL()
and then remove support for PARSE_OPT_NEGHELP.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --quiet is specified, finish_object() is called instead of
show_object(). The latter is in charge of --verify-objects and
will be skipped if --quiet is specified.
Move the code up to finish_object(). Also pass the quiet flag along
and make it always call show_* functions to avoid similar problems in
future.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since c99f069 (bisect--helper: remove "--next-vars" option as it is
now useless - 2009-04-21), this flag has always been off. Remove the
flag and all related code.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It can be helpful to resolve a symbolic ref and output the result in a
shortened form, such as for use in shell prompts. Add a "--short" option
to do so.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
print_ref_list looks up the merge_filter_ref and assumes that a valid
pointer is returned. When the object doesn't exist, it tries to
dereference a NULL pointer. This can be the case when git branch
--merged is given an argument that isn't a valid commit name.
Check whether the lookup returns a NULL pointer and die with an error
if it does. Add a test, while we're at it.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fc/push-prune:
push: add '--prune' option
remote: refactor code into alloc_delete_ref()
remote: reorganize check_pattern_match()
remote: use a local variable in match_push_refs()
Conflicts:
builtin/push.c
It looks like commit 99fb6e04 (pack-objects: convert to use
parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
hasn't noticed that the 'arg' variable no longer is available.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/config-include:
: An assignment to the include.path pseudo-variable causes the named file
: to be included in-place when Git looks up configuration variables.
config: add include directive
config: eliminate config_exclusive_filename
config: stop using config_exclusive_filename
config: provide a version of git_config with more options
config: teach git_config_rename_section a file argument
config: teach git_config_set_multivar_in_file a default path
config: copy the return value of prefix_filename
t1300: add missing &&-chaining
docs/api-config: minor clarifications
docs: add a basic description of the config API
The heuristic used by "git merge" to decide if it automatically gives an
editor upon clean automerge is to see if the standard input and the
standard output is the same device and is a tty, we are in an interactive
session. "The same device" test was done by comparing fstat(2) result on
the two file descriptors (and they must match), and we asked isatty() only
for the standard input (we insist that they are the same device and there
is no point asking tty-ness of the standard output).
The stat(2) emulation in the Windows port however does not give a usable
value in the st_ino field, so even if the standard output is connected to
something different from the standard input, "The same device" test may
incorrectly return true. To accomodate it, add another isatty() check for
the standard output stream as well.
Reported-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing groups of refs to a remote, there is no simple way to remove
old refs that still exist at the remote that is no longer updated from us.
This will allow us to remove such refs from the remote.
With this change, running this command
$ git push --prune remote refs/heads/*:refs/remotes/laptop/*
removes refs/remotes/laptop/foo from the remote if we do not have branch
"foo" locally anymore.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/grep-binary-attribute:
grep: pre-load userdiff drivers when threaded
grep: load file data after checking binary-ness
grep: respect diff attributes for binary-ness
grep: cache userdiff_driver in grep_source
grep: drop grep_buffer's "name" parameter
convert git-grep to use grep_source interface
grep: refactor the concept of "grep source" into an object
grep: move sha1-reading mutex into low-level code
grep: make locking flag global
The canonical order of command line arguments is always to have dashed
commands before other parameters, but the "git remote set-branches"
subcommand was described to take "name" before an optional "--add".
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.
Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:
1. A relative path specified by GIT_CONFIG=foo will look
in the wrong directory if we have to chdir as part of
repository setup. We already handle this properly for
"git config -f foo", but the GIT_CONFIG lookup used
config_exclusive_filename directly. By dropping to a
single magic variable, the GIT_CONFIG case now just
works.
2. Calling "git config -f foo --edit" would not respect
core.editor. This is because just before editing, we
called git_config, which would respect the
config_exclusive_filename setting, even though this
particular git_config call was not about looking in the
user's specified file, but rather about loading actual
git config, just as any other git program would.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prefix_filename function returns a pointer to a static
buffer which may be overwritten by subsequent calls. Since
we are going to keep the result around for a while, let's be
sure to duplicate it for safety.
I don't think this can be triggered as a bug in the current
code, but it's a good idea to be defensive, as any resulting
bug would be quite subtle.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/blame.c has a helper function to compute how many columns
we need to show a line-number, whose implementation is reusable as
a more generic helper function to count the number of columns
necessary to show any cardinal number.
Rename it to decimal_width(), move it to pager.c and export it for
use by future callers.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/grep-binary-attribute:
grep: pre-load userdiff drivers when threaded
grep: load file data after checking binary-ness
grep: respect diff attributes for binary-ness
grep: cache userdiff_driver in grep_source
grep: drop grep_buffer's "name" parameter
convert git-grep to use grep_source interface
grep: refactor the concept of "grep source" into an object
grep: move sha1-reading mutex into low-level code
grep: make locking flag global
* nd/pack-objects-parseopt:
pack-objects: convert to use parse_options()
pack-objects: remove bogus comment
pack-objects: do not accept "--index-version=version,"
* mh/war-on-extra-refs:
refs: remove the extra_refs API
clone: do not add alternate references to extra_refs
everything_local(): mark alternate refs as complete
fetch-pack.c: inline insert_alternate_refs()
fetch-pack.c: rename some parameters from "path" to "refname"
clone.c: move more code into the "if (refs)" conditional
t5700: document a failure of alternates to affect fetch
* jk/maint-tag-show-fixes:
tag: do not show non-tag contents with "-n"
tag: die when listing missing or corrupt objects
tag: fix output of "tag -n" when errors occur
Conflicts:
t/t7004-tag.sh
Receive runs rev-list --verify-objects in order to detect missing
objects. However, such errors are ignored and overridden later.
Instead, consequently ignore all update commands for which an error has
already been detected.
Some tests in t5504 are obsoleted by this change, because invalid
objects are detected even if fsck is not enabled. Instead, they now test
for different error messages depending on whether or not fsck is turned
on. A better fix would be to force a corruption that will be detected by
fsck but not by rev-list.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, progress output is disabled if stderr is not a terminal.
The --progress option can be used to force progress output anyways.
Conversely, --no-progress does not force progress output. In particular,
if stderr is a terminal, progress output is enabled.
This is unintuitive. Change --no-progress to force output off.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git rev-list passes rev_list_info, not rev_list objects. Without this
fix, rev-list enables or disables the --verify-objects option depending
on a read from an undefined memory location.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, sparse complains as follows:
SP builtin/tag.c
builtin/tag.c:411:5: warning: symbol 'parse_opt_points_at' was \
not declared. Should it be static?
In order to suppress the warning, since the parse_opt_points_at()
function does not need to be an external symbol, we simply add the
static modifier to the function definition.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-tag-show-fixes:
tag: do not show non-tag contents with "-n"
tag: die when listing missing or corrupt objects
tag: fix output of "tag -n" when errors occur
Conflicts:
t/t7004-tag.sh
Alternate references are directly (and now, correctly) handled by
fetch-pack, so there is no need to inform fetch-pack about them via
the extra_refs back channel.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Objects in an alternate object database are already available to the
local repository and therefore don't need to be fetched. So mark them
as complete in everything_local().
This fixes a test in t5700.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic of the (single) caller is clearer without encapsulating this
one line in a function.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parameters denote reference names, which are no longer 1:1 with
filesystem paths.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bahavior of a bunch of code before the "if (refs)" statement also
depends on whether refs is set, so make the logic clearer by shifting
this code into the if statement.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user explicitly asked us not to, don't launch an editor.
But do everything else the same way as the "edit" case, i.e. leave the
comment with verification result in the log template and record the
mergesig in the resulting merge commit for later inspection.
Based on initiail analysis by Jonathan Nieder.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git tag -n" did not check the type of the object it is reading the top n
lines from. At least, avoid showing the beginning of trees and blobs when
dealing with lightweight tags that point at them.
As the payload of a tag and a commit look similar in that they both start
with a header block, which is skipped for the purpose of "-n" output,
followed by human readable text, allow the message of commit objects to be
shown just like the contents of tag objects. This avoids regression for
people who have been using "tag -n" to show the log messages of commits
that are pointed at by lightweight tags.
Test script is from Jeff King.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This filters the list for tags of the given object.
Example,
john$ git tag v1.0-john v1.0
john$ git tag -l --points-at v1.0
v1.0-john
v1.0
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the HEAD of the submodule matches what is recorded in the index of
the superproject, and it has local changes or untracked files, the patch
offered by "git add -e" for editing shows a diff like this:
diff --git a/submodule b/submodule
<header>
-deadbeef...
+deadbeef...-dirty
Because applying such a patch has no effect to the index, this is a
useless noise. Generate the patch with IGNORE_DIRTY_SUBMODULES flag to
prevent such a change from getting reported.
This patch also loses the "-dirty" suffix from the output when the HEAD of
the submodule is different from what is in the index of the superproject.
As such dirtiness expressed by the suffix does not affect the result of
the patch application at all, there is no information lost if we remove
it. The user could still run "git status" before "git add -e" if s/he
cares about the dirtiness.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running "git checkout -b another" immediately after "git init" when you do
not even have a commit on 'master' fails with:
$ git checkout -b another
fatal: You are on a branch yet to be born
This is unnecessary, if we redefine "git checkout -b $name" that does not
take any $start_point (which has to be a commit) as "I want to check out a
new branch $name from the state I am in".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't usually bother looking at tagged objects at all
when listing. However, if "-n" is specified, we open the
objects to read the annotations of the tags. If we fail to
read an object, or if the object has zero length, we simply
silently return.
The first case is an indication of a broken or corrupt repo,
and we should notify the user of the error.
The second case is OK to silently ignore; however, the
existing code leaked the buffer returned by read_sha1_file.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git tag" is instructed to print lines from annotated
tags via "-n", it first prints the tag name, then attempts
to parse and print the lines of the tag object, and then
finally adds a trailing newline.
If an error occurs, we return early from the function and
never print the newline, screwing up the output for the next
tag. Let's factor the line-printing into its own function so
we can manage the early returns better, and make sure that
we always terminate the line.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cb/push-quiet:
t5541: avoid TAP test miscounting
fix push --quiet: add 'quiet' capability to receive-pack
server_supports(): parse feature list more carefully
It is very easy to mistype the branch name when editing its description,
e.g.
$ git checkout -b my-topic master
: work work work
: now we are at a good point to switch working something else
$ git checkout master
: ah, let's write it down before we forget what we were doing
$ git branch --edit-description my-tpoic
The command does not notice that branch 'my-tpoic' does not exist. It is
not lost (it becomes description of an unborn my-tpoic branch), but is not
very useful. So detect such a case and error out to reduce the grief
factor from this common mistake.
This incidentally also errors out --edit-description when the HEAD points
at an unborn branch (immediately after "init", or "checkout --orphan"),
because at that point, you do not even have any commit that is part of
your history and there is no point in describing how this particular
branch is different from the branch it forked off of, which is the useful
bit of information the branch description is designed to capture.
We may want to special case the unborn case later, but that is outside the
scope of this patch to prevent more common mistakes before 1.7.9 series
gains too much widespread use.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge"
always creates a merge commit, even when the tag points at a commit that
happens to be a descendant of your current commit.
Unfortunately, this interacts rather badly for people who use --ff-only to
make sure that their branch is free of local developments. It used to be
possible to say:
$ git checkout -b frotz v1.7.9~30
$ git merge --ff-only v1.7.9
and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka
the commit tagged as v1.7.9), but this fails with the updated Git with:
fatal: Not possible to fast-forward, aborting.
because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by
fast forwarding.
We could teach users that now they have to do
$ git merge --ff-only v1.7.9^0
but it is far more pleasant for users if we DWIMmed this ourselves.
When an integrator pulls in a topic from a lieutenant via a signed tag,
even when the work done by the lieutenant happens to fast-forward, the
integrator wants to have a merge record, so the integrator will not be
asking for --ff-only when running "git pull" in such a case. Therefore,
this change should not regress the support for the use case v1.7.9 wanted
to add.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --stat" and "git apply --stat" now learn to print the line
"%d files changed, %d insertions(+), %d deletions(-)" in singular form
whenever applicable. "0 insertions" and "0 deletions" are also omitted
unless they are both zero.
This matches how versions of "diffstat" that are not prehistoric produced
their output, and also makes this line translatable.
[jc: with help from Thomas Dickey in archaeology of "diffstat"]
[jc: squashed Jonathan's updates to illustrations in tutorials and a test]
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only place that the issue this series addresses was observed
where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE
in order to replay a commit with an ancient timestamp.
With the previous patch alone, "git commit --date='20100917 +0900'"
can be misinterpreted to mean an ancient timestamp, not September in
year 2010. Guard this codepath by requring an extra '@' in front of
the raw git timestamp on the parsing side. This of course needs to
be compensated by updating get_author_ident_from_commit and the code
for "git commit --amend" to prepend '@' to the string read from the
existing commit in the GIT_AUTHOR_DATE environment variable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you specify a local repository on the command line of
clone, ls-remote, upload-pack, receive-pack, or upload-archive,
or in a request to git-daemon, we perform a little bit of
lookup magic, doing things like looking in working trees for
.git directories and appending ".git" for bare repos.
For clone, this magic happens in get_repo_path. For
everything else, it happens in enter_repo. In both cases,
there are some ambiguous or confusing cases that aren't
handled well, and there is one case that is not handled the
same by both methods.
This patch tries to provide (and test!) standard, sensible
lookup rules for both code paths. The intended changes are:
1. When looking up "foo", we have always preferred
a working tree "foo" (containing "foo/.git" over the
bare "foo.git". But we did not prefer a bare "foo" over
"foo.git". With this patch, we do so.
2. We would select directories that existed but didn't
actually look like git repositories. With this patch,
we make sure a selected directory looks like a git
repo. Not only is this more sensible in general, but it
will help anybody who is negatively affected by change
(1) negatively (e.g., if they had "foo.git" next to its
separate work tree "foo", and expect to keep finding
"foo.git" when they reference "foo").
3. The enter_repo code path would, given "foo", look for
"foo.git/.git" (i.e., do the ".git" append magic even
for a repo with working tree). The clone code path did
not; with this patch, they now behave the same.
In the unlikely case of a working tree overlaying a bare
repo (i.e., a ".git" directory _inside_ a bare repo), we
continue to treat it as a working tree (prefering the
"inner" .git over the bare repo). This is mainly because the
combination seems nonsensical, and I'd rather stick with
existing behavior on the off chance that somebody is relying
on it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The low-level grep_source code will automatically load the
userdiff driver to see whether a file is binary. However,
when we are threaded, it will load the drivers in a
non-deterministic order, handling each one as its assigned
thread happens to be scheduled.
Meanwhile, the attribute lookup code (which underlies the
userdiff driver lookup) is optimized to handle paths in
sequential order (because they tend to share the same
gitattributes files). Multi-threading the lookups destroys
the locality and makes this optimization less effective.
We can fix this by pre-loading the userdiff driver in the
main thread, before we hand off the file to a worker thread.
My best-of-five for "git grep foo" on the linux-2.6
repository went from:
real 0m0.391s
user 0m1.708s
sys 0m0.584s
to:
real 0m0.360s
user 0m1.576s
sys 0m0.572s
Not a huge speedup, but it's quite easy to do. The only
trick is that we shouldn't perform this optimization if "-a"
was used, in which case we won't bother checking whether
the files are binary at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The grep_source interface (as opposed to grep_buffer) will
eventually gives us a richer interface for telling the
low-level grep code about our buffers. Eventually this will
lead to things like better binary-file handling. For now, it
lets us drop a lot of now-redundant code.
The conversion is mostly straight-forward. One thing to note
is that the memory ownership rules for "struct grep_source"
are different than the "struct work_item" found here (the
former will copy things like the filename, rather than
taking ownership). Therefore you will also see some slight
tweaking of when filename buffers are released.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The multi-threaded git-grep code needs to serialize access
to the thread-unsafe read_sha1_file call. It does this with
a mutex that is local to builtin/grep.c.
Let's instead push this down into grep.c, where it can be
used by both builtin/grep.c and grep.c. This will let us
safely teach the low-level grep.c code tricks that involve
reading from the object db.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The low-level grep code traditionally didn't care about
threading, as it doesn't do any threading itself and didn't
call out to other non-thread-safe code. That changed with
0579f91 (grep: enable threading with -p and -W using lazy
attribute lookup, 2011-12-12), which pushed the lookup of
funcname attributes (which is not thread-safe) into the
low-level grep code.
As a result, the low-level code learned about a new global
"grep_attr_mutex" to serialize access to the attribute code.
A multi-threaded caller (e.g., builtin/grep.c) is expected
to initialize the mutex and set "use_threads" in the
grep_opt structure. The low-level code only uses the lock if
use_threads is set.
However, putting the use_threads flag into the grep_opt
struct is not the most logical place. Whether threading is
in use is not something that matters for each call to
grep_buffer, but is instead global to the whole program
(i.e., if any thread is doing multi-threaded grep, every
other thread, even if it thinks it is doing its own
single-threaded grep, would need to use the locking). In
practice, this distinction isn't a problem for us, because
the only user of multi-threaded grep is "git-grep", which
does nothing except call grep.
This patch turns the opt->use_threads flag into a global
flag. More important than the nit-picking semantic argument
above is that this means that the locking functions don't
need to actually have access to a grep_opt to know whether
to lock. Which in turn can make adding new locks simpler, as
we don't need to pass around a grep_opt.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the "merge/cherry-pick" messages in whence_s for translation.
These messages returned from whence_s function are used as argument
to build other messages.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment was introduced in b5d97e6 (pack-objects: run rev-list
equivalent internally. - 2006-09-04), stating that
git pack-objects [options] base-name <refs...>
is acceptable and refs should be passed into rev-list. But that's not
true. All arguments after base-name are ignored.
Remove the comment and reject this syntax (i.e. no more arguments after
base name)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/clone-detached:
clone: fix up delay cloning conditions
push: do not let configured foreign-vcs permanently clobbered
clone: print advice on checking out detached HEAD
clone: allow --branch to take a tag
clone: refuse to clone if --branch points to bogus ref
clone: --branch=<branch> always means refs/heads/<branch>
clone: delay cloning until after remote HEAD checking
clone: factor out remote ref writing
clone: factor out HEAD update code
clone: factor out checkout code
clone: write detached HEAD in bare repositories
t5601: add missing && cascade
Before f824628 (merge: use editor by default in interactive sessions,
2012-01-10), git-merge only started an editor if the user explicitly
asked for it with --edit. Thus it seemed unlikely that the user would
need extra guidance.
After f824628 the _normal_ thing is to start an editor. Give at least
an indication of why we are doing it.
The sentence about justification is one of the few things about
standard git that are not agnostic to the workflow that the user
chose. However, f824628 was proposed by Linus specifically to
discourage users from merging unrelated upstream progress into topic
branches. So we may as well take another step in the same direction.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/index-pack-no-recurse:
index-pack: eliminate unlimited recursion in get_base_data()
index-pack: eliminate recursion in find_unresolved_deltas
Eliminate recursion in setting/clearing marks in commit list
* mh/ref-clone-without-extra-refs:
write_remote_refs(): create packed (rather than extra) refs
add_packed_ref(): new function in the refs API.
ref_array: keep track of whether references are sorted
pack_refs(): remove redundant check
* cb/push-quiet:
t5541: avoid TAP test miscounting
fix push --quiet: add 'quiet' capability to receive-pack
server_supports(): parse feature list more carefully
6f48d39 (clone: delay cloning until after remote HEAD checking -
2012-01-16) allows us to perform some checks on remote refs before the
actual cloning happens. But not all transport types support
this. Remote helper with "import" capability will not return complete
ref information until fetch is performed and therefore the clone cannot
be delayed.
foreign_vcs field in struct remote was used to detect this kind of transport
and save the result. This is a mistake because foreign_vcs is designed
to override url-based transport detection. As a result, if the same
"struct transport *" object is used on many different urls and one of
them attached remote transport, the following urls will be mistakenly
attached to the same transport. This fault is worked around by dad0b3d
(push: do not let configured foreign-vcs permanently clobbered -
2012-01-23)
To fix this, detect incomplete refs from transport_get_remote_refs()
by SHA-1. Incomplete ones must have null SHA-1 (*). Then revert
changes related to foreign_cvs field in 6f48d39 and dad0b3d.
A good thing from this change is that cloning smart http transport can
also be delayed. Earlier it falls into the same category "remote
transport, no delay".
(*) Theoretically if one of the remote refs happens to have null SHA-1,
it will trigger false alarm and the clone will not be delayed. But
that chance may be too small for us to pay attention to.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently, 6f48d39 (clone: delay cloning until after remote HEAD checking,
2012-01-16) tried to record if a remote helper needs to be called after
parsing the remote when transport_get() is called, by overwriting the
field meant to store the configured remote helper name in the remote
structure.
This is OK when a remote represents a single remote repository, but fails
miserably when pushing to locations with multiple URLs, like this:
$ cat .git/config
[remote "origin"]
url = https://code.google.com/p/git-htmldocs/
url = github.com:gitster/git-htmldocs.git
push = refs/heads/master:refs/heads/master
$ git push
The second url that is supposed to use the git-over-ssh transport
mistakenly use https:// and fails with:
error: Couldn't resolve host 'github.com:gitster' while accessing
github.com:gitster/git-htmldocs.git/info/refs
fatal: HTTP request failed
The right solution would probably be to dedicate a separate field to store
the detected external helper to be used, which is valid only during a
single use of transport until it is disconnected, instead of overwriting
foreign_vcs field, but in the meantime, this band-aid should suffice.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally, a cleanly resolved merge was committed by "git merge" using
the auto-generated merge commit log message without invoking the editor.
After 5 years of use in the field, it turns out that people perform too
many unjustified merges of the upstream history into their topic branches.
These merges are not just useless, but they are often not explained well,
and making the end result unreadable when it gets time for merging their
history back to their upstream.
Earlier we added the "--edit" option to the command, so that people can
edit the log message to explain and justify their merge commits. Let's
take it one step further and spawn the editor by default when we are in an
interactive session (i.e. the standard input and the standard output are
pointing at the same tty device).
There may be existing scripts that leave the standard input and the
standard output of the "git merge" connected to whatever environment the
scripts were started, and such invocation might trigger the above
"interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable
can be set to "no" at the beginning of such scripts to use the historical
behaviour while the script runs.
Note that this backward compatibility is meant only for scripts, and we
deliberately do *not* support "merge.edit = yes/no/auto" configuration
option to allow people to keep the historical behaviour.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In threaded mode, git-grep emits file breaks (enabled with context, -W
and --break) into the accumulation buffers even if they are not
required. The output collection thread then uses skip_first_line to
skip the first such line in the output, which would otherwise be at
the very top.
This is wrong when the user also specified -l/-L/-c, in which case
every line is relevant. While arguably giving these options together
doesn't make any sense, git-grep has always quietly accepted it. So
do not skip anything in these cases.
Signed-off-by: Albert Yale <surfingalbert@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
write_remote_refs() creates new packed refs from references obtained
from the remote repository, which is "out of thin air" as far as the
local repository is concerned. Previously it did this by creating
"extra" refs, then calling pack_refs() to bake them into the
packed-refs file. Instead, create packed refs (in the packed
reference cache) directly, then call pack_refs().
Aside from being more logical, this is another step towards removing
extra refs entirely.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a tag ref cannot be put to HEAD, HEAD will become detached.
This is consistent with "git checkout <tag>".
This is mostly useful in shallow clone, where it allows you to clone a
tag in addtion to branches.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's possible that users make a typo in the branch name. Stop and let
users recheck. Falling back to remote's HEAD is not documented any
way.
Except when using remote helper, the pack has not been transferred at
this stage yet so we don't waste much bandwidth.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It does not make sense to look outside refs/heads for HEAD's target
(src_ref_prefix can be set to "refs/" if --mirror is used) because ref
code only allows symref in form refs/heads/...
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives us an opportunity to abort the command during remote HEAD
check without wasting much bandwidth.
Cloning with remote-helper remains before the check because the remote
helper updates mapped_refs, which is necessary for remote ref checks.
foreign_vcs field is used to indicate the transport is handled by
remote helper.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While at it, update the comment at "if (remote_head)"
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Read HEAD from disk instead of relying on local variable
our_head_points_at, so that if earlier code fails to make HEAD
properly, it'll be detected.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we don't write, HEAD is still at refs/heads/master as initialized
by init-db, which may or may not match remote's HEAD.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic for the -b mode, where [PATCH] is dropped but [foo] is not,
silently ate all spaces after the ].
Fix this by keeping the next isspace() character, if there is any.
Being more thorough is pointless, as the later cleanup_space() call
will normalize any sequence of whitespace to a single ' '.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revese the order of delta applying so that by the time a delta is
applied, its base is either non-delta or already inflated.
get_base_data() is still recursive, but because base's data is always
ready, the inner get_base_data() call never has any chance to call
itself again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Current find_unresolved_deltas() links all bases together in a form of
tree, using struct base_data, with prev_base pointer to point to
parent node. Then it traverses down from parent to children in
recursive manner with all base_data allocated on stack.
To eliminate recursion, we simply need to put all on heap
(parse_pack_objects and fix_unresolved_deltas). After that, it's
simple non-recursive depth-first traversal loop. Each node also
maintains its own state (ofs and ref indices) to iterate over all
children nodes.
So we process one node:
- if it returns a new (child) node (a parent base), we link it to our
tree, then process the new node.
- if it returns nothing, the node is done, free it. We go back to
parent node and resume whatever it's doing.
and do it until we have no nodes to process.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.8.4
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.6.6
thin-pack: try harder to use preferred base objects as base
When creating a pack using objects that reside in existing packs, we try
to avoid recomputing futile delta between an object (trg) and a candidate
for its base object (src) if they are stored in the same packfile, and trg
is not recorded as a delta already. This heuristics makes sense because it
is likely that we tried to express trg as a delta based on src but it did
not produce a good delta when we created the existing pack.
As the pack heuristics prefer producing delta to remove data, and Linus's
law dictates that the size of a file grows over time, we tend to record
the newest version of the file as inflated, and older ones as delta
against it.
When creating a thin-pack to transfer recent history, it is likely that we
will try to send an object that is recorded in full, as it is newer. But
the heuristics to avoid recomputing futile delta effectively forbids us
from attempting to express such an object as a delta based on another
object. Sending an object in full is often more expensive than sending a
suboptimal delta based on other objects, and it is even more so if we
could use an object we know the receiving end already has (i.e. preferred
base object) as the delta base.
Tweak the recomputation avoidance logic, so that we do not punt on
computing delta against a preferred base object.
The effect of this change can be seen on two simulated upload-pack
workloads. The first is based on 44 reflog entries from my git.git
origin/master reflog, and represents the packs that kernel.org sent me git
updates for the past month or two. The second workload represents much
larger fetches, going from git's v1.0.0 tag to v1.1.0, then v1.1.0 to
v1.2.0, and so on.
The table below shows the average generated pack size and the average CPU
time consumed for each dataset, both before and after the patch:
dataset
| reflog | tags
---------------------------------
before | 53358 | 2750977
size after | 32398 | 2668479
change | -39% | -3%
---------------------------------
before | 0.18 | 1.12
CPU after | 0.18 | 1.15
change | +0% | +3%
This patch makes a much bigger difference for packs with a shorter slice
of history (since its effect is seen at the boundaries of the pack) though
it has some benefit even for larger packs.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expose the cherry-picking machinery through a public
sequencer_pick_revisions() (renamed from pick_revisions() in
builtin/revert.c), so that cherry-picking and reverting are special
cases of a general sequencer operation. The cherry-pick builtin is
now a thin wrapper that does command-line argument parsing before
calling into sequencer_pick_revisions(). In the future, we can write
a new "foo" builtin that calls into the sequencer like:
memset(&opts, 0, sizeof(opts));
opts.action = REPLAY_FOO;
opts.revisions = xmalloc(sizeof(*opts.revs));
parse_args_populate_opts(argc, argv, &opts);
init_revisions(opts.revs);
sequencer_pick_revisions(&opts);
This patch does not intend to make any functional changes. Check
with:
$ git blame -s -C HEAD^..HEAD -- sequencer.c | grep -C3 '^[^^]'
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
REVERT and CHERRY_PICK and are unsuitable names for an enumerator in a
public interface, because they are generic enough to be likely to
clash with identifiers with other meanings. Rename to REPLAY_REVERT
and REPLAY_PICK as preparation for exposing them.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reason why the trailing slash is needed is obvious. refs/stash and
HEAD are not namespace, but complete refs. Do full string compare on them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/ref-api-less-extra-refs:
write_head_info(): handle "extra refs" locally
show_ref(): remove unused "flag" and "cb_data" arguments
receive-pack: move more work into write_head_info()
Currently, git push --quiet produces some non-error output, e.g.:
$ git push --quiet
Unpacking objects: 100% (3/3), done.
This fixes a bug reported for the fedora git package:
https://bugzilla.redhat.com/show_bug.cgi?id=725593
Reported-by: Jesse Keating <jkeating@redhat.com>
Cc: Todd Zullinger <tmz@pobox.com>
Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack)
introduced the --quiet option to receive-pack and made send-pack
pass that option. Older versions of receive-pack do not recognize
the option, however, and terminate immediately. The commit was
therefore reverted.
This change instead adds a 'quiet' capability to receive-pack,
which is a backwards compatible.
In addition, this fixes push --quiet via http: A verbosity of 0
means quiet for remote helpers.
Reported-by: Tobias Ulmer <tobiasu@tmux.org>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have been carefully choosing feature names used in the protocol
extensions so that the vocabulary does not contain a word that is a
substring of another word, so it is not a real problem, but we have
recently added "quiet" feature word, which would mean we cannot later
add some other word with "quiet" (e.g. "quiet-push"), which is awkward.
Let's make sure that we can eventually be able to do so by teaching the
clients and servers that feature words consist of non whitespace
letters. This parser also allows us to later add features with parameters
e.g. "feature=1.5" (parameter values need to be quoted for whitespaces,
but we will worry about the detauls when we do introduce them).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --single-branch is given, only one branch, either HEAD or one
specified by --branch, will be fetched. Also only tags that point to
the downloaded history are fetched.
This helps most in shallow clones, where it can reduce the download to
minimum and that is why it is enabled by default when --depth is given.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/show-sig:
log --show-signature: reword the common two-head merge case
log-tree: show mergetag in log --show-signature output
log-tree.c: small refactor in show_signature()
commit --amend -S: strip existing gpgsig headers
verify_signed_buffer: fix stale comment
gpg-interface: allow use of a custom GPG binary
pretty: %G[?GS] placeholders
test "commit -S" and "log --show-signature"
log: --show-signature
commit: teach --gpg-sign option
Conflicts:
builtin/commit-tree.c
builtin/commit.c
builtin/merge.c
notes-cache.c
pretty.c
The old code basically did:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
add_extra_ref(".have", sha1)
for each ref (including real refs and extra refs):
show_ref(refname, sha1)
But there is no need to stuff the alternate refs in extra_refs; we can
call show_ref() directly when iterating over the array, then handle
real refs separately. So change the code to:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
show_ref(".have", sha1)
for each ref (this now only includes real refs):
show_ref(refname, sha1)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function is not used as a callback, so it doesn't need these
arguments. Also change its return type to void.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move some more code from the calling site into write_head_info(), and
inline add_alternate_refs() there. (Some more simplification is
coming, and it is easier if all this code is in the same place.)
Move some helper functions to avoid the need for forward declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Any existing commit signature was made against the contents of the old
commit, including its committer date that is about to change, and will
become invalid by amending it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They both use the extended headers in commit objects, and the former has
necessary infrastructure to show them that is useful to view the result of
the latter.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The FETCH_HEAD refname is supposed to refer to the ref that was fetched
and should be merged. However all fetched refs are written to
.git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply
takes the first ref as the FETCH_HEAD, which is often the wrong one,
when other branches were also fetched.
The solution is to write the for-merge ref(s) to FETCH_HEAD first.
Then, unless --append is used, the FETCH_HEAD refname behaves as intended.
If the user uses --append, they presumably are doing so in order to
preserve the old FETCH_HEAD.
While we are at it, update an old example in the read-tree documentation
that implied that each entry in FETCH_HEAD only has the object name, which
is not true for quite a while.
[jc: adjusted tests]
Signed-off-by: Joey Hess <joey@kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/checkout-m-twoway:
t/t2023-checkout-m.sh: fix use of test_must_fail
checkout_merged(): squelch false warning from some gcc
Test 'checkout -m -- path'
checkout -m: no need to insist on having all 3 stages
* jn/maint-sequencer-fixes:
revert: stop creating and removing sequencer-old directory
Revert "reset: Make reset remove the sequencer state"
revert: do not remove state until sequence is finished
revert: allow single-pick in the middle of cherry-pick sequence
revert: pass around rev-list args in already-parsed form
revert: allow cherry-pick --continue to commit before resuming
revert: give --continue handling its own function
* jk/maint-mv:
mv: be quiet about overwriting
mv: improve overwrite warning
mv: make non-directory destination error more clear
mv: honor --verbose flag
docs: mention "-k" for both forms of "git mv"
* jk/fetch-no-tail-match-refs:
connect.c: drop path_match function
fetch-pack: match refs exactly
t5500: give fully-qualified refs to fetch-pack
drop "match" parameter from get_remote_heads
* ab/sun-studio-portability:
Appease Sun Studio by renaming "tmpfile"
Fix a bitwise negation assignment issue spotted by Sun Studio
Fix an enum assignment issue spotted by Sun Studio
* rs/diff-tree-combined-clean-up:
submodule: use diff_tree_combined_merge() instead of diff_tree_combined()
pass struct commit to diff_tree_combined_merge()
use struct sha1_array in diff_tree_combined()
* tr/grep-threading:
grep: disable threading in non-worktree case
grep: enable threading with -p and -W using lazy attribute lookup
grep: load funcname patterns for -W
* nd/war-on-nul-in-commit:
commit_tree(): refuse commit messages that contain NULs
Convert commit_tree() to take strbuf as message
merge: abort if fails to commit
Conflicts:
builtin/commit.c
commit.c
commit.h
Advice messages are by definition meant for human end-users, and prime
candidates for i18n/l10n. They tend to also be more verbose to be helpful,
and need to be longer than just one line.
Although we do not have parameterized multi-line advice messages yet, once
we do, we cannot emit such a message like this:
advise(_("Please rename %s to something else"), gostak);
advise(_("so that we can avoid distimming %s unnecessarily."), doshes);
because some translations may need to have the replacement of 'gostak' on
the second line (or 'doshes' on the first line). Some languages may even
need to use three lines in order to fit the same message within a
reasonable width.
Instead, it has to be a single advise() construct, like this:
advise(_("Please rename %s to something else\n"
"so that we can avoid distimming %s unnecessarily."),
gostak, doshes);
Update the advise() function and its existing callers to
- take a format string that can be multi-line and translatable as a
whole;
- use the string and the parameters to form a localized message; and
- show each line in the result with the localization of the "hint: ".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is to give an alternate <name> instead of "origin" to the remote
we are cloning from.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"abbrev" and "commit_format" in struct rev_info get initialized in
init_revisions - no need to reinit in cmd_log_init_defaults.
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Solaris the system headers define the "tmpfile" name, which'll
cause Git compiled with Sun Studio 12 Update 1 to whine about us
redefining the name:
"pack-write.c", line 76: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC)
"sha1_file.c", line 2455: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC)
"fast-import.c", line 858: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC)
"builtin/index-pack.c", line 175: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC)
Just renaming the "tmpfile" variable to "tmp_file" in the relevant
places is the easiest way to fix this.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In builtin/fast-export.c we'd assign to variables of the
tag_of_filtered_mode enum type with constants defined for the
signed_tag_mode enum.
We'd get the intended value since both the value we were assigning
with and the one we actually wanted had the same positional within
their respective enums, but doing it this way makes no sense.
This issue was spotted by Sun Studio 12 Update 1:
"builtin/fast-export.c", line 54: warning: enum type mismatch: op "=" (E_ENUM_TYPE_MISMATCH_OP)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Solaris systems we'd warn about an implicit cast of mode_t when we
printed things out with the %d format. We'd get this warning under GCC
4.6.0 with Solaris headers:
builtin/init-db.c: In function ‘separate_git_dir’:
builtin/init-db.c:354:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘mode_t’ [-Wformat]
We've been doing this ever since v1.7.4.1-296-gb57fb80. Just work
around this by adding an explicit cast.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The earlier ed7a42a (commit: teach --amend to carry forward extra headers,
2011-11-08) broke "git merge/pull; edit to fix conflict; git commit"
workflow by forgetting that commit_tree_extended() takes the whole extra
header list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/checkout-m-twoway:
checkout_merged(): squelch false warning from some gcc
Test 'checkout -m -- path'
checkout -m: no need to insist on having all 3 stages
* jk/fetch-no-tail-match-refs:
connect.c: drop path_match function
fetch-pack: match refs exactly
t5500: give fully-qualified refs to fetch-pack
drop "match" parameter from get_remote_heads
* nd/resolve-ref:
Rename resolve_ref() to resolve_ref_unsafe()
Convert resolve_ref+xstrdup to new resolve_refdup function
revert: convert resolve_ref() to read_ref_full()
* jn/maint-sequencer-fixes:
revert: stop creating and removing sequencer-old directory
Revert "reset: Make reset remove the sequencer state"
revert: do not remove state until sequence is finished
revert: allow single-pick in the middle of cherry-pick sequence
revert: pass around rev-list args in already-parsed form
revert: allow cherry-pick --continue to commit before resuming
revert: give --continue handling its own function
* jk/maint-mv:
mv: be quiet about overwriting
mv: improve overwrite warning
mv: make non-directory destination error more clear
mv: honor --verbose flag
docs: mention "-k" for both forms of "git mv"
* tr/cache-tree:
reset: update cache-tree data when appropriate
commit: write cache-tree data when writing index anyway
Refactor cache_tree_update idiom from commit
Test the current state of the cache-tree optimization
Add test-scrap-cache-tree
Maintaining an array of hashes is easier using sha1_array than
open-coding it. This patch also fixes a leak of the SHA1 array
in diff_tree_combined_merge().
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/stream-to-pack:
bulk-checkin: replace fast-import based implementation
csum-file: introduce sha1file_checkpoint
finish_tmp_packfile(): a helper function
create_tmp_packfile(): a helper function
write_pack_header(): a helper function
Conflicts:
pack.h
Measurements by various people have shown that grepping in parallel is
not beneficial when the object store is involved. For example, with a
simple regex:
Threads | --cached case | worktree case
----------------------------------------------------------------
8 (default) | 2.88u 0.21s 0:02.94real | 0.19u 0.32s 0:00.16real
4 | 2.89u 0.29s 0:02.99real | 0.16u 0.34s 0:00.17real
2 | 2.83u 0.36s 0:02.87real | 0.18u 0.32s 0:00.26real
NO_PTHREADS | 2.16u 0.08s 0:02.25real | 0.12u 0.17s 0:00.31real
This happens because all the threads contend on read_sha1_mutex almost
all of the time. A more complex regex allows the threads to do more
work in parallel, but as Jeff King found out, the "super boost" (much
higher clock when only one core is active) feature of recent CPUs
still causes the unthreaded case to win by a large margin.
So until the pack machinery allows unthreaded access, we disable
grep's threading in all but the worktree case.
Helped-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lazily load the userdiff attributes in match_funcname(). Use a
separate mutex around this loading to protect the (not thread-safe)
attributes machinery. This lets us re-enable threading with -p and
-W while reducing the overhead caused by looking up attributes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
format_todo() calls get_message(), but uses only the subject line of
the commit message. As a minor optimization, save work and
unnecessary memory allocations by using find_commit_subject() instead.
Also, remove the unnecessary check on cur->item->buffer: the
lookup_commit_reference() call in parse_insn_line() has already made
sure of this.
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tolerate extra spaces and tabs as part of the the field separator in
'.git/sequencer/todo', for people with fat fingers.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the instruction sheet format subtly so that the subject of the
commit message that follows the object name is optional. As a result,
an instruction sheet like this is now perfectly valid:
pick 35b0426
pick fbd5bbcbc2e
pick 7362160f
While at it, also fix a bug introduced by 5a5d80f4 (revert: Introduce
--continue to continue the operation, 2011-08-04) that failed to read
lines that are too long to fit on the commit-id-shaped buffer we
currently use; eliminate the need for the buffer altogether. In
addition to literal SHA-1 hexes, you can now safely use expressions
like the following in the instruction sheet:
featurebranch~4
rr/revert-cherry-pick-continue^2~12@{12 days ago}
[jc: simplify parsing]
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Memory allocated to the fields of msg by get_message() isn't freed.
This is potentially a big leak, because fresh memory is allocated to
store the commit message for each commit. Fix this using
free_message().
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There wan't a way for commit_tree() to notice if the message the caller
prepared contained a NUL byte, as it did not take the length of the
message as a parameter. Use a pointer to a strbuf instead, so that we can
either choose to allow low-level plumbing commands to make commits that
contain NUL byte in its message, or forbid NUL everywhere by adding the
check in commit_tree(), in later patches.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gcc 4.6.2 (there may be others) does not realize that the variable "mode"
can never be used uninitialized in this function and issues a false warning
under -Wuninitialized option.
Squelch it with an unnecessary initialization; it is not like a single
assignment matters to the performance in this codepath that writes out
to the filesystem with checkout_entry() anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/misc-cleanups:
unpack_object_header_buffer(): clear the size field upon error
tree_entry_interesting: make use of local pointer "item"
tree_entry_interesting(): give meaningful names to return values
read_directory_recursive: reduce one indentation level
get_tree_entry(): do not call find_tree_entry() on an empty tree
tree-walk.c: do not leak internal structure in tree_entry_len()
* maint-1.7.7:
Git 1.7.7.5
Git 1.7.6.5
blame: don't overflow time buffer
fetch: create status table using strbuf
checkout,merge: loosen overwriting untracked file check based on info/exclude
cast variable in call to free() in builtin/diff.c and submodule.c
apply: get rid of useless x < 0 comparison on a size_t type
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
builtin/fetch.c
When showing the raw timestamp, we format the numeric
seconds-since-epoch into a buffer, followed by the timezone
string. This string has come straight from the commit
object. A well-formed object should have a timezone string
of only a few bytes, but we could be operating on data
pushed by a malicious user.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are determining the list of refs to fetch via
fetch-pack, we have two sets of refs to compare: those on
the remote side, and a "match" list of things we want to
fetch. We iterate through the remote refs alphabetically,
seeing if each one is wanted by the "match" list.
Since def88e9 (Commit first cut at "git-fetch-pack",
2005-07-04), we have used the "path_match" function to do a
suffix match, where a remote ref is considered wanted if
any of the "match" elements is a suffix of the remote
refname.
This enables callers of fetch-pack to specify unqualified
refs and have them matched up with remote refs (e.g., ask
for "A" and get remote's "refs/heads/A"). However, if you
provide a fully qualified ref, then there are corner cases
where we provide the wrong answer. For example, given a
remote with two refs:
refs/foo/refs/heads/master
refs/heads/master
asking for "refs/heads/master" will first match
"refs/foo/refs/heads/master" by the suffix rule, and we will
erroneously fetch it instead of refs/heads/master.
As it turns out, all callers of fetch_pack do provide
fully-qualified refs for the match list. There are two ways
fetch_pack can get match lists:
1. Through the transport code (i.e., via git-fetch)
2. On the command-line of git-fetch-pack
In the first case, we will always be providing the names of
fully-qualified refs from "struct ref" objects. We will have
pre-matched those ref objects already (since we have to
handle more advanced matching, like wildcard refspecs), and
are just providing a list of the refs whose objects we need.
In the second case, users could in theory be providing
non-qualified refs on the command-line. However, the
fetch-pack documentation claims that refs should be fully
qualified (and has always done so since it was written in
2005).
Let's change this path_match call to simply check for string
equality, matching what the callers of fetch_pack are
expecting.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The get_remote_heads function reads the list of remote refs
during git protocol session. It dates all the way back to
def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04).
At that time, the idea was to come up with a list of refs we
were interested in, and then filter the list as we got it
from the remote side.
Later, 1baaae5 (Make maximal use of the remote refs,
2005-10-28) stopped filtering at the get_remote_heads layer,
letting us use the non-matching refs to find common history.
As a result, all callers now simply pass an empty match
list (and any future callers will want to do the same). So
let's drop these now-useless parameters.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref() may return a pointer to a shared buffer and can be
overwritten by the next resolve_ref() calls. Callers need to
pay attention, not to keep the pointer when the next call happens.
Rename with "_unsafe" suffix to warn developers (or reviewers) before
introducing new call sites.
This patch is generated using the following command
git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g'
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tell the user what this command is intended for, and expand the
description of what it does.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a user asks us to force a mv and overwrite the
destination, we print a warning. However, since a typical
use would be:
$ git mv one two
fatal: destination exists, source=one, destination=two
$ git mv -f one two
warning: overwriting 'two'
this warning is just noise. We already know we're
overwriting; that's why we gave -f!
This patch silences the warning unless "--verbose" is given.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we try to "git mv" over an existing file, the error
message is fairly informative:
$ git mv one two
fatal: destination exists, source=one, destination=two
When the user forces the overwrite, we give a warning:
$ git mv -f one two
warning: destination exists; will overwrite!
This is less informative, but still sufficient in the simple
rename case, as there is only one rename happening.
But when moving files from one directory to another, it
becomes useless:
$ mkdir three
$ touch one two three/one
$ git add .
$ git mv one two three
fatal: destination exists, source=one, destination=three/one
$ git mv -f one two three
warning: destination exists; will overwrite!
The first message is helpful, but the second one gives us no
clue about what was overwritten. Let's mention the name of
the destination file:
$ git mv -f one two three
warning: overwriting 'three/one'
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that "git reset" no longer implicitly removes .git/sequencer that
the operator may or may not have wanted to keep, the logic to write a
backup copy of .git/sequencer and remove it when stale is not needed
any more. Simplify the sequencer API and repository layout by
dropping it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes
the sequencer state just before applying the final patch. In the
single-pick case, that was a good thing, since --abort and --continue
work fine without access to such state and removing it provides a
signal that git should not complain about the need to clobber it ("a
cherry-pick or revert is already in progress") in sequences like the
following:
git cherry-pick foo
git read-tree -m -u HEAD; # forget that; let's try a different one
git cherry-pick bar
After the recent patch "allow single-pick in the middle of cherry-pick
sequence" we don't need that hack any more. In the new regime, a
traditional "git cherry-pick <commit>" command never looks at
.git/sequencer, so we do not need to cripple "git cherry-pick
<commit>..<commit>" for it any more.
So now you can run "git cherry-pick --abort" near the end of a
multi-pick sequence and it will abort the entire sequence, instead of
misbehaving and aborting just the final commit.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After messing up a difficult conflict resolution in the middle of a
cherry-pick sequence, it can be useful to be able to
git checkout HEAD . && git cherry-pick that-one-commit
to restart the conflict resolution. The current code however errors out
saying that another cherry-pick is already in progress.
Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 7e2bfd3f (revert: allow cherry-picking more than one commit,
2010-07-02), the pick/revert machinery has kept track of the set of
commits to be cherry-picked or reverted using commit_argc and
commit_argv variables, storing the corresponding command-line
parameters.
Future callers as other commands are built in (am, rebase, sequencer)
may find it easier to pass rev-list options to this machinery in
already-parsed form. Teach cmd_cherry_pick and cmd_revert to parse
the rev-list arguments in advance and pass the commit set to
pick_revisions() as a rev_info structure.
Original patch by Jonathan, tweaks and test from Ram.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git cherry-pick ..bar" encounters conflicts, permit the operator
to use cherry-pick --continue after resolving them as a shortcut for
"git commit && git cherry-pick --continue" to record the resolution
and carry on with the rest of the sequence.
This improves the analogy with "git rebase" (in olden days --continue
was the way to preserve authorship when a rebase encountered
conflicts) and fits well with a general UI goal of making "git cmd
--continue" save humans the trouble of deciding what to do next.
Example: after encountering a conflict from running "git cherry-pick
foo bar baz":
CONFLICT (content): Merge conflict in main.c
error: could not apply f78a8d98c... bar!
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
We edit main.c to resolve the conflict, mark it acceptable with "git
add main.c", and can run "cherry-pick --continue" to resume the
sequence.
$ git cherry-pick --continue
[editor opens to confirm commit message]
[master 78c8a8c98] bar!
1 files changed, 1 insertions(+), 1 deletions(-)
[master 87ca8798c] baz!
1 files changed, 1 insertions(+), 1 deletions(-)
This is done for both codepaths to pick multiple commits and a single
commit.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes pick_revisions() a little shorter and easier to read
straight through.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you try to "git mv" multiple files onto another
non-directory file, you confusingly get the "usage" message:
$ touch one two three
$ git add .
$ git mv one two three
usage: git mv [options] <source>... <destination>
[...]
From the user's perspective, that makes no sense. They just
gave parameters that exactly match that usage!
This behavior dates back to the original C version of "git
mv", which had a usage message like:
usage: git mv (<source> <destination> | <source>... <destination>)
This was slightly less confusing, because it at least
mentions that there are two ways to invoke (but it still
isn't clear why what the user provided doesn't work).
Instead, let's show an error message like:
$ git mv one two three
fatal: destination 'three' is not a directory
We could leave the usage message in place, too, but it
doesn't actually help here. It contains no hints that there
are two forms, nor that multi-file form requires that the
endpoint be a directory. So it just becomes useless noise
that distracts from the real error.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code for a verbose flag has been here since "git mv" was
converted to C many years ago, but actually getting the "-v"
flag from the command line was accidentally lost in the
transition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the follow up of c689332 (Convert many resolve_ref() calls to
read_ref*() and ref_exists() - 2011-11-13). See the said commit for
rationale.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we fetch from a remote, we print a status table like:
From url
* [new branch] foo -> origin/foo
We create this table in a static buffer using sprintf. If
the remote refnames are long, they can overflow this buffer
and smash the stack.
Instead, let's use a strbuf to build the string.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/resolve-ref:
Copy resolve_ref() return value for longer use
Convert many resolve_ref() calls to read_ref*() and ref_exists()
Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
refs.c
* jc/pull-signed-tag:
commit-tree: teach -m/-F options to read logs from elsewhere
commit-tree: update the command line parsing
commit: teach --amend to carry forward extra headers
merge: force edit and no-ff mode when merging a tag object
commit: copy merged signed tags to headers of merge commit
merge: record tag objects without peeling in MERGE_HEAD
merge: make usage of commit->util more extensible
fmt-merge-msg: Add contents of merged tag in the merge message
fmt-merge-msg: package options into a structure
fmt-merge-msg: avoid early returns
refs DWIMmery: use the same rule for both "git fetch" and others
fetch: allow "git fetch $there v1.0" to fetch a tag
merge: notice local merging of tags and keep it unwrapped
fetch: do not store peeled tag object names in FETCH_HEAD
Split GPG interface into its own helper library
Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
* jc/request-pull-show-head-4:
request-pull: use the annotated tag contents
fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
environment.c: Fix an sparse "symbol not declared" warning
builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
fmt-merge-msg: use branch.$name.description
request-pull: use the branch description
request-pull: state what commit to expect
request-pull: modernize style
branch: teach --edit-description option
format-patch: use branch description in cover letter
branch: add read_branch_desc() helper function
Conflicts:
builtin/branch.c
Normally git tag strips tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.
--cleanup allows to select different cleanup modes for tag message.
It provides the same interface as --cleanup option in git-commit.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After making fixes to the contents to be committed, it is not unusual to
update the current commit without rewording the message. Idioms to tell
"commit --amend" that we do not need an editor have been:
$ EDITOR=: git commit --amend
$ git commit --amend -C HEAD
but that was only because a more natural "--no-edit" option in
$ git commit --amend --no-edit
was not honoured.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the case of --mixed and --hard, we throw away the old index and
rebuild everything from the tree argument (or HEAD). So we have an
opportunity here to fill in the cache-tree data, just as read-tree
did.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In prepare_index(), we refresh the index, and then write it to disk if
this changed the index data. After running hooks we re-read the index
and compute the root tree sha1 with the cache-tree machinery.
This gives us a mostly free opportunity to write up-to-date cache-tree
data: we can compute it in prepare_index() immediately before writing
the index to disk.
If we do this, we were going to write the index anyway, and the later
cache-tree update has no further work to do. If we don't do it, we
don't do any extra work, though we still don't have have cache-tree
data after the commit.
The only case that suffers badly is when the pre-commit hook changes
many trees in the index. I'm writing this off as highly unusual.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We'll need to safely create or update the cache-tree data of the_index
from other places. While at it, give it an argument that lets us
silence the messages produced by unmerged entries (which prevent it
from working).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The content level merge machinery ll_merge() is prepared to merge
correctly in "both sides added differently" case by using an empty blob as
if it were the common ancestor. "checkout -m" could do the same, but didn't
bother supporting it and instead insisted on having all three stages.
Reported-by: Pete Harlan
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref() may return a pointer to a static buffer. Callers that
use this value longer than a couple of statements should copy the
value to avoid some hidden resolve_ref() call that may change the
static buffer's value.
The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c
demonstrates this. The first call is in cmd_merge()
branch = resolve_ref("HEAD", head_sha1, 0, &flag);
Then deep in lookup_commit_or_die() a few lines after, resolve_ref()
may be called again and destroy "branch".
lookup_commit_or_die
lookup_commit_reference
lookup_commit_reference_gently
parse_object
lookup_replace_object
do_lookup_replace_object
prepare_replace_object
for_each_replace_ref
do_for_each_ref
get_loose_refs
get_ref_dir
get_ref_dir
resolve_ref
All call sites are checked and made sure that xstrdup() is called if
the value should be saved.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/fsck-progress:
fsck: print progress
fsck: avoid reading every object twice
verify_packfile(): check as many object as possible in a pack
fsck: return error code when verify_pack() goes wrong
* nd/misc-cleanups:
unpack_object_header_buffer(): clear the size field upon error
tree_entry_interesting: make use of local pointer "item"
tree_entry_interesting(): give meaningful names to return values
read_directory_recursive: reduce one indentation level
get_tree_entry(): do not call find_tree_entry() on an empty tree
tree-walk.c: do not leak internal structure in tree_entry_len()
The comment on top of stripspace() claims that the buffer
will no longer be NUL-terminated. However, this has not been
the case at least since the move to using strbuf in 2007.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git apply is passed something that is not a patch, it does not produce
an error message or exit with a non-zero status if it was not actually
"applying" the patch i.e. --check or --numstat etc were supplied on the
command line.
Fix this by producing an error when apply fails to find any hunks whatsoever
while parsing the patch.
This will cause some of the output formats (--numstat, --diffstat, etc) to
produce an error when they formerly would have reported zero changes and
exited successfully. That seems like the correct behavior though. Failure
to recognize the input as a patch should be an error.
Plus, add a test.
Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This extends the earlier approach to stream a large file directly from the
filesystem to its own packfile, and allows "git add" to send large files
directly into a single pack. Older code used to spawn fast-import, but the
new bulk-checkin API replaces it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When on master, "git checkout -B master <commit>" is a more natural way to
say "git reset --keep <commit>", which was originally invented for the
exact purpose of moving to the named commit while keeping the local changes
around.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Overwriting the current branch with a different commit is forbidden, as it
will make the status recorded in the index and the working tree out of
sync with respect to the HEAD. There however is no reason to forbid it if
the current branch is renamed to itself, which admittedly is something
only an insane user would do, but is handy for scripts.
Test script is by Conrad Irwin.
Reported-by: Soeren Sonnenburg <sonne@debian.org>
Reported-by: Josh Chia (谢任中)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ignored files usually are generated files (e.g. .o files) and can be
safely discarded. However sometimes users may have important files in
working directory, but still want a clean "git status", so they mark
them as ignored files. But in this case, these files should not be
overwritten without asking first.
Enable this use case with --no-overwrite-ignore, where git only sees
tracked and untracked files, no ignored files. Those who mix
discardable ignored files with important ones may have to sort it out
themselves.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back in 1127148 (Loosen "working file will be lost" check in
Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly
overwrite ignored files. Howver the code only took .gitignore files
into account.
Standard ignored files include all specified in .gitignore files in
working directory _and_ $GIT_DIR/info/exclude. This patch makes sure
ignored files in info/exclude can also be overwritten automatically in
the spirit of the original patch.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option --force should not put us in 'create branch' mode. The
fact that this option is only valid in 'create branch' mode is
already caught by the the next 'if' in which we assure that we
are in the correct mode.
Without this patch, "git branch -f" without any other argument ends
up calling create_branch without any branch name.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident. cherry-pick --abort is designed to
work in three steps:
1) find which commit to roll back to
2) call "git reset --merge <commit>" to move to that commit
3) remove the .git/sequencer directory
But the careless author forgot step 3 entirely. The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.
By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking. Remove
the (renamed) .git/sequencer directory as intended all along.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, it is not possible to rename or remove a directory that has
open files. 'revert --abort' renamed .git/sequencer when it still had
.git/sequencer/head open. Close the file as early as possible to allow
the rename operation on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the following warning.
CC builtin/revert.o
builtin/revert.c: In function ‘write_cherry_pick_head’:
builtin/revert.c:311: warning: format not a string literal and no format arguments
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the "git cherry-pick --reset" option, which has a different
preferred spelling nowadays ("--quit"). Luckily the old --reset name
was not around long enough for anyone to get used to it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running some ill-advised command like "git cherry-pick
HEAD..linux-next", the bewildered novice may want to return to more
familiar territory. Introduce a "git cherry-pick --abort" command
that rolls back the entire cherry-pick sequence and places the
repository back on solid ground.
Just like "git merge --abort", this internally uses "git reset
--merge", so local changes not involved in the conflict resolution are
preserved.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When conflicts are encountered while reverting a commit, it can be
handy to have the name of that commit easily available. For example,
to produce a copy of the patch to refer to while resolving conflicts:
$ git revert 2eceb2a8
error: could not revert 2eceb2a8... awesome, buggy feature
$ git show -R REVERT_HEAD >the-patch
$ edit $(git diff --name-only)
Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
for cases like this. This also makes it possible for scripts to
distinguish between a revert that encountered conflicts and other
sources of an unmerged index.
After successfully committing, resetting with "git reset", or moving
to another commit with "git checkout" or "git reset", the pseudoref is
no longer useful, so remove it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge,
2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when
in the middle of an existing conflicted cherry-pick in the following
sequence:
1. git cherry-pick HEAD..origin
2. resolve conflicts
3. git cherry-pick HEAD..origin (instead of "git cherry-pick
--continue", by mistake)
Good. However, the error message on attempting step 3 is more
convoluted than necessary:
$ git cherry-pick HEAD..origin
error: .git/sequencer already exists.
error: A cherry-pick or revert is in progress.
hint: Use --continue to continue the operation
hint: or --quit to forget about it
fatal: cherry-pick failed
Clarify by removing the redundant first "error:" message, simplifying
the advice, and using lower-case and no full stops to be consistent
with other commands that prefix their messages with "error:", so it
becomes
error: a cherry-pick or revert is already in progress
hint: try "git cherry-pick (--continue | --quit)"
fatal: cherry-pick failed
The "fatal: cherry-pick failed" line seems unnecessary, too, but
that can be fixed some other day.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Deal completely with "cherry-pick --quit" and --continue at the
beginning of pick_revisions(), leaving the rest of the function for
the more interesting "git cherry-pick <commits>" case.
No functional change intended. The impact is just to unindent the
code a little.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option to "git cherry-pick" and "git revert" to discard the
sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
--reset to remove sequencer state, 2011-08-04) has a confusing name.
Change it now, while we still have the time.
The new name for "cherry-pick, please get out of my way, since I've
long forgotten about the sequence of commits I was cherry-picking when
you wrote that old .git/sequencer directory" is --quit. Mnemonic:
this is analagous to quiting a program the user is no longer using ---
we just want to get out of the multiple-command cherry-pick procedure
and not to reset HEAD or rewind any other old state.
The "--reset" option is kept as a synonym to minimize the impact. We
might consider dropping it for simplicity in a separate patch, though.
Adjust documentation and tests to use the newly preferred name (--quit)
instead of --reset. While at it, let's clarify the short descriptions
of these operations in "-h" output.
Before:
--reset forget the current operation
--continue continue the current operation
After:
--quit end revert or cherry-pick sequence
--continue resume revert or cherry-pick sequence
Noticed-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The POSIX-function fork is not supported on Windows. Use our
start_command API instead, respawning ourselves in a special
"writer" mode to follow the alternate code path.
Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
now works.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git merge' can be called without any arguments if merge.defaultToUpstream
is set. However, when merge.defaultToUpstream is not set, the user will be
presented the usage information as if he entered a command with a wrong
syntaxis. Ironically, the usage information confirms that no arguments are
mandatory.
This adds a proper error message telling the user why the command failed. As
a side-effect this can help the user in discovering the possibility to merge
with the upstream branch by setting merge.defaultToUpstream.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because git_path() calls vsnprintf(), code like
fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
die_errno(_("Could not write to '%s'"), git_path("SQUASH_MSG"));
can end up printing an error indicator from vsnprintf() instead of
open() by mistake. Store the path we are trying to write to in a
temporary variable and pass _that_ to die_errno(), so the messages
written by git cherry-pick/revert and git merge can avoid this source
of confusion.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --reuse-delta is in effect (which is the default), and an existing
pack in the repository has the same object registered twice (e.g. one copy
in a non-delta format and the other copy in a delta against some other
object), an attempt to repack the repository can result in a cyclic delta
dependency, causing write_one() function to infinitely recurse into
itself.
Detect such a case and break the loopy dependency by writing out an object
that is involved in such a loop in the non-delta format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When receive-pack & fetch-pack are run and store the pack obtained over
the wire to a local repository, they internally run the index-pack command
with the --strict option. Make sure that we reject incoming packfile that
records objects twice to avoid spreading such a damage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some of the fatal messages printed by revert and cherry-pick look ugly
like the following:
fatal: Could not open .git/sequencer/todo.: No such file or directory
The culprit here is that these callers of the die_errno() function did not
take it into account that the message string they give to it is followed
by ": <strerror>", hence the message typically should not end with the
full-stop.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref() may return a pointer to a static buffer, which is not
safe for long-term use because if another resolve_ref() call happens,
the buffer may be changed. Many call sites though do not care about
this buffer. They simply check if the return value is NULL or not.
Convert all these call sites to new wrappers to reduce resolve_ref()
calls from 57 to 34. If we change resolve_ref() prototype later on
to avoid passing static buffer out, this helps reduce changes.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have kept the original "git commit-tree <tree> -p <parent> ..." syntax
forever, but "git commit-tree -p <parent> -p <parent> ... <tree>" would be
more intuitive way to spell it. Dashed flags along with their arguments
come first and then the "thing" argument after the flags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running "git pull $there for-linus" to merge a signed tag, the
integrator may need to amend the resulting merge commit to fix typoes
in it. Teach --amend option to read the existing extra headers, and
carry them forward.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we allow pulling a tag from the remote site to validate the
authenticity, we should give the user the final chance to verify and edit
the merge message. The integrator is expected to leave a meaningful merge
commit log in the history. Disallow fast-forwarding in such a case to
ensure that a merge commit is always recorded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now MERGE_HEAD records the tag objects without peeling, we could record
the result of manual conflict resolution via "git commit" without losing
the tag information. Introduce a new "mergetag" multi-line header field to
the commit object, and use it to store the entire contents of each signed
tag merged.
A commit header that has a multi-line payload begins with the header tag
(e.g. "mergetag" in this case), SP, the first line of payload, LF, and all
the remaining lines have a SP inserted at the beginning.
In hindsight, it would have been better to make "merge --continue" as the
way to continue from such an interrupted merge, not "commit", but this is
a backward compatibility baggage we would need to carry around for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dm/pack-objects-update:
pack-objects: don't traverse objects unnecessarily
pack-objects: rewrite add_descendants_to_write_order() iteratively
pack-objects: use unsigned int for counter and offset values
pack-objects: mark add_to_write_order() as inline
Otherwise, "git commit" wouldn't have a way to tell that we were in the
middle of merging an annotated or signed tag, not a plain commit, after
"git merge" stops to ask the user to resolve conflicts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The merge-recursive code uses the commit->util field directly to annotate
the commit objects given from the command line, i.e. the remote heads to
be merged, with a single string to be used to describe it in its trace
messages and conflict markers.
Correct this short-signtedness by redefining the field to be a pointer to
a structure "struct merge_remote_desc" that later enhancements can add
more information. Store the original objects we were told to merge in a
field "obj" in this struct, so that we can recover the tag we were told to
merge.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a contributor asks the integrator to merge her history, a signed tag
can be a good vehicle to communicate the authenticity of the request while
conveying other information such as the purpose of the topic.
E.g. a signed tag "for-linus" can be created, and the integrator can run:
$ git pull git://example.com/work.git/ for-linus
This would allow the integrator to run "git verify-tag FETCH_HEAD" to
validate the signed tag.
Update fmt-merge-msg so that it pre-fills the merge message template with
the body (but not signature) of the tag object to help the integrator write
a better merge message, in the same spirit as the existing merge.log summary
lines.
The message that comes from GPG signature validation is also included in
the merge message template to help the integrator verify it, but they are
prefixed with "#" to make them comments.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
prune already shows progress meter while pruning. The marking part may
take a few seconds or more, depending on repository size. Show
progress meter during this time too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2564aa4 started to initialize buf.alloc, but that should actually be one
more byte than the string length due to the trailing \0. Also, do not
modify buf.alloc out of the strbuf code. Use the existing strbuf_attach
instead.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In various places in the codepath, the program tries to return early
assuming there is no more work needed. That is generally untrue when
over time new features are added.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also updates the autogenerated merge title message from "merge commit X"
to "merge tag X", and its effect can be seen in the changes to the test suite.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bad copy-paste.
Otherwise "git remote set-branches" without necessary argument
will result in an error message and help for set-url subcommand.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Progress meter is not printed when --verbose is given because
--verbose prints a lot, there's no need for "alive" indicator.
Progress meter may provide "% complete" information but it would
be lost anyway in the flood of text.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During verify_pack() all objects are read for SHA-1 check. Then
fsck_sha1() is called on every object, which read the object again
(fsck_sha1 -> parse_object -> read_sha1_file).
Avoid reading an object twice, do fsck_sha1 while we have an object
uncompressed data in verify_pack.
On git.git, with this patch I got:
$ /usr/bin/time ./git fsck >/dev/null
98.97user 0.90system 1:40.01elapsed 99%CPU (0avgtext+0avgdata 616624maxresident)k
0inputs+0outputs (0major+194186minor)pagefaults 0swaps
Without it:
$ /usr/bin/time ./git fsck >/dev/null
231.23user 2.35system 3:53.82elapsed 99%CPU (0avgtext+0avgdata 636688maxresident)k
0inputs+0outputs (0major+461629minor)pagefaults 0swaps
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both of these free() calls are freeing a "const unsigned char (*)[20]"
type while free() expects a "void *". This results in the following
warning under clang 2.9:
builtin/diff.c:185:7: warning: passing 'const unsigned char (*)[20]' to parameter of type 'void *' discards qualifiers
free(parent);
^~~~~~
submodule.c:394:7: warning: passing 'const unsigned char (*)[20]' to parameter of type 'void *' discards qualifiers
free(parents);
^~~~~~~
This free()-ing without a cast was added by Jim Meyering to
builtin/diff.c in v1.7.6-rc3~4 and later by Fredrik Gustafsson in
submodule.c in v1.7.7-rc1~25^2.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the C standard size_t is always unsigned, therefore the
comparison "n1 < 0 || n2 < 0" when n1 and n2 are size_t will always be
false.
This was raised by clang 2.9 which throws this warning when compiling
apply.c:
builtin/apply.c:253:9: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (n1 < 0 || n2 < 0)
~~ ^ ~
builtin/apply.c:253:19: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (n1 < 0 || n2 < 0)
~~ ^ ~
This check was originally added in v1.6.5-rc0~53^2 by Giuseppe Bilotta
while adding an option to git-apply to ignore whitespace differences.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We do not want to record tags as parents of a merge when the user does
"git pull $there tag v1.0" to merge tagged commit, but that is not a good
enough excuse to peel the tag down to commit when storing in FETCH_HEAD.
The caller of underlying "git fetch $there tag v1.0" may have other uses
of information contained in v1.0 tag in mind.
[jc: the test adjustment is to update for the new expectation]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This mostly moves existing code from builtin/tag.c (for signing)
and builtin/verify-tag.c (for verifying) to a new gpg-interface.c
file to provide a more generic library interface.
- sign_buffer() takes a payload strbuf, a signature strbuf, and a signing
key, runs "gpg" to produce a detached signature for the payload, and
appends it to the signature strbuf. The contents of a signed tag that
concatenates the payload and the detached signature can be produced by
giving the same strbuf as payload and signature strbuf.
- verify_signed_buffer() takes a payload and a detached signature as
<ptr, len> pairs, and runs "gpg --verify" to see if the payload matches
the signature. It can optionally capture the output from GPG to allow
the callers to pretty-print it in a way more suitable for their
contexts.
"verify-tag" (aka "tag -v") used to save the whole tag contents as if it
is a detached signature, and fed gpg the payload part of the tag. It
relied on gpg to fail when the given tag is not signed but just is
annotated. The updated run_gpg_verify() function detects the lack of
detached signature in the input, and errors out without bothering "gpg".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing to delete a ref, it uses 0{40} as an object name to signal
that the request is a deletion. We shouldn't trigger "deletion of a
corrupt ref" warning in such a case, which was designed to notice that a
ref points at an object that is truly missing from the repository.
Reported-by: Stefan Näwe
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify the option parsing heuristic to handle all -m (rename) cases,
including the no-arg case.
Previously, this "fell through" to the (argc <= 2) case and caused
segfault.
Reported-by: Stefan Näwe <stefan.naewe@atlas-elektronik.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cn/fetch-prune:
fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
fetch: honor the user-provided refspecs when pruning refs
remote: separate out the remote_find_tracking logic into query_refspecs
t5510: add tests for fetch --prune
fetch: free all the additional refspecs
* ss/blame-textconv-fake-working-tree:
(squash) test for previous
blame.c: Properly initialize strbuf after calling, textconv_object()
Conflicts:
t/t8006-blame-textconv.sh
* ef/mingw-upload-archive:
mingw: poll.h is no longer in sys/
upload-archive: use start_command instead of fork
compat/win32/poll.c: upgrade from upstream
mingw: move poll out of sys-folder
* dm/pack-objects-update:
pack-objects: don't traverse objects unnecessarily
pack-objects: rewrite add_descendants_to_write_order() iteratively
pack-objects: use unsigned int for counter and offset values
pack-objects: mark add_to_write_order() as inline
The POSIX-function fork is not supported on Windows. Use our
start_command API instead.
As this is the last call-site that depends on the fork-stub in
compat/mingw.h, remove that as well.
Add an undocumented flag to git-archive that tells it that the
action originated from a remote, so features can be disabled.
Thanks to Jeff King for work on this part.
Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
now works.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Factor out a small logic out of the private write_pack_file() function
in builtin/pack-objects.c.
This changes the order of finishing multi-pack generation slightly. The
code used to
- adjust shared perm of temporary packfile
- rename temporary packfile to the final name
- update mtime of the packfile under the final name
- adjust shared perm of temporary idxfile
- rename temporary idxfile to the final name
but because the helper does not want to do the mtime thing, the updated
code does that step first and then all the rest.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a plain string where only the length is known, strbuf.alloc needs to
be initialized to the length. Otherwise strbuf.alloc is 0 and a later
call to strbuf_setlen() will fail.
This bug surfaced when calling git blame under Windows on a *.doc file.
The *.doc file is converted to plain text by antiword via the textconv
mechanism. However, the plain text returned by antiword contains DOS line
endings instead of Unix line endings which triggered the strbuf_setlen()
which previous to this patch failed.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/grep-mutex:
builtin/grep: simplify lock_and_read_sha1_file()
builtin/grep: make lock/unlock into static inline functions
git grep: be careful to use mutexes only when they are initialized
Without this patch,
$ git clone foo .
results in this:
Cloning into ....
done.
With it:
Cloning into '.'...
done.
Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is a basic code hygiene to avoid magic constants that are unnamed.
Besides, this helps extending the value later on for "interesting, but
cannot decide if the entry truely matches yet" (ie. prefix matches)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tree_entry_len() does not simply take two random arguments and return
a tree length. The two pointers must point to a tree item structure,
or struct name_entry. Passing random pointers will return incorrect
value.
Force callers to pass struct name_entry instead of two pointers (with
hope that they don't manually construct struct name_entry themselves)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cn/fetch-prune:
fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
fetch: honor the user-provided refspecs when pruning refs
remote: separate out the remote_find_tracking logic into query_refspecs
t5510: add tests for fetch --prune
fetch: free all the additional refspecs
Conflicts:
remote.c
* jk/argv-array:
run_hook: use argv_array API
checkout: use argv_array API
bisect: use argv_array API
quote: provide sq_dequote_to_argv_array
refactor argv_array into generic code
quote.h: fix bogus comment
add sha1_array API docs
* maint-1.7.6:
notes_merge_commit(): do not pass temporary buffer to other function
gitweb: Fix links to lines in blobs when javascript-actions are enabled
mergetool: no longer need to save standard input
mergetool: Use args as pathspec to unmerged files
t9159-*.sh: skip for mergeinfo test for svn <= 1.4
date.c: Support iso8601 timezone formats
remote: only update remote-tracking branch if updating refspec
remote rename: warn when refspec was not updated
remote: "rename o foo" should not rename ref "origin/bar"
remote: write correct fetch spec when renaming remote 'remote'
* mz/remote-rename:
remote: only update remote-tracking branch if updating refspec
remote rename: warn when refspec was not updated
remote: "rename o foo" should not rename ref "origin/bar"
remote: write correct fetch spec when renaming remote 'remote'
Rather nasty things happen when a mutex is not initialized but locked
nevertheless. Now, when we're not running in a threaded manner, the mutex
is not initialized, which is correct. But then we went and used the mutex
anyway, which -- at least on Windows -- leads to a hard crash (ordinarily
it would be called a segmentation fault, but in Windows speak it is an
access violation).
This problem was identified by our faithful tests when run in the msysGit
environment.
To avoid having to wrap the line due to the 80 column limit, we use
the name "WHEN_THREADED" instead of "IF_USE_THREADS" because it is one
character shorter. Which is all we need in this case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-pack-objects-compete-with-delete:
downgrade "packfile cannot be accessed" errors to warnings
pack-objects: protect against disappearing packs
* nd/maint-autofix-tag-in-head:
Accept tags in HEAD or MERGE_HEAD
merge: remove global variable head[]
merge: use return value of resolve_ref() to determine if HEAD is invalid
merge: keep stash[] a local variable
Conflicts:
builtin/merge.c
This brings back some of the performance lost in optimizing recency
order inside pack objects. We were doing extreme amounts of object
re-traversal: for the 2.14 million objects in the Linux kernel
repository, we were calling add_to_write_order() over 1.03 billion times
(a 0.2% hit rate, making 99.8% of of these calls extraneous).
Two optimizations take place here- we can start our objects array
iteration from a known point where we left off before we started trying
to find our tags, and we don't need to do the deep dives required by
add_family_to_write_order() if the object has already been marked as
filled.
These two optimizations bring some pretty spectacular results via `perf
stat`:
task-clock: 83373 ms --> 43800 ms (50% faster)
cycles: 221,633,461,676 --> 116,307,209,986 (47% fewer)
instructions: 149,299,179,939 --> 122,998,800,184 (18% fewer)
Helped-by: Ramsay Jones (format string fix in "die" message)
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/no-cherry-pick-head-after-punted:
cherry-pick: do not give irrelevant advice when cherry-pick punted
revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
This removes the need to call this function recursively, shinking the
code size slightly and netting a small performance increase.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is done in some of the new pack layout code introduced in commit
1b4bb16b9e. This more closely matches the nr_objects global that is
unsigned that these variables are based off of and bounded by.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is a whole 26 bytes when compiled on x86_64, but is
currently invoked over 1.037 billion times when running pack-objects on
the Linux kernel git repository. This is hitting the point where
micro-optimizations do make a difference, and inlining it only increases
the object file size by 38 bytes.
As reported by perf, this dropped task-clock from 84183 to 83373 ms, and
total cycles from 223.5 billion to 221.6 billion. Not astronomical, but
worth getting for adding one word.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --tags is specified, add that refspec to the list given to
prune_refs so it knows to treat it as a filter on what refs to
should consider for prunning. This way
git fetch --prune --tags origin
only prunes tags and doesn't delete the branch refs.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user gave us refspecs on the command line, we should use those
when deciding whether to prune a ref instead of relying on the
refspecs in the config.
Previously, running
git fetch --prune origin refs/heads/master:refs/remotes/origin/master
would delete every other ref under the origin namespace because we
were using the refspec to filter the available refs but using the
configured refspec to figure out if a ref had been deleted on the
remote. This is clearly the wrong thing to do.
Change prune_refs and get_stale_heads to simply accept a list of
references and a list of refspecs. The caller of either function needs
to decide what refspecs should be used to decide whether a ref is
stale.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These can happen if another process simultaneously prunes a
pack. But that is not usually an error condition, because a
properly-running prune should have repacked the object into
a new pack. So we will notice that the pack has disappeared
unexpectedly, print a message, try other packs (possibly
after re-scanning the list of packs), and find it in the new
pack.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's possible that while pack-objects is running, a
simultaneously running prune process might delete a pack
that we are interested in. Because we load the pack indices
early on, we know that the pack contains our item, but by
the time we try to open and map it, it is gone.
Since c715f78, we already protect against this in the normal
object access code path, but pack-objects accesses the packs
at a lower level. In the normal access path, we call
find_pack_entry, which will call find_pack_entry_one on each
pack index, which does the actual lookup. If it gets a hit,
we will actually open and verify the validity of the
matching packfile (using c715f78's is_pack_valid). If we
can't open it, we'll issue a warning and pretend that we
didn't find it, causing us to go on to the next pack (or on
to loose objects).
Furthermore, we will cache the descriptor to the opened
packfile. Which means that later, when we actually try to
access the object, we are likely to still have that packfile
opened, and won't care if it has been unlinked from the
filesystem.
Notice the "likely" above. If there is another pack access
in the interim, and we run out of descriptors, we could
close the pack. And then a later attempt to access the
closed pack could fail (we'll try to re-open it, of course,
but it may have been deleted). In practice, this doesn't
happen because we tend to look up items and then access them
immediately.
Pack-objects does not follow this code path. Instead, it
accesses the packs at a much lower level, using
find_pack_entry_one directly. This means we skip the
is_pack_valid check, and may end up with the name of a
packfile, but no open descriptor.
We can add the same is_pack_valid check here. Unfortunately,
the access patterns of pack-objects are not quite as nice
for keeping lookup and object access together. We look up
each object as we find out about it, and the only later when
writing the packfile do we necessarily access it. Which
means that the opened packfile may be closed in the interim.
In practice, however, adding this check still has value, for
three reasons.
1. If you have a reasonable number of packs and/or a
reasonable file descriptor limit, you can keep all of
your packs open simultaneously. If this is the case,
then the race is impossible to trigger.
2. Even if you can't keep all packs open at once, you
may end up keeping the deleted one open (i.e., you may
get lucky).
3. The race window is shortened. You may notice early that
the pack is gone, and not try to access it. Triggering
the problem without this check means deleting the pack
any time after we read the list of index files, but
before we access the looked-up objects. Triggering it
with this check means deleting the pack means deleting
the pack after we do a lookup (and successfully access
the packfile), but before we access the object. Which
is a smaller window.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/pending:
commit: factor out clear_commit_marks_for_object_array
checkout: use leak_pending flag
bundle: use leak_pending flag
bisect: use leak_pending flag
revision: add leak_pending flag
checkout: use add_pending_{object,sha1} in orphan check
revision: factor out add_pending_sha1
checkout: check for "Previous HEAD" notice in t2020
Conflicts:
builtin/checkout.c
revision.c
* nd/maint-autofix-tag-in-head:
Accept tags in HEAD or MERGE_HEAD
merge: remove global variable head[]
merge: use return value of resolve_ref() to determine if HEAD is invalid
merge: keep stash[] a local variable
Conflicts:
builtin/merge.c
Implemented internally instead of as "git merge --no-commit && git commit"
so that "merge --edit" is otherwise consistent (hooks, etc) with "merge".
Note: the edit message does not include the status information that one
gets with "commit --status" and it is cleaned up after editing like one
gets with "commit --cleanup=default". A later patch could add the status
information if desired.
Note: previously we were not calling stripspace() after running the
prepare-commit-msg hook. Now we are, stripping comments and
leading/trailing whitespace lines if --edit is given, otherwise only
stripping leading/trailing whitespace lines if not given --edit.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I noticed this when "git am CORRUPTED" unexpectedly failed with an
odd diagnostic, and even removed one of the files it was supposed
to have patched.
Reproduce with any valid old/new patch from which you have removed
the "+++ b/FILE" line. You'll see a diagnostic like this
fatal: unable to write file '(null)' mode 100644: Bad address
and you'll find that FILE has been removed.
The above is on glibc-based systems. On other systems, rather than
getting "null", you may provoke a segfault as git tries to
dereference the NULL file name.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/check-ref-format-3: (23 commits)
add_ref(): verify that the refname is formatted correctly
resolve_ref(): expand documentation
resolve_ref(): also treat a too-long SHA1 as invalid
resolve_ref(): emit warnings for improperly-formatted references
resolve_ref(): verify that the input refname has the right format
remote: avoid passing NULL to read_ref()
remote: use xstrdup() instead of strdup()
resolve_ref(): do not follow incorrectly-formatted symbolic refs
resolve_ref(): extract a function get_packed_ref()
resolve_ref(): turn buffer into a proper string as soon as possible
resolve_ref(): only follow a symlink that contains a valid, normalized refname
resolve_ref(): use prefixcmp()
resolve_ref(): explicitly fail if a symlink is not readable
Change check_refname_format() to reject unnormalized refnames
Inline function refname_format_print()
Make collapse_slashes() allocate memory for its result
Do not allow ".lock" at the end of any refname component
Refactor check_refname_format()
Change check_ref_format() to take a flags argument
Change bad_ref_char() to return a boolean value
...
* mz/remote-rename:
remote: only update remote-tracking branch if updating refspec
remote rename: warn when refspec was not updated
remote: "rename o foo" should not rename ref "origin/bar"
remote: write correct fetch spec when renaming remote 'remote'
* cb/common-prefix-unification:
rename pathspec_prefix() to common_prefix() and move to dir.[ch]
consolidate pathspec_prefix and common_prefix
remove prefix argument from pathspec_prefix
The previous logic in show_config was to print the delimiter when the
value was set, but Boolean variables have an implicit value "true" when
they appear with no value in the config file. As a result, we got:
git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean
git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue
Fix this by defering the display of the separator until after the value
to display has been computed.
Reported-by: Brian Foster <brian.foster@maxim-ic.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, gcc complains as follows:
CC tree-walk.o
tree-walk.c: In function `traverse_trees':
tree-walk.c:347: warning: 'e' might be used uninitialized in this \
function
CC builtin/revert.o
builtin/revert.c: In function `verify_opt_mutually_compatible':
builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
this function
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Close FETCH_HEAD and release the string url even if we have to leave the
function store_updated_refs() early.
Reported-by: Chris Wilson <cwilson@vigilantsw.com>
Helped-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "merge --log" and fmt-merge-msg to use branch description
information when merging a local topic branch into the mainline. The
description goes between the branch name label and the list of commit
titles.
The refactoring to share the common configuration parsing between
merge and fmt-merge-msg needs to be made into a separate patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-no-cherry-pick-head-after-punted:
cherry-pick: do not give irrelevant advice when cherry-pick punted
revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
Conflicts:
builtin/revert.c
If a cherry-pick did not even start because the working tree had local
changes that would overlap with the operation, we shouldn't be advising
the users to resolve conflicts nor to conclude it with "git commit".
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
do_pick_commit() writes out CHERRY_PICK_HEAD before invoking merge (either
via do_recursive_merge() or try_merge_command()) on the assumption that if
the merge fails it is due to conflict. However, if the tree is dirty, the
merge may not even start, aborting before do_pick_commit() can remove
CHERRY_PICK_HEAD.
Instead, defer writing CHERRY_PICK_HEAD till after merge has returned.
At this point we know the merge has either succeeded or failed due
to conflict. In either case, we want CHERRY_PICK_HEAD to be written
so that it may be picked up by the subsequent invocation of commit.
Note that do_recursive_merge() aborts if the merge cannot start, while
try_merge_command() returns a non-zero value other than 1.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This code calls git_config from a helper function to parse the config entry
it is interested in. Calling git_config in this way may cause a problem if
the helper function can be called after a previous call to git_config by
another function since the second call to git_config may reset some
variable to the value in the config file which was previously overridden.
The above is not a problem in this case since the function passed to
git_config only parses one config entry and the variable it sets is not
assigned outside of the parsing function. But a programmer who desires
all of the standard config options to be parsed may be tempted to modify
git_attr_config() so that it falls back to git_default_config() and then it
_would_ be vulnerable to the above described behavior.
So, move the call to git_config up into the top-level cmd_* function and
move the responsibility for parsing core.attributesfile into the main
config file parser.
Which is only the logical thing to do ;-)
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "it" string would not be free'ed if base_name was non-NULL.
Let's free it.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "x"-prefixed versions of strdup, malloc, etc. will check whether the
allocation was successful and terminate the process otherwise.
A few uses of malloc were left alone since they already implemented a
graceful path of failure or were in a quasi external library like xdiff.
Additionally, the call to malloc in compat/win32/syslog.c was not modified
since the syslog() implemented there is a die handler and a call to the
x-wrappers within a die handler could result in recursion should memory
allocation fail. This will have to be addressed separately.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using branch.$name.description as the configuration key, give users a
place to write about what the purpose of the branch is and things like
that, so that various subsystems, e.g. "push -s", "request-pull", and
"format-patch --cover-letter", can later be taught to use this
information.
The "-m" option similar to "commit/tag" is deliberately omitted, as the
whole point of branch description is about giving descriptive information
(the name of the branch itself is a better place for information that fits
on a single-line).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the description for the branch when preparing the cover letter
when available.
While at it, mark a loosely written codepath that would do a random and
useless thing given an unusual input (e.g. "^master HEAD HEAD^"), which
we may want to fix someday.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since much of the infrastructure does not work correctly with
unnormalized refnames, change check_refname_format() to reject them.
Similarly, change "git check-ref-format" to reject unnormalized
refnames by default. But add an option --normalize, which causes "git
check-ref-format" to normalize the refname before checking its format,
and print the normalized refname. This is exactly the behavior of the
old --print option, which is retained but deprecated.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Soon we will make printing independent of collapsing.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will make upcoming changes a tiny bit easier.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change check_ref_format() to take a flags argument that indicates what
is acceptable in the reference name (analogous to "git
check-ref-format"'s "--allow-onelevel" and "--refspec-pattern"). This
is more convenient for callers and also fixes a failure in the test
suite (and likely elsewhere in the code) by enabling "onelevel" and
"refspec-pattern" to be allowed independently of each other.
Also rename check_ref_format() to check_refname_format() to make it
obvious that it deals with refnames rather than references themselves.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also add tests of the new options. (Actually, one big reason to add
the new options is to make it easy to test check_ref_format(), though
the options should also be useful to other scripts.)
Interpret the result of check_ref_format() based on which types of
refnames are allowed. However, because check_ref_format() can only
return a single value, one test case is still broken. Specifically,
the case "git check-ref-format --onelevel '*'" incorrectly succeeds
because check_ref_format() returns CHECK_REF_FORMAT_ONELEVEL for this
refname even though the refname is also CHECK_REF_FORMAT_WILDCARD.
The type of check that leads to this failure is used elsewhere in
"real" code and could lead to bugs; it will be fixed over the next few
commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/argv-array:
run_hook: use argv_array API
checkout: use argv_array API
bisect: use argv_array API
quote: provide sq_dequote_to_argv_array
refactor argv_array into generic code
quote.h: fix bogus comment
add sha1_array API docs
* mg/branch-list:
t3200: clean up checks for file existence
branch: -v does not automatically imply --list
branch: allow pattern arguments
branch: introduce --list option
git-branch: introduce missing long forms for the options
git-tag: introduce long forms for the options
t6040: test branch -vv
Conflicts:
Documentation/git-tag.txt
t/t3200-branch.sh
* jk/for-each-ref:
for-each-ref: add split message parts to %(contents:*).
for-each-ref: handle multiline subjects like --pretty
for-each-ref: refactor subject and body placeholder parsing
t6300: add more body-parsing tests
t7004: factor out gpg setup
* jc/receive-verify:
receive-pack: check connectivity before concluding "git push"
check_everything_connected(): libify
check_everything_connected(): refactor to use an iterator
fetch: verify we have everything we need before updating our ref
Conflicts:
builtin/fetch.c
* jc/fetch-verify:
fetch: verify we have everything we need before updating our ref
rev-list --verify-object
list-objects: pass callback data to show_objects()
* rr/revert-cherry-pick-continue:
builtin/revert.c: make commit_list_append() static
revert: Propagate errors upwards from do_pick_commit
revert: Introduce --continue to continue the operation
revert: Don't implicitly stomp pending sequencer operation
revert: Remove sequencer state when no commits are pending
reset: Make reset remove the sequencer state
revert: Introduce --reset to remove sequencer state
revert: Make pick_commits functionally act on a commit list
revert: Save command-line options for continuing operation
revert: Save data for continuing after conflict resolution
revert: Don't create invalid replay_opts in parse_args
revert: Separate cmdline parsing from functional code
revert: Introduce struct to keep command-line options
revert: Eliminate global "commit" variable
revert: Rename no_replay to record_origin
revert: Don't check lone argument in get_encoding
revert: Simplify and inline add_message_to_msg
config: Introduce functions to write non-standard file
advice: Introduce error_resolve_conflict
Make ERR as first packet of remote snapshot reply work like it does in
fetch/push. Lets servers decline remote snapshot with message the same
way as declining fetch/push with a message.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-grep-untracked-exclude:
grep: teach --untracked and --exclude-standard options
grep --no-index: don't use git standard exclusions
grep: do not use --index in the short usage output
Conflicts:
Documentation/git-grep.txt
builtin/grep.c
Give each mode of operation (all, from stdin, given commits) its own usage
line to make it easier to see that they are mutually exclusive.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Factor out the code to clear the commit marks for a whole struct
object_array from builtin/checkout.c into its own exported function
clear_commit_marks_for_object_array and use it in bisect and bundle
as well. It handles tags and commits and ignores objects of any
other type.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of going through all the references again when we clear the
commit marks, do it like bisect and bundle and gain ownership of the
list of pending objects which we constructed from those references.
We simply copy the struct object_array that points to the list, set
the flag leak_pending and then prepare_revision_walk won't destroy
it and it's ours. We use it to clear the marks and free it at the
end.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of building a list of textual arguments for setup_revisions, use
add_pending_object and add_pending_sha1 to queue the objects directly.
This is both faster and simpler.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a push specifies deletion of non-existent refs, the post post-receive and
post-update hooks receive them as input/arguments.
For instance, for the following push, where refs/heads/nonexistent is a ref
which does not exist on the remote side:
git push origin :refs/heads/nonexistent
the post-receive hook receives from standard input:
<null-sha1> SP <null-sha1> SP refs/heads/nonexistent
and the post-update hook receives as arguments:
refs/heads/nonexistent
which does not make sense since it is a no-op.
Teach receive-pack not to pass non-existent refs to the post-receive and
post-update hooks. If the push only attempts to delete non-existent refs,
these hooks are not even called.
The update and pre-receive hooks are still notified about attempted
deletion of non-existent refs to give them a chance to inspect the
situation and act on it.
[jc: mild fix-ups to avoid introducing an extra list; also added fixes to
some tests]
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Checking paths out of a tree is (currently) defined to do:
- Grab the paths from the named tree that match the given pathspec,
and add them to the index;
- Check out the contents from the index for paths that match the
pathspec to the working tree; and while at it
- If the given pathspec did not match anything, suspect a typo from the
command line and error out without updating the index nor the working
tree.
Suppose that the branch you are working on has dir/myfile, and the "other"
branch has dir/other but not dir/myfile. Further imagine that you have
either modified or removed dir/myfile in your working tree, but you have
not run "git add dir/myfile" or "git rm dir/myfile" to tell Git about your
local change. Running
$ git checkout other dir
would add dir/other to the index with the contents taken out of the
"other" branch, and check out the paths from the index that match the
pathspec "dir", namely, "dir/other" and "dir/myfile", overwriting your
local changes to "dir/myfile", even though "other" branch does not even
know about that file.
Fix it by updating the working tree only with the index entries that
was read from the "other" tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git describe --dirty the index should be refreshed. Previously
the cached index would cause describe to think that the index was dirty when,
in reality, it was just stale.
The issue was exposed by python setuptools which hardlinks files into another
directory when building a distribution.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option causes check-attr to consider .gitattributes only from
the index, ignoring .gitattributes from the working tree. This allows
the command to be used in situations where a working tree does not exist.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_one_patchid() uses a rather dumb heuristic to determine if the
passed buffer is part of the next commit. Whenever the first 40 bytes
are a valid hexadecimal sha1 representation, get_one_patchid() returns
next_sha1.
Once the current line is longer than the fixed buffer, this will break
(provided the additional bytes make a valid hexadecimal sha1). As a result
patch-id returns incorrect results. Instead, use strbuf and read one line
at a time.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the usual "git" transport, a large-ish transfer with "git fetch" and
"git pull" give progress eye-candy to avoid boring users. However, not
when they are reading from a bundle. I.e.
$ git pull ../git-bundle.bndl master
This teaches bundle.c:unbundle() to give "-v" option to index-pack and
tell it to give progress bar when transport decides it is necessary.
The operation in the other direction, "git bundle create", could also
learn to honor --quiet but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
HEAD and MERGE_HEAD (among other branch tips) should never hold a
tag. That can only be caused by broken tools and is cumbersome to fix
by an end user with:
$ git update-ref HEAD $(git rev-parse HEAD^{commit})
which may look like a magic to a new person.
Be easy, warn users (so broken tools can be fixed if they bother to
report) and move on.
Be robust, if the given SHA-1 cannot be resolved to a commit object,
die (therefore return value is always valid).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also kill head_invalid in favor of "head_commit == NULL".
Local variable "head" in cmd_merge() is renamed to "head_sha1" to make
sure I don't miss any access because this variable should not be used
after head_commit is set (use head_commit->object.sha1 instead).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref() only updates "head" when it returns non NULL value (it
may update "head" even when returning NULL, but not in all cases).
Because "head" is not initialized before the call, is_null_sha1() is
not enough. Check also resolve_ref() return value.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git branch" command, while not in listing mode, calls create_branch()
even when the target branch already exists, and it does so even when it is
not interested in updating the value of the branch (i.e. the name of the
commit object that sits at the tip of the existing branch). This happens
when the command is run with "--set-upstream" option.
The earlier safety-measure to prevent "git branch -f $branch $commit" from
updating the currently checked out branch did not take it into account,
and we no longer can update the tracking information of the current branch.
Minimally fix this regression by telling the validation code if it is
called to really update the value of a potentially existing branch, or if
the caller merely is interested in updating auxiliary aspects of a branch.
Reported-and-Tested-by: Jay Soffian
Signed-off-by: Junio C Hamano <gitster@pobox.com>
What should happen if you run this command?
$ git ls-remote -h
It does not give a short-help for the command. Instead because "-h" is a
synonym for "--heads", it runs "git ls-remote --heads", and because there
is no remote specified on the command line, we run it against the default
"origin" remote, hence end up doing the same as
$ git ls-remote --heads origin
Fix this counter-intuitive behaviour by special casing a lone "-h" that
does not have anything else on the command line and calling usage().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It probably is not such a good idea to use ":/<pattern>" to specify which
commit to merge, as ":/<pattern>" can often hit unexpected commits, but
somebody tried it and got a nonsense error message:
fatal: ':/Foo bar' does not point to a commit
So here is a for-the-sake-of-consistency update that is fairly useless
that allows users to carefully try not shooting in the foot.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were using a similar ad-hoc rev_list_args structure, but
this saves some code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Yes, there is a warning that says the function is only used by push in big
red letters in front of this function, but it didn't say a more important
thing it should have said: what the function is for and what it does.
Rename it and document it to avoid future confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
