Commit b60daf0 (Make git-prune-packed a bit more chatty. - 2007-01-12)
changes the meaning of prune_packed_objects()'s argument, from "dry
run or not dry run" to a bitmap.
It however forgot to update prune_packed_objects() caller in
builtin/prune.c to use new DRY_RUN macro. It's fine (for a long time!)
but there is a risk that someday someone may change the value of
DRY_RUN to something else and builtin/prune.c suddenly breaks. Avoid
that possibility.
While at there, change "opts == VERBOSE" to "opts & VERBOSE" as there
is no obvious reason why we only be chatty when DRY_RUN is not set.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit f269048 (fetch: opportunistically update tracking refs,
2013-05-11) we update tracking refs opportunistically when fetching
remote branches. However, if there is a configured non-pattern refspec
that does not match any of the refspecs given on the command line then a
fatal error occurs.
Fix this by setting the "missing_ok" flag when calling get_fetch_map.
Test-added-by: Jeff King <peff@peff.net>
Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to make sure the cloned repository is good, we run "rev-list
--objects --not --all $new_refs" on the repository. This is expensive
on large repositories. This patch attempts to mitigate the impact in
this special case.
In the "good" clone case, we only have one pack. If all of the
following are met, we can be sure that all objects reachable from the
new refs exist, which is the intention of running "rev-list ...":
- all refs point to an object in the pack
- there are no dangling pointers in any object in the pack
- no objects in the pack point to objects outside the pack
The second and third checks can be done with the help of index-pack as
a slight variation of --strict check (which introduces a new condition
for the shortcut: pack transfer must be used and the number of objects
large enough to call index-pack). The first is checked in
check_everything_connected after we get an "ok" from index-pack.
"index-pack + new checks" is still faster than the current "index-pack
+ rev-list", which is the whole point of this patch. If any of the
conditions fail, we fall back to the good old but expensive "rev-list
..". In that case it's even more expensive because we have to pay for
the new checks in index-pack. But that should only happen when the
other side is either buggy or malicious.
Cloning linux-2.6 over file://
before after
real 3m25.693s 2m53.050s
user 5m2.037s 4m42.396s
sys 0m13.750s 0m16.574s
A more realistic test with ssh:// over wireless
before after
real 11m26.629s 10m4.213s
user 5m43.196s 5m19.444s
sys 0m35.812s 0m37.630s
This shortcut is not applied to shallow clones, partly because shallow
clones should have no more objects than a usual fetch and the cost of
rev-list is acceptable, partly to avoid dealing with corner cases when
grafting is involved.
This shortcut does not apply to unpack-objects code path either
because the number of objects must be small in order to trigger that
code path.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only consider the first parent commit when walking the commit history. This
is useful if you only wish to match tags on your branch after a merge.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make get_color_ui_found default to -1, and make it explicit that 0 is the
default value when nothing else is found.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we run a regular "git fetch" without arguments, we
update the tracking refs according to the configured
refspec. However, when we run "git fetch origin master" (or
"git pull origin master"), we do not look at the configured
refspecs at all, and just update FETCH_HEAD.
We miss an opportunity to update "refs/remotes/origin/master"
(or whatever the user has configured). Some users find this
confusing, because they would want to do further comparisons
against the old state of the remote master, like:
$ git pull origin master
$ git log HEAD...origin/master
In the currnet code, they are comparing against whatever
commit happened to be in origin/master from the last time
they did a complete "git fetch". This patch will update a
ref from the RHS of a configured refspec whenever we happen
to be fetching its LHS. That makes the case above work.
The downside is that any users who really care about whether
and when their tracking branches are updated may be
surprised.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Each "struct ref" has a boolean flag that is set by the
fetch code to determine whether the ref should be marked as
"not-for-merge" or not when we write it out to FETCH_HEAD.
It would be useful to turn this boolean into a tri-state,
with the third state meaning "do not bother writing it out
to FETCH_HEAD at all". That would let us add extra refs to
the set of refs to be stored (e.g., to store copies of
things we fetched) without impacting FETCH_HEAD.
This patch turns it into an enum that covers the tri-state
case, and hopefully makes the code more explicit and easier
to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
check_everything_connected could take a long time, especially in the
clone case where the whole DAG is traversed. The user deserves to know
what's going on.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use help.c:help_unknown_ref() instead of die() to provide a
friendlier error message before exiting, when one of the refs
specified in a merge is unknown.
Signed-off-by: Vikrant Varma <vikrant.varma94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's wrong to call get_sha1() if they should be SHA-1s, plus
inefficient.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually "foo:bar" is interpreted as an ssh url. This patch allows to
clone from such paths by putting at least one slash before the colon
(i.e. /path/to/foo:bar or just ./foo:bar).
file://foo:bar should also work, but local optimizations are off in
that case, which may be unwanted. While at there, warn the users about
--local being ignored in this case.
Reported-by: William Giokas <1007380@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need the parsed objects at this point, merely the
information that they have marks.
Seems to be three times faster in my setup with lots of objects.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We read from the marks file and keep only marked commits, but in
order to find the type of object, we are parsing the whole thing,
which is slow, specially in big repositories with lots of big files.
There's no need for that, we can query the object information with
sha1_object_info().
Before this, loading the objects of a fresh emacs import, with 260598
blobs took 14 minutes, after this patch, it takes 3 seconds.
This is the way fast-import does it. Also die if the object is not
found (like fast-import).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge-tree causes a null pointer dereference when a directory
entry exists in only one or two of the three trees being compared with
no corresponding entry in the other tree(s).
When this happens, we want to handle the entry as a directory and not
attempt to mark it as a file merge. Do this by setting the entries bit
in the directory mask when the entry is missing or when it is a
directory, only performing the file comparison when we know that a file
entry exists.
Reported-by: Andreas Jacobsen <andreas@andreasjacobsen.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Tested-by: Andreas Jacobsen <andreas@andreasjacobsen.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/remote-tighten-commandline-parsing:
remote: 'show' and 'prune' can take more than one remote
remote: check for superfluous arguments in 'git remote add'
remote: add a test for extra arguments, according to docs
pack-refs.c doesn't contain much code, and the code it does contain is
closely related to reference handling. Moreover, there is some
duplication between pack_refs() and repack_without_ref(). Therefore,
merge pack-refs.c into refs.c and pack-refs.h into refs.h.
The code duplication will be addressed in future commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/remote-tighten-commandline-parsing:
remote: 'show' and 'prune' can take more than one remote
remote: check for superfluous arguments in 'git remote add'
remote: add a test for extra arguments, according to docs
Sparse issues an "'junk_mode' not declared. Should it be static?"
warning. In order to suppress the warning, since this symbol does
not need more than file visibility, we simply add the static
modifier to its declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit aacecc3 (merge-tree: don't print entries that match "local" -
2013-04-07) had a typo causing the "same in both" check to be incorrect
and check if both the base and "their" versions are removed instead of
checking that both the "our" and "their" versions are removed. Fix
this.
Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update documentation for "log" and "shortlog".
* rr/shortlog-doc:
builtin/shortlog.c: make usage string consistent with log
builtin/log.c: make usage string consistent with doc
git-shortlog.txt: make SYNOPSIS match log, update OPTIONS
git-log.txt: rewrite note on why "--" may be required
git-log.txt: generalize <since>..<until>
git-log.txt: order OPTIONS properly; move <since>..<until>
revisions.txt: clarify the .. and ... syntax
git-shortlog.txt: remove (-h|--help) from OPTIONS
Introduce "--ignore-removal" as a synonym to "--no-all" for "git
add", and improve the 2.0 migration warning with it.
* jc/add-ignore-removal:
git add: rephrase -A/--no-all warning
git add: --ignore-removal is a better named --no-all
In preparation for Git 2.0, "git add -u/-A" without pathspec checks
all the working tree (not limited to the current directory) and
issues a warning when it finds any path that we might add in Git
2.0, because that would mean the users' fingers need to be trained
to explicitly say "." if they want to keep the current behaviour.
However, the check was incomplete, because "git add" usually does
not refresh the index, considers a path that is stat-dirty but has
contents that is otherwise up-to-date in the index as "we might
add", and relies on that it is a no-op to add the same thing again
via the add_file_to_index() API (which also knows not to say "added"
in verbose mode when this happens). We do not want to trigger the
warning for a path that is outside the current directory is merely
stat-dirty, as it won't be added in Git 2.0, either.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
* rt/commentchar-fmt-merge-msg:
t6200: avoid path mangling issue on Windows
fmt-merge-msg: use core.commentchar in tag signatures completely
fmt-merge-msg: respect core.commentchar in people credits
Earlier we added support for --expire=all (or --expire=now) that
considers all crufts, regardless of their age, as eligible for
garbage collection by turning command argument parsers that use
approxidate() to use parse_expiry_date(), but "git prune" used a
built-in parse-options facility OPT_DATE() and did not benefit from
the new function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allows remote-helpers to declare they can handle signed tags, and
issue a warning when using those that don't.
* jk/remote-helper-with-signed-tags:
transport-helper: add 'signed-tags' capability
transport-helper: pass --signed-tags=warn-strip to fast-export
fast-export: add --signed-tags=warn-strip mode
"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload. Make the code
notice the type of the tag object, in addition to the dwim_ref()
based classification the current code uses (i.e. the name appears in
refs/tags/) to decide when to special case merging of tags.
* jc/merge-tag-object:
t6200: test message for merging of an annotated tag
t6200: use test_config/test_unconfig
merge: a random object may not necssarily be a commit
The 'git remote add' subcommand did not check for superfluous command
line arguments. Make it so.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty-printing body of the commit that is stored in non UTF-8
encoding did not work well. The early part of this series fixes
it. And then it adds %C(auto) specifier that turns the coloring on
when we are emitting to the terminal, and adds column-aligning
format directives.
* nd/pretty-formats:
pretty: support %>> that steal trailing spaces
pretty: support truncating in %>, %< and %><
pretty: support padding placeholders, %< %> and %><
pretty: add %C(auto) for auto-coloring
pretty: split color parsing into a separate function
pretty: two phase conversion for non utf-8 commits
utf8.c: add reencode_string_len() that can handle NULs in string
utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
utf8.c: move display_mode_esc_sequence_len() for use by other functions
pretty: share code between format_decoration and show_decorations
pretty-formats.txt: wrap long lines
pretty: get the correct encoding for --pretty:format=%e
pretty: save commit encoding from logmsg_reencode if the caller needs it
Fixes a handful of issues in the code to traverse working tree to
find untracked and/or ignored files, cleans up and optimizes the
codepath in general.
* kb/status-ignored-optim-2:
dir.c: git-status --ignored: don't scan the work tree twice
dir.c: git-status --ignored: don't scan the work tree three times
dir.c: git-status: avoid is_excluded checks for tracked files
dir.c: replace is_path_excluded with now equivalent is_excluded API
dir.c: unify is_excluded and is_path_excluded APIs
dir.c: move prep_exclude
dir.c: factor out parts of last_exclude_matching for later reuse
dir.c: git-clean -d -X: don't delete tracked directories
dir.c: make 'git-status --ignored' work within leading directories
dir.c: git-status --ignored: don't list empty directories as ignored
dir.c: git-ls-files --directories: don't hide empty directories
dir.c: git-status --ignored: don't list empty ignored directories
dir.c: git-status --ignored: don't list files in ignored directories
dir.c: git-status --ignored: don't drop ignored directories
When receive-pack detects error in the pack header it received in
order to decide which of unpack-objects or index-pack to run, it
returned without closing the error stream, which led to a hang
sideband thread.
* jk/receive-pack-deadlocks-with-early-failure:
receive-pack: close sideband fd on early pack errors
Now we have a synonym --ignore-removal for --no-all, we can rephrase
the Git 2.0 transition warning message in a more natural way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the historical context of "git add --all ." that pays attention
to "all kinds of changes" (implying "without ignoring removals"),
the option to countermand it "--no-all" may have made sense, but
because we will be making "--all" the default when a pathspec is
given, it makes more sense to rename the option to a more explicit
"--ignore-removal". The "--all" option naturally becomes its
negation, "--no-ignore-removal".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone" did not work if a repository pointed at by the
"--reference" option is a gitfile that points at another place.
* as/clone-reference-with-gitfile:
clone: Allow repo using gitfile as a reference
clone: Fix error message for reference repository
Preparatory steps to make "git add <pathspec>" take notice of
removed paths that match <pathspec> by default in Git 2.0.
* 'jc/add-2.0-delete-default' (early part):
git add: rephrase the "removal will cease to be ignored" warning
git add: rework the logic to warn "git add <pathspec>..." default change
git add: start preparing for "git add <pathspec>..." to default to "-A"
builtin/add.c: simplify boolean variables
Make the initial "sparse" selection of the paths more sticky across
"git checkout".
* nd/checkout-keep-sparse:
checkout: add --ignore-skip-worktree-bits in sparse checkout mode
A commit object whose author or committer ident are malformed
crashed some code that trusted that a name, an email and an
timestamp can always be found in it.
* jk/chopped-ident:
blame: handle broken commit headers gracefully
pretty: handle broken commit headers gracefully
cat-file: print tags raw for "cat-file -p"
"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace '<since>..<until>' with '<revision range>', in accordance with
the documentation.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now the logic to decide when to warn has been tightened, we know the
user is in a situation where the current and future behaviours will
be different. Spell out what happens with these two versions and
how to explicitly ask for the behaviour, and suggest "git status" as
a way to inspect the current status.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
