Teach "rev-parse" the same "I'm going to glob, but omit the ones
that match these patterns" feature as "rev-list".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests for the --exclude=<glob> feature.
A few tests are added for cases where use of globbing and
"--exclude" results in no positive revisions:
* "--exclude=<glob>" before "--all" etc. resulted in no results;
* "--stdin" is used but no input was given;
* "--all" etc. is used but no matching refs are found.
Currently, we fail such a request with the same error message we
would give to a command line that does not specify any positive
revision (e.g. "git rev-list<ENTER>").
We may want to treat these cases differently and not error out, but
the logic to detect that would be common to all of them, so I'd
leave it outside this topic for now, and stop at adding these tests
as food-for-thought.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it clear that "pack-file" is not to be spelled as is in the
unpack-objects usage.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/tests-windows-port-fix:
tests: undo special treatment of CRLF for Windows
Windows: a test_cmp that is agnostic to random LF <> CRLF conversions
t5300-pack-object: do not compare binary data using test_cmp
"git reset -p HEAD" has codepath to special case it from resetting
to contents of other commits, but recent change broke it.
* jk/reset-p-current-head-fix:
reset: pass real rev name to add--interactive
add-interactive: handle unborn branch in patch mode
A fast-import stream expresses a pathname with funny characters by
quoting them in C style; remote-hg remote helper forgot to unquote
such a path.
* ap/remote-hg-unquote-cquote:
remote-hg: unquote C-style paths when exporting
Moving a regular file in a repository with a .gitmodules file was
producing a warning 'Could not find section in .gitmodules where
path=<filename>'.
* jl/submodule-mv:
mv: Fix spurious warning when moving a file in presence of submodules
Add the --stuck-long option to output the options in their long form
if available, and with their arguments stuck.
Contrary to the default form (non stuck arguments and short options),
this can be parsed unambiguously when using options with optional
arguments :
- in the non stuck form, when an option is taking an optional argument
you cannot know if the next argument is its optional argument, or the
next option.
- the long options form allows to differentiate between an empty argument
'--option=' and an unset argument '--option', which is not possible
with short options.
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit 87b7b84 removed a space in the unpack-objects usage, which
makes the synopsis a bit confusing. This patch simply restores it.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise we might not have 'struct diff_options'.
[jc: needs a matching follow-up patch to remove inclusion of diff.h
from *.c files that do not themselves use anything from diff.h]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The second illustration that shows the history after "git pull"
spelled the remote-tracking branch with "remotes/" prefix, which
is not necessary. Drop it.
To match the assumption that a remote-tracking branch is used to
keep track of the advancement of the master at the origin, update
the first illustration that shows the history before "git pull"
to show the distinction between the master currently at origin and
the stale origin/master remote-tracking branch.
Noticed-by: Felipe Contreras <felipe.contreras@gmail.com>
Helped-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is what the code intended.
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The printf utility provided by coreutils when interpreting '\%o' format
does not recognize %o as formatting directive. For example
printf '\%o 0 returns \%o and warning: ignoring excess arguments,
starting with ‘0’, which results in failed tests in
t5309-pack-delta-cycles.sh. In most shells the test ends with success as
the printf is a builtin utility.
Fix it by using '\\%o' which is interpreted consistently in all versions
of printf.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to an interaction between the way libcurl handles GSSAPI
authentication over HTTP and the way git uses libcurl, large
pushes (those over http.postBuffer bytes) would fail due to
an authentication failure requiring a rewind of the curl
buffer. Such a rewind was not possible because the data did
not fit into the entire buffer.
Enable the use of the Expect: 100-continue header for large
requests where the server offers GSSAPI authentication to
avoid this issue, since the request would otherwise fail.
This allows git to get the authentication data right before
sending the pack contents. Existing cases where pushes
would succeed, including small requests using GSSAPI, still
disable the use of 100 Continue, as it causes problems for
some remote HTTP implementations (servers and proxies).
Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Jeff King <peff@peff.net>
Some callers may want to know more than just the integer
error code we return. Let them optionally pass a
slot_results struct to fill in (or NULL if they do not
care). In either case we continue to return the integer
code.
We can also give probe_rpc the same treatment (since it
builds directly on run_slot).
Signed-off-by: Jeff King <peff@peff.net>
Callers of the http code may want to know which auth types
were available for the previous request. But after finishing
with the curl slot, they are not supposed to look at the
curl handle again. We already handle returning other
information via the slot_results struct; let's add a flag to
check the available auth.
Note that older versions of curl did not support this, so we
simply return 0 (something like "-1" would be worse, as the
value is a bitflag and we might accidentally set a flag).
This is sufficient for the callers planned in this series,
who only trigger some optional behavior if particular bits
are set, and can live with a fake "no bits" answer.
Signed-off-by: Jeff King <peff@peff.net>
When a commit has many tags, the tag icons in the graph display can
easily become so wide as to push the commit message off the right-hand
edge of the graph display pane. This changes the display so that if
there are more than 3 tags or they would take up more than a quarter
of the width of the pane, we instead display a single tag icon with
a legend inside it like "4 tags...". If the user clicks on the tag
icon, gitk then displays all the tags in the diff display pane.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If we find two refspecs that want to update the same local reference,
emit an error message that is more informative based on whether one of
the conflicting refspecs is an opportunistic update during a fetch
with explicit command-line refspecs. And especially, do not die if an
opportunistic reference update conflicts with an express wish of the
user; rather, just emit a warning and skip the opportunistic reference
update.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the loop body into the more straightforward
* remove item from the front of the old list
* if necessary, add it to the tail of the new list
and return a pointer to the new list (even though it is currently
always the same as the input argument, because the first element in
the list is currently never deleted).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add some tests that "git fetch" handles refspec conflicts (i.e., when
the same local reference should be updated from two different remote
references) correctly.
There is a small bug when updating references opportunistically,
namely that an explicit user wish like
git fetch origin \
refs/heads/branch1:refs/remotes/origin/branch2 \
refs/heads/branch2:refs/remotes/origin/branch1
should override a configured refspec like
+refs/heads/*:refs/remotes/origin/*
The current code incorrectly treats this as a fatal error.
In a few commits we will improve the error messages for refspec
conflicts in general and also turn this buggy fatal error into a
warning.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code called string_list_lookup(), and if that failed called
string_list_insert(), thus doing the bisection search through the
string list twice in the latter code path.
Instead, just call string_list_insert() right away. If an entry for
that peer reference name already existed, then its util pointer is
always non-NULL.
Of course this doesn't change the fact that the repeated
string_list_insert() calls make the function scale like O(N^2) if the
input reference list is not already approximately sorted.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it clearer that tags are fetched independent of which branches
were fetched from the remote in any particular fetch. (Tags are even
fetched if they point at objects that are in the current repository
but not reachable, which is probably a bug.)
Put less emphasis on the mechanism and more on the effect of tag
auto-following. Also mention the options and configuration settings
that can change the tag-fetching behavior.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --no-prune is passed to one of the following commands:
git fetch --all
git fetch --multiple
git fetch --recurse-submodules
git remote update
then it must also be passed to the "fetch" subprocesses that those
commands use to do their work. Otherwise there might be a fetch.prune
or remote.<name>.prune configuration setting that causes pruning to
occur, contrary to the user's express wish.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use struct argv_array for calling the "git fetch" subprocesses.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder function definitions to remove the need for forward
declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
