Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
once there no longer is any other branch whose name begins with
"foo/", but we didn't do so so far. Now we do.
* mh/ref-remove-empty-directory: (23 commits)
files_transaction_commit(): clean up empty directories
try_remove_empty_parents(): teach to remove parents of reflogs, too
try_remove_empty_parents(): don't trash argument contents
try_remove_empty_parents(): rename parameter "name" -> "refname"
delete_ref_loose(): inline function
delete_ref_loose(): derive loose reference path from lock
log_ref_write_1(): inline function
log_ref_setup(): manage the name of the reflog file internally
log_ref_write_1(): don't depend on logfile argument
log_ref_setup(): pass the open file descriptor back to the caller
log_ref_setup(): improve robustness against races
log_ref_setup(): separate code for create vs non-create
log_ref_write(): inline function
rename_tmp_log(): improve error reporting
rename_tmp_log(): use raceproof_create_file()
lock_ref_sha1_basic(): use raceproof_create_file()
lock_ref_sha1_basic(): inline constant
raceproof_create_file(): new function
safe_create_leading_directories(): set errno on SCLD_EXISTS
safe_create_leading_directories_const(): preserve errno
...
"git repack --depth=<n>" for a long time busted the specified depth
when reusing delta from existing packs. This has been corrected.
* jk/delta-chain-limit:
pack-objects: convert recursion to iteration in break_delta_chain()
pack-objects: enforce --depth limit in reused deltas
"git describe" and "git name-rev" have been taught to take more
than one refname patterns to restrict the set of refs to base their
naming output on, and also learned to take negative patterns to
name refs not to be used for naming via their "--exclude" option.
* jk/describe-omit-some-refs:
describe: teach describe negative pattern matches
describe: teach --match to accept multiple patterns
name-rev: add support to exclude refs by pattern match
name-rev: extend --refs to accept multiple patterns
doc: add documentation for OPT_STRING_LIST
In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11),
the default aggressive depth of git-gc has been changed to 50. While
git-config(1) has been updated to represent the new default value,
git-gc(1) still mentions the old value. This patch fixes it.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Within the help message of 'git add -i', the 'diff' command uses one
tab character and blanks to create the space between the name and the
description while the others use blanks only. So if the tab size is
not at 4 characters, this description will not be in range.
Replace the tab character with blanks.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for git blame used vertical bars for optional
arguments to -M and -C, which is unusual and potentially confusing.
Since most man pages use brackets for optional items, and that's
consistent with how we document the same options for git diff and
friends, use brackets here, too.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option is “--detach”, but we accidentally spelled it “--detached” at
one point in the man page.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Reported-by: Casey Rodarmor <casey@rodarmor.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use of 'iff' may be confusing to people not familiar with this term.
Improving the --normalize option's documentation to remove the use of
'iff', and clearly describe what happens when the condition is not met.
Signed-off-by: Damien Regad <dregad@mantisbt.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not just . and .., but any path that begins with dot is not copied
when copying the template directory to a new repository. You can
customize the template directory, copying some dotfiles might make
sense, but it's actually a good thing not to, because you would not
want to have your git directory copied in every git directory that
is created should you decide to put your template directory under
version control, for example. Plus, it might be used as a feature
by people who would want to exclude some files.
Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"ls-files" run with pathspec has been micro-optimized to avoid
having to memmove(3) unnecessary bytes.
* rs/ls-files-partial-optim:
ls-files: move only kept cache entries in prune_cache()
ls-files: pass prefix length explicitly to prune_cache()
A new coccinelle rule that catches a check of !pointer before the
pointer is free(3)d, which most likely is a bug.
* rs/cocci-check-free-only-null:
cocci: detect useless free(3) calls
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
* ls/p4-path-encoding:
git-p4: fix git-p4.pathEncoding for removed files
The current code wants to record an error condition from
either ferror() or fclose(), but makes sure that we always
call both functions. So it can't use logical-OR "||", which
would short-circuit when ferror() is true. Instead, it uses
bitwise-OR "|" to evaluate both functions and set one or
more bits in the "err" flag if they reported a failure.
Unlike logical-OR, though, bitwise-OR does not introduce a
sequence point, and the order of evaluation for its operands
is unspecified. So a compiler would be free to generate code
which calls fclose() first, and then ferror() on the
now-freed filehandle.
There's no indication that this has happened in practice,
but let's write it out in a way that follows the standard.
Noticed-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add missing `::` after the title.
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
Acked-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is often useful to break a commit into multiple parts that are more
logical separations. This can be tricky to learn how to do without the
brute-force method if re-writing code or commit messages from scratch.
Add a section to the git-reset documentation which shows an example
process for how to use git add -p and git commit -c HEAD@{1} to
interactively break a commit apart and re-use the original commit
message as a starting point when making the new commit message.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
