* nd/struct-pathspec:
pathspec: rename per-item field has_wildcard to use_wildcard
Improve tree_entry_interesting() handling code
Convert read_tree{,_recursive} to support struct pathspec
Reimplement read_tree_recursive() using tree_entry_interesting()
* mg/reflog-with-options:
reflog: fix overriding of command line options
t/t1411: test reflog with formats
builtin/log.c: separate default and setup of cmd_log_init()
* ab/i18n-fixup: (24 commits)
i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
i18n: use test_i18n{grep,cmp} in t7508
i18n: use test_i18ngrep in t7506
i18n: use test_i18ngrep and test_i18ncmp in t7502
i18n: use test_i18ngrep in t7501
i18n: use test_i18ncmp in t7500
i18n: use test_i18ngrep in t7201
i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
i18n: use test_i18ngrep in lib-httpd and t2019
i18n: do not overuse C_LOCALE_OUTPUT (grep)
i18n: use test_i18ncmp in t1200 and t2200
i18n: .git file is not a human readable message (t5601)
i18n: do not overuse C_LOCALE_OUTPUT
i18n: mark init-db messages for translation
i18n: mark checkout plural warning for translation
i18n: mark checkout --detach messages for translation
...
Since 0beee4c (git-add--interactive: remove hunk coalescing, 2008-07-02),
"git add--interactive" behaves lazily and passes overlapping hunks to the
underlying "git apply" without coalescing. This was partially corrected
by 7a26e65 (its partial revert, 2009-05-16), but overlapping hunks are
still passed when the patch is edited.
Teach "git apply" the --allow-overlap option that disables a safety
feature that avoids misapplication of patches by not applying patches
to overlapping hunks, and pass this option form "add -p" codepath.
Do not even advertise the option, as this is merely a workaround, and the
correct fix is to make "add -p" correctly coalesce adjacent patch hunks.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The names and e-mails are sanitized by fmt_ident() when creating commits,
so that they do not contain "<" nor ">", and the "committer" and "author"
lines in the commit object will always be in the form:
("author" | "committer") name SP "<" email ">" SP timestamp SP zone
When parsing the email part out, the current code looks for SP starting
from the end of the email part, but the author could obfuscate the address
as "author at example dot com".
We should instead look for SP followed by "<", to match the logic of the
side that formats these lines.
Signed-off-by: Josh Stone <jistone@redhat.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/rename-degrade-cc-to-c:
diffcore-rename: fall back to -C when -C -C busts the rename limit
diffcore-rename: record filepair for rename src
diffcore-rename: refactor "too many candidates" logic
builtin/diff.c: remove duplicated call to diff_result_code()
* rj/sparse:
sparse: Fix some "symbol not declared" warnings
sparse: Fix errors due to missing target-specific variables
sparse: Fix an "symbol 'merge_file' not decared" warning
sparse: Fix an "symbol 'format_subject' not declared" warning
sparse: Fix some "Using plain integer as NULL pointer" warnings
sparse: Fix an "symbol 'cmd_index_pack' not declared" warning
Makefile: Use cgcc rather than sparse in the check target
* mg/reflog-with-options:
reflog: fix overriding of command line options
t/t1411: test reflog with formats
builtin/log.c: separate default and setup of cmd_log_init()
When --count is used with --cherry-mark, omit the patch equivalent
commits from the count for left and right commits and print the count of
equivalent commits separately.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git add -u" updates the index with the updated contents from the working
tree by internally running "diff-files" to grab the set of paths that are
different from the index. Then it updates the index entries for the paths
that are modified in the working tree, and deletes the index entries for
the paths that are deleted in the working tree.
It ignored the output from the diff-files that indicated that a path is
unmerged. For these paths, it instead relied on the fact that an unmerged
path is followed by the result of comparison between stage #2 (ours) and
the working tree, and used that to update or delete such a path when it is
used to record the resolution of a conflict.
As the result, when a path did not have stage #2 (e.g. "we deleted while
the other side added"), these unmerged stages were left behind, instead of
recording what the user resolved in the working tree.
Since we recently fixed "diff-files" to indicate if the corresponding path
exists on the working tree for an unmerged path, we do not have to rely on
the comparison with stage #2 anymore. We can instead tell the diff-files
not to compare with higher stages, and use the unmerged output to update
the index to reflect the state of the working tree.
The changes to the test vector in t2200 illustrates the nature of the bug
and the fix. The test expected stage #1 and #3 entries be left behind,
but it was codifying the buggy behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike plain merge-base, merge-base --octopus only requires at least one
commit argument; update the synopsis to reflect that.
Add a sentence to the discussion that when --octopus is used, we do expect
'2' (the common ansestor across all) as the result.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use parse-options in cmd_log_init instead of manually iterating
through them. This makes the code a bit cleaner but more importantly
allows us to catch the "--quiet" option which causes some of the
log-related commands to misbehave as it would otherwise get passed on
to the diff.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '-r' command-line option is a no-op provided only for backward
compatiblity since abd6970 (cherry-pick: make -r the default, 2006-10-05),
and somehow ended up surviving across reimplementation in C at 9509af6
(Make git-revert & git-cherry-pick a builtin, 2007-03-01) and another
rewrite of the command line parser at f810379 (Make builtin-revert.c use
parse_options, 2007-10-07). We should have stopped advertising the option
long time ago.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --quiet flag is not meant to be passed on to the diff, as the user
always wants the patches to be produced so catch it and pass it to
reopen_stdout which decides whether to print the filename or not.
Noticed by Paul Gortmaker
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the init-db messages that were added in v1.7.5-rc1~16^2 (init,
clone: support --separate-git-dir for .git file) by Nguyễn Thái Ngọc
Duy for translation.
This requires splitting up the tests that the patch added so that
certain parts of them can be skipped unless the C_LOCALE_OUTPUT
prerequisite is satisfied.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the "Warning: you are leaving %d commit(s) behind" message added
in v1.7.5-rc0~74^2 (commit: give final warning when reattaching HEAD
to leave commits behind) by Junio C Hamano for translation.
This message requires the use of ngettext() features, and is the first
message to use the Q_() wrapper around ngettext().
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark messages added in v1.7.5-rc0~117^2~2 (checkout: introduce
--detach synonym for "git checkout foo^{commit}") by Junio C Hamano
for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the "repository '%s' does not exist" message added in
v1.7.4.2~21^2 (clone: die when trying to clone missing local path) by
Jeff King for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark CHERRY_PICK_HEAD related messages in builtin/merge.c that were
added in v1.7.5-rc0~88^2~2 (Introduce CHERRY_PICK_HEAD) by Jay Soffian
for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the merge messages that were added in v1.7.5-rc1~17^2 (merge:
merge with the default upstream branch without argument) by Junio C
Hamano for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the "Could not read from '%s'" message that was added to
builtin/merge.c in v1.7.4.2~25^2 (merge: honor prepare-commit-msg
hook) by Jay Soffian for translation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to fix the warning, we add a new "merge-file.h" header
containing the extern declaration of the merge_file() function,
and include the header in the source files that require the
declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to fix the warning, we add an extern declaration for this
function to the "commit.h" header file, along with all other non-
static functions defined in pretty.c. Also, we remove the function
declaration from builtin/shortlog.c, since it is no longer needed.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just like "git checkout -" is a short-hand for "git checkout @{-1}" to
conveniently switch back to the previous branch, "git merge -" is a
short-hand for "git merge @{-1}" to conveniently merge the previous branch.
It will allow me to say:
$ git checkout -b au/topic
$ git am -s ./+au-topic.mbox
$ git checkout pu
$ git merge -
which is an extremely typical and repetitive operation during my git day.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-remote-mirror-safer:
remote: deprecate --mirror
remote: separate the concept of push and fetch mirrors
remote: disallow some nonsensical option combinations
The pack-objects command should take notice of the object file and
refrain from attempting to delta large ones, to be consistent with
the fast-import command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If user sets config.abbrev option, use it as if --abbrev was given. This
is the default value and user can override different abbrev length by
specifying the --abbrev=N command line option.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the point of the last change is to allow use of strings as
literals no matter what characters are in them, "has_wildcard"
does not match what we use this field for anymore.
It is used to decide if the wildcard matching should be used, so
rename it to match the usage better.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also adds the new colors to show-branch that were added a while
back for graph output.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-fetch-on-demand:
fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
submodule update: Don't fetch when the submodule commit is already present
fetch/pull: Don't recurse into a submodule when commits are already present
Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
config: teach the fetch.recurseSubmodules option the 'on-demand' value
fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
fetch/pull: recurse into submodules when necessary
Conflicts:
builtin/fetch.c
submodule.c
* load_file() returns a void pointer but is using 0 for the return
value
* builtin/receive-pack.c forgot to include builtin.h
* packet_trace_prefix can be marked static
* ll_merge takes a pointer for its last argument, not an int
* crc32 expects a pointer as the second argument but Z_NULL is defined
to be 0 (see 38f4d13 sparse fix: Using plain integer as NULL pointer,
2006-11-18 for more info)
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/merge-sans-branch:
merge: merge with the default upstream branch without argument
merge: match the help text with the documentation
Conflicts:
builtin/merge.c
Currently, "git reflog" overrides some command line options such as
"--format".
Fix this by using the new 2-phase version of cmd_log_init().
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cmd_log_init() sets up some default rev options and then calls
setup_revisions(), so that a caller cannot set up own defaults: Either
they get overriden by cmd_log_init() (if set before) or they override
the command line (if set after). We even complain about this in a
comment to cmd_log_reflog().
Therefore, separate the two steps so that one can still call
cmd_log_init() or, alternatively, cmd_log_init_defaults() followed by
cmd_log_init_finish() (and set defaults in between).
No functional change so far.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration created by plain --mirror is dangerous and
useless, and we now have --mirror=fetch and --mirror=push to
replace it. Let's warn the user.
One alternative to this is to try to guess which type the
user wants. In a non-bare repository, a fetch mirror doesn't
make much sense, since it would overwrite local commits. But
in a bare repository, you might use either type, or even
both (e.g., if you are acting as an intermediate drop-point
across two disconnected networks).
So rather than try for complex heuristics, let's keep it
simple. The user knows what they're trying to do, so let
them tell us.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote currently has one option, "--mirror", which sets
up mirror configuration which can be used for either
fetching or pushing. It looks like this:
[remote "mirror"]
url = wherever
fetch = +refs/*:refs/*
mirror = true
However, a remote like this can be dangerous and confusing.
Specifically:
1. If you issue the wrong command, it can be devastating.
You are not likely to "push" when you meant to "fetch",
but "git remote update" will try to fetch it, even if
you intended the remote only for pushing. In either
case, the results can be quite destructive. An
unintended push will overwrite or delete remote refs,
and an unintended fetch can overwrite local branches.
2. The tracking setup code can produce confusing results.
The fetch refspec above means that "git checkout -b new
master" will consider refs/heads/master to come from
the remote "mirror", even if you only ever intend to
push to the mirror. It will set up the "new" branch to
track mirror's refs/heads/master.
3. The push code tries to opportunistically update
tracking branches. If you "git push mirror foo:bar",
it will see that we are updating mirror's
refs/heads/bar, which corresponds to our local
refs/heads/bar, and will update our local branch.
To solve this, we split the concept into "push mirrors" and
"fetch mirrors". Push mirrors set only remote.*.mirror,
solving (2) and (3), and making an accidental fetch write
only into FETCH_HEAD. Fetch mirrors set only the fetch
refspec, meaning an accidental push will not force-overwrite
or delete refs on the remote end.
The new syntax is "--mirror=<fetch|push>". For
compatibility, we keep "--mirror" as-is, setting up both
types simultaneously.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It doesn't make sense to use "-m" on a mirror, since "-m"
sets up the HEAD symref in the remotes namespace, but with
mirror, we are by definition not using a remotes namespace.
Similarly, it does not make much sense to specify refspecs
with --mirror. For a mirror you plan to push to, those
refspecs will be ignored. For a mirror you are fetching
from, there is no point in mirroring, since the refspec
specifies everything you want to grab.
There is one case where "--mirror -t <X>" would be useful.
Because <X> is used as-is in the refspec, and because we
append it to to refs/, you could mirror a subset of the
hierarchy by doing:
git remote add --mirror -t 'tags/*'
But using anything besides a single branch as an argument to
"-t" is not documented and only happens to work, so closing
it off is not a serious regression.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add two configration variables grep.extendedRegexp and grep.lineNumbers to
allow the user to skip typing -E and -n on the command line, respectively.
Scripts that are meant to be used by random users and/or in random
repositories now have use -G and/or --no-line-number options as
appropriately to override the settings in the repository or user's
~/.gitconfig settings. Just because the script didn't say "git grep -n" no
longer guarantees that the output from the command will not have line
numbers.
Signed-off-by: Joe Ratterman <jratt0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, "notes add" (without -f/--force) will abort when the given object
already has existing notes. This makes sense for the modes of "git notes add"
that would necessarily overwrite the old message (when using the -m/-F/-C/-c
options). However, when no options are given (meaning the notes are created
from scratch in the editor) it is not very user-friendly to abort on existing
notes, and forcing the user to run "git notes edit".
Instead, it is better to simply "redirect" to "git notes edit" automatically,
i.e. open the existing notes in the editor and let the user edit them.
This patch does just that.
This changes the behavior of "git notes add" without options when notes
already exist for the given object, but I doubt that many users really depend
on the previous failure from "git notes add" in this case.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is useful for other commands besides "git
notes" which want to let users refer to notes by their
shorthand name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/maint-fetch-pack-stop-early:
enable "no-done" extension only when fetching over smart-http
* sp/maint-upload-pack-stop-early:
enable "no-done" extension only when serving over smart-http
Last night I had to make these two emergency reverts, but now we have a
better understanding of which part of the topic was broken, let's get rid
of the revert to fix it correctly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fetch-pack/upload-pack protocol relies on the underlying transport
(local pipe or TCP socket) to have enough slack to allow one window worth
of data in flight without blocking the writer. Traditionally we always
relied on being able to have two windows of 32 "have"s in flight (roughly
3k bytes) to stream.
The recent "progressive-stride" change allows "fetch-pack" to send up to
1024 "have"s without reading any response from "upload-pack". The
outgoing pipe of "upload-pack" can be clogged with many ACK and NAK that
are unread, while "fetch-pack" is still stuffing its outgoing pipe with
more "have"s, leading to a deadlock.
Revert the change unless we are in stateless rpc (aka smart-http) mode, as
using a large window full of "have"s is still a good way to help reduce
the number of back-and-forth, and there is no buffering issue there (it is
strictly "ping-pong" without an overlap).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'no-done' protocol extension is used, the upload-pack (i.e. the
server side) process stops listening to the fetch-pack after issuing the
final NAK, and starts sending the generated pack data back, but there may
be more "have" send by the latter in flight that the fetch-pack is
expecting to be responded with ACK/NAK. This will typically result in a
deadlock (both will block on write that the other end never reads) or
SIGPIPE on the fetch-pack end (upload-pack will finish writing a small
pack and goes away).
Disable it unless fetch-pack is running under smart-http, where there is
no such streaming issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
This is a synonym for the existing '-n' option, matching GNU grep.
Signed-off-by: Joe Ratterman <jratt0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/rev-list-n-parents:
tests: avoid nonportable {foo,bar} glob
rev-list --min-parents,--max-parents: doc, test and completion
revision.c: introduce --min-parents and --max-parents options
t6009: use test_commit() from test-lib.sh
* jc/fetch-progressive-stride:
fetch-pack: use smaller handshake window for initial request
fetch-pack: progressively use larger handshake windows
fetch-pack: factor out hardcoded handshake window size
Conflicts:
builtin/fetch-pack.c
When we merge into an unborn branch, there are basically two
steps:
1. Write the sha1 of the new commit into the ref pointed
to by HEAD.
2. Update the index with the new content, and check it out
to the working tree.
We currently do them in this order. However, (2) is the step
that is much more likely to fail, since it can be blocked by
things like untracked working tree files. When it does, the
merge fails and we are left with an empty index but an
updated HEAD.
This patch switches the order, so that a failure in updating
the index leaves us unchanged. Of course, a failure in
updating the ref now leaves us with an updated index and
mis-matched HEAD. That is arguably not much better, but it
is probably less likely to actually happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t_e_i() can return -1 or 2 to early shortcut a search. Current code
may use up to two variables to handle it. One for saving return value
from t_e_i temporarily, one for saving return code 2.
The second variable is not needed. If we make sure the first variable
does not change until the next t_e_i() call, then we can do something
like this:
int ret = 0;
while (...) {
if (ret != 2) {
ret = t_e_i();
if (ret < 0) /* no longer interesting */
break;
if (ret == 0) /* skip this round */
continue;
}
/* ret > 0, interesting */
}
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch changes behavior of the two functions. Previously it does
prefix matching only. Now it can also do wildcard matching.
All callers are updated. Some gain wildcard matching (archive,
checkout), others reset pathspec_item.has_wildcard to retain old
behavior (ls-files, ls-tree as they are plumbing).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git merge" without specifying any commit is a no-op by default.
A new option merge.defaultupstream can be set to true to cause such an
invocation of the command to merge the upstream branches configured for
the current branch by using their last observed values stored in their
remote tracking branches.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to be very casual in terminology and used <branch>, <ref> and
<rev> more or less interchangeably with <commit>. Match the help text
given by "git merge -h" with that of the documentation.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce --min-parents and --max-parents options which limit the
revisions to those commits which have at least (or at most) that many
commits, where negative arguments for --max-parents= denote infinity
(i.e. no upper limit).
In particular:
--max-parents=1 is the same as --no-merges;
--min-parents=2 is the same as --merges;
--max-parents=0 shows only roots; and
--min-parents=3 shows only octopus merges
Using --min-parents=n and --max-parents=m with n>m gives you what you ask
for (i.e. nothing) for obvious reasons, just like when you give --merges
(show only merge commits) and --no-merges (show only non-merge commits) at
the same time.
Also, introduce --no-min-parents and --no-max-parents to do the obvious
thing for convenience.
We compute the number of parents only when we limit by that, so there
is no performance impact when there are no limiters.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/rev-list-one-side-only:
git-log: put space after commit mark
t6007: test rev-list --cherry
log --cherry: a synonym
rev-list: documentation and test for --cherry-mark
revision.c: introduce --cherry-mark
rev-list/log: factor out revision mark generation
rev-list: --left/right-only are mutually exclusive
rev-list: documentation and test for --left/right-only
t6007: Make sure we test --cherry-pick
revlist.c: introduce --left/right-only for unsymmetric picking
* jn/test-sanitize-git-env:
tests: scrub environment of GIT_* variables
config: drop support for GIT_CONFIG_NOGLOBAL
gitattributes: drop support for GIT_ATTR_NOGLOBAL
tests: suppress system gitattributes
tests: stop worrying about obsolete environment variables
* jc/maint-fetch-alt:
fetch-pack: objects in our alternates are available to us
refs_from_alternate: helper to use refs from alternates
Conflicts:
builtin/receive-pack.c
When there are too many paths in the project, the number of rename source
candidates "git diff -C -C" finds will exceed the rename detection limit,
and no inexact rename detection is performed. We however could fall back
to "git diff -C" if the number of modified paths is sufficiently small.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The return value from builtin_diff_files() is fed to diff_result_code()
by the caller, and all other callees like builtin_diff_index() do not
have their own call to diff_result_code(). Remove the duplicated one
from builtin_diff_files() and let the caller handle it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix warnings from 'make check'.
- These files don't include 'builtin.h' causing sparse to complain that
cmd_* isn't declared:
builtin/clone.c:364, builtin/fetch-pack.c:797,
builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
builtin/merge-index.c:69, builtin/merge-recursive.c:22
builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
builtin/notes.c:822, builtin/pack-redundant.c:596,
builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
builtin/remote.c:1512, builtin/remote-ext.c:240,
builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
builtin/unpack-file.c:25, builtin/var.c:75
- These files have symbols which should be marked static since they're
only file scope:
submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48
- These files redeclare symbols to be different types:
builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
usage.c:49, usage.c:58, usage.c:63, usage.c:72
- These files use a literal integer 0 when they really should use a NULL
pointer:
daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362
While we're in the area, clean up some unused #includes in builtin files
(mostly exec_cmd.h).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we had to refresh the index internally before running diff or status,
we opportunistically updated the $GIT_INDEX_FILE so that later invocation
of git can use the lstat(2) we already did in this invocation.
Make them share a helper function to do so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Start the initial request small by halving the INITIAL_FLUSH (we will try
to stay one window ahead of the server, so we would end up giving twice as
many "have" in flight at the very beginning). We may want to tweak these
values even more, taking MTU into account.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn Pearce <spearce@spearce.org>
The client has to dig the history deeper when more recent parts of its
history do not have any overlap with the server it is fetching from. Make
the handshake window exponentially larger as we dig deeper, with a
reasonable upper cap.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn Pearce <spearce@spearce.org>
The "git fetch" client presents the most recent 32 commits it has to the
server and gives a chance to the server to say "ok, we heard enough", and
continues reporting what it has in chunks of 32 commits, digging its
history down to older commits.
Move the hardcoded size of the handshake window outside the code, so that
we can tweak it more easily.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn Pearce <spearce@spearce.org>
When orphaning a commit on a detached HEAD, the warning
currently looks like:
Warning: you are leaving 3 commits behind, not connected to
any of your branches:
- commit subject 1
- commit subject 2
- commit subject 3
If you want to keep them by creating a new branch, this
may be a good time to do so with:
git branch new_branch_name 933a615ab0bc566dcfd8c01ec8af159f770d3fe5
Instead of using the "-" list, let's provide a more
traditional oneline format, with the abbreviated sha1 before
each subject. Users are accustomed to seeing commits in this
format, and having the sha1 of each commit can be useful if
you want to cherry-pick instead of creating a new branch.
The new format looks like:
Warning: you are leaving 3 commits behind, not connected to
any of your branches:
933a615 commit subject 1
824fcde commit subject 2
fa49b1a commit subject 3
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When leaving a detached HEAD, we do a revision walk to make
sure the commit we are leaving isn't being orphaned.
However, this leaves crufty marks in the commit objects
which can confuse later walkers, like the one in
stat_tracking_info.
Let's clean up after ourselves to prevent this conflict.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* uk/ls-remote-in-get-remote-url:
git-request-pull: open-code the only invocation of get_remote_url
get_remote_url(): use the same data source as ls-remote to get remote urls
* jk/trace-sifter:
trace: give repo_setup trace its own key
add packet tracing debug code
trace: add trace_strbuf
trace: factor out "do we want to trace" logic
trace: refactor to support multiple env variables
trace: add trace_vprintf
--separate-git-dir tells git to create git dir at the specified
location, instead of where it is supposed to be. A .git file that
points to that location will be put in place so that it appears normal
to repo discovery process.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the well-know convention of reading standard input instead of a
named file if "-" (dash) is specified. GNU grep does the same.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the helper function split from the receiving end of "git push" to
allow the same optimization on the receiving end of "git fetch".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
The receiving end of "git push" advertises the objects that the repository
itself does not use, but are at the tips of refs in other repositories
whose object databases are used as alternates for it. This helps it avoid
having to receive (and the pusher having to send) objects that are already
available to the receiving repository via the alternates mechanism.
Tweak the helper function that implements this feature, and move it to
transport.[ch] for future reuse by other programs.
The additional test demonstrates how this optimization is helping "git push",
and "git fetch" is ignorant about it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Rename the make_*_path functions so it's clearer what they do, in
particlar make clear what the differnce between make_absolute_path and
make_nonrelative_path is by renaming them real_path and absolute_path
respectively. make_relative_path has an understandable name and is
renamed to relative_path to maintain the name convention.
The function calls have been replaced 1-to-1 in their usage.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.0-rc0~34 (make "mktag" a built-in, 2010-01-22), git mktag
uses the C99-style %td format to print ptrdiff_t values. It falls
back to %d when NO_C99_FORMAT is set, on the assumption that pre-C99
systems probably are using 32-bit pointers.
But many modern systems are 64-bit and
* sometimes one wants to test the NO_C99_FORMAT fallbacks using a
modern development platform;
* some platforms (I'm looking at you, msvc) have not gotten with the
program and are still C89-only.
These ptrdiff_t values are offsets from the beginning of a buffer, so
a size_t or uintmax_t would work about as well. Use the latter so we
can take advantage of the PRIuMAX fallback in git-compat-util.h, even
on C99-challenged systems with 64-bit pointers.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare draft release notes to 1.7.4.2
gitweb: highlight: replace tabs with spaces
make_absolute_path: return the input path if it points to our buffer
valgrind: ignore SSE-based strlen invalid reads
diff --submodule: split into bite-sized pieces
cherry: split off function to print output lines
branch: split off function that writes tracking info and commit subject
standardize brace placement in struct definitions
compat: make gcc bswap an inline function
enums: omit trailing comma for portability
Conflicts:
RelNotes
* lt/rename-no-extra-copy-detection:
diffcore-rename: improve estimate_similarity() heuristics
diffcore-rename: properly honor the difference between -M and -C
for_each_hash: allow passing a 'void *data' pointer to callback
* mg/placeholders-are-lowercase:
Make <identifier> lowercase in Documentation
Make <identifier> lowercase as per CodingGuidelines
Make <identifier> lowercase as per CodingGuidelines
Make <identifier> lowercase as per CodingGuidelines
CodingGuidelines: downcase placeholders in usage messages
Readers uninterested in the details of "git cherry"'s output format
can see
print_commit('-', commit, verbose, abbrev);
and ignore the details.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a add_verbose_info function that takes care of adding
- an abbreviated object name;
- a summary of the form [ahead x, behind y] of the relationship
to the corresponding upstream branch;
- a one line commit subject
for the tip commit of a branch, for use in "git branch -v" output.
No functional change intended. This just unindents the code a little
and makes it easier to skip on first reading.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a struct definitions, unlike functions, the prevailing style is for
the opening brace to go on the same line as the struct name, like so:
struct foo {
int bar;
char *baz;
};
Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many
matches as 'struct [a-z_]*$'.
Linus sayeth:
Heretic people all over the world have claimed that this inconsistency
is ... well ... inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that test-lib sets $HOME to protect against pollution from user
settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test
suite any more. And as luck would have it, a quick code search
reveals no other users in the wild.
This patch does not affect GIT_CONFIG_NOSYSTEM, which is still
needed.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If enabled on the connection "multi_ack_detailed no-done" as a
pair allows the remote upload-pack process to send a PACK down
to the client as soon as a "ACK %s ready" message was also sent.
Over git:// and ssh:// where a bi-directional stream is in place
this has very little difference over the classical version that
waits for the client to send a "done\n" line by itself. It does
slightly reduce the latency involved to start the pack stream as
there is one less round-trip from client->server required.
Over smart HTTP this avoids needing to send a final RPC that has
all of the prior common objects. Instead the server is able to
return a pack as soon as its ready to. For many common users the
smart HTTP fetch is now just 2 requests: GET .../info/refs, and
a POST .../git-upload-pack to not only negotiate but also receive
the pack stream. Only users who have more than 32 local unshared
commits with the remote will need additional requests to negotiate
a common merge base.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If multi_ack_detailed was selected in the protocol capabilities
(both client and server are >= Git 1.6.6) the upload-pack side will
send "ACK %s ready" when it knows how to safely cut the graph and
produce a reasonable pack for the want list that was already sent
on the connection.
Upon receiving "ACK %s ready" there is no point in looking at
the remaining commits inside of rev_list. Sending additional
"have %s" lines to the remote will not construct a smaller pack.
It is unlikely a commit older than the current cut point will have
a better delta base than the cut point itself has.
The original design of this code had fetch-pack empty rev_list by
marking a commit and its transitive ancestors COMMON whenever the
remote side said "ACK %s {continue,common}" and skipping over any
already COMMON commits during get_rev(). This approach does not
work when most of rev_list is actually COMMON_REF, commits that
are pointed to by a reference on the remote, which exist locally,
and which have not yet been sent to the remote as a "have %s" line.
Most of the common references are tags in the ref/tags namespace,
using points in the commit graph that are more than 1 commit apart.
In git.git itself, this is currently 340 tags, 339 of which point to
commits in the commit graph. fetch-pack pushes all of these into
rev_list, but is unable to mark them COMMON and discard during a
remote's "ACK %s {continue,common}" because it does not parse through
the entire parent chain. Not parsing the entire parent chain is
an optimization to avoid walking back to the roots of the repository.
Assuming the client is only following the remote (and does not make
its own local commits), the client needs 11 rounds to spin through
the entire list of tags (32 commits per round, ceil(339/32) == 11).
Unfortunately the server knows on the first "have %s" line that
it can produce a good pack, and does not need to see the remaining
320 tags in the other 10 rounds.
Over git:// and ssh:// this isn't as bad as it sounds, the client is
only transmitting an extra 16,000 bytes that it doesn't need to send.
Over smart HTTP, the client must do an additional 10 HTTP POST
requests, each of which incurs round-trip latency, and must upload
the entire state vector of all known common objects. On the final
POST request, this is 16 KiB worth of data.
Fix all of this by clearing rev_list as soon as the remote side
says it can construct a pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of 7 comes from fairly early in git development, when
seven hex digits was a lot (it covers about 250+ million hash
values). Back then I thought that 65k revisions was a lot (it was what
we were about to hit in BK), and each revision tends to be about 5-10
new objects or so, so a million objects was a big number.
These days, the kernel isn't even the largest git project, and even
the kernel has about 220k revisions (_much_ bigger than the BK tree
ever was) and we are approaching two million objects. At that point,
seven hex digits is still unique for a lot of them, but when we're
talking about just two orders of magnitude difference between number
of objects and the hash size, there _will_ be collisions in truncated
hash values. It's no longer even close to unrealistic - it happens all
the time.
We should both increase the default abbrev that was unrealistically
small, _and_ add a way for people to set their own default per-project
in the git config file.
This is the first step to first make it configurable; the default of 7
is not raised yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split up the "could not %s %s... %s" message into "could not revert
%s... %s" and "could not apply %s... %s". This makes it easier for
translators to understand the message.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate messages that use the `me' variable. These are all error
messages referencing the command name, so the name shouldn't be
translated.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate the "Your local changes [...]" message without using the
`me' variable, instead split up the two messages so translators can
translate the whole messages as-is.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use sprintf format for the error message that's displayed if
GIT_NOTES_REWRITE_MODE is invalid, and leave a note in a TRANSLATORS
comment indicating what the message means.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split up the "Auto packing the repository" message into quiet and
verbose variants to make translation easier.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split up the "clean.requireForce set/defaults to true..." die()
message to make it easier to translate.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "To prevent you from losing history" message. A test in
lib-httpd.sh and another in t5541-http-push.sh explicitly checked for
this message. Change them to skip under GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark the tag_template message as translatable with N_() and then use
it later with _(). We need to skip a test under GETTEXT_POISON that
relies on the output having a leading newline.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the ""Unstaged changes after reset:" message. A test in
t7102-reset.sh explicitly checked for this message. Change it to skip
under GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the messages in git-reset that use the reset_type_names static
array to be translatable by marking the array items with N_() and
using _() later.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
