config.c: Fix a static buffer overwrite bug by avoiding mkpath()
On cygwin, test number 21 of t3200-branch.sh (git branch -m q q2
without config should succeed) fails. The failure involves the
functions from path.c which parcel out internal static buffers
from the git_path() and mkpath() functions.
In particular, the rename_ref() function calls safe_create_leading\
_directories() with a filename returned by git_path("logs/%s", ref).
safe_create_leading_directories(), in turn, calls stat() on each
element of the path it is given. On cygwin, this leads to a call
to git_config() for each component of the path, since this test
explicitly removes the config file. git_config() calls mkpath(), so
on the fourth component of the path, the original buffer passed
into the function is overwritten with the config filename.
Note that this bug is specific to cygwin and it's schizophrenic
stat() functions (see commits adbc0b6, 7faee6b and 7974843). The
lack of a config file and a path with at least four elements is
also important to trigger the bug.
In order to fix the problem, we replace the call to mkpath() with
a call to mksnpath() and provide our own buffer.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, the url passed to git-clone has an extra '/' given
after the 'file://' schema prefix, thus:
git clone --reference=original "file:///$(pwd)/original one
Once the prefix is removed, the remainder of the url looks something
like "//home/ramsay/git/t/...", which is then interpreted as an
network path. This then results in a "Permission denied" error, like
so:
ramsay $ ls //home
ls: cannot access //home: No such host or network path
ramsay $ ls //home/ramsay
ls: cannot access //home/ramsay: Permission denied
ramsay $
In order to fix the problem, we simply remove the extraneous '/'
character from the url.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rr/misc-fixes:
git-compat-util: don't assume value for undefined variable
sha1_file: don't mix enum with int
convert: don't mix enum with int
http: remove unused function hex()
refresh_index: make porcelain output more specific
If you have a deleted file and a porcelain refreshes the
cache, we print:
Unstaged changes after reset:
M file
This is technically correct, in that the file is modified,
but it's friendlier to the user if we further differentiate
the case of a deleted file (especially because this output
looks a lot like "diff --name-status", which would also make
the distinction).
Similarly, we can distinguish typechanges ("T") and
intent-to-add files ("A"), both of which appear as just "M"
in the current output.
The plumbing output for all cases remains "needs update" for
historical compatibility.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When refreshing the index, for modified (or unmerged) files we will print
"needs update" (or "needs merge") for plumbing, or line similar to the
output from "diff --name-status" for porcelain.
The variables holding which type of message to show are named after the
plumbing messages. However, as we begin to differentiate more cases at the
porcelain level (with the plumbing message staying the same), that naming
scheme will become awkward.
Instead, name the variables after which case we found (modified or
unmerged), not what we will output.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: add option to disable automatic dependency generation
Now that the COMPUTE_HEADER_DEPENDENCIES feature is turned on
automatically for compilers that support it (see v1.7.8-rc0~142^2~1,
2011-08-18), there is no easy way to force it off. For example,
setting COMPUTE_HEADER_DEPENDENCIES to the empty string in config.mak
just tells the makefile to treat it as undefined and run a test
command to see if the -MMD option is supported.
So allow setting COMPUTE_HEADER_DEPENDENCIES=no to explicitly force
the feature off. The new semantics:
- "yes" means to explicitly enable the feature
- "no" means to disable it
- "auto" means to autodetect
The default is still "auto". Any value other than these three will
cause the build to error out with a descriptive message so typos and
stale settings in config.mak don't result in mysterious behavior.
Makefile:1278: *** please set COMPUTE_HEADER_DEPENDENCIES to
yes, no, or auto (not "1"). Stop.
So now when someone using a compiler without -MMD support reports
trouble building git, you can reproduce it by running "make
COMPUTE_HEADER_DEPENDENCIES=no".
Suggested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the streaming filter API was introduced in v1.7.7-rc0~60^2~7
(2011-05-20), we forgot to add its header to LIB_H. Most translation
units depend on streaming.h via cache.h.
v1.7.5-rc0~48 (Fix sparse warnings, 2011-03-22) introduced undeclared
dependencies by url.o on url.h and thread-utils.o on thread-utils.h.
Noticed by make CHECK_HEADER_DEPENDENCIES=1.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The macro is variadic, which breaks support for pre-C99 compilers,
and it hides an "if", which can make code hard to understand on
first reading if some arguments have side-effects.
The OUTPUT macro seems to have been inspired by the "output" function
from merge-recursive. But that function in merge-recursive exists to
indent output based on the level of recursion and there is no similar
justification for such a function in "notes merge".
Noticed with 'make CC="gcc -std=c89 -pedantic"':
notes-merge.c:24:22: warning: anonymous variadic macros were introduced in C99 [-Wvariadic-macros]
Encouraged-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
do not let git_path clobber errno when reporting errors
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>
pack-object: tolerate broken packs that have duplicated objects
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.
receive-pack, fetch-pack: reject bogus pack that records objects twice
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.
The add_extra_ref() interface is used to add an extra-ref that is _not_
our ref for the purpose of helping auto-following of tags and reducing
object transfer from remote repository, and they are typically formatted
as a tagname followed by ^{} to make sure no valid refs match that
pattern. In other words, these entries are deliberately formatted not to
pass check-refname-format test.
A recent series however added a test unconditionally to the add_ref()
function that is called from add_extra_ref(). The check may be sensible
for other two callsites of the add_ref() interface, but definitely is
a wrong thing to do in add_extra_ref(). Disable it.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Michael Haggerty <mhagger@alum.mit.edu>
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>
git-compat-util: don't assume value for undefined variable
Suggested-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev --all: do not even attempt to describe non-commit object
This even dates back to the very beginning of "git name-rev";
it does not make much sense to dump all objects in the repository
and label non-commits as "undefined".
Convert many resolve_ref() calls to read_ref*() and ref_exists()
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>
* commit '633e3556ccbc': (5835 commits)
build-in git-mktree
allow -t abbreviation for --track in git branch
gitweb: Remove function prototypes (cleanup)
Documentation: cloning to empty directory is allowed
Clarify kind of conflict in merge-one-file helper
git config: clarify --add and --get-color
archive-tar.c: squelch a type mismatch warning
Start 1.6.4 development
Start 1.6.3.1 maintenance series.
GIT 1.6.3
t4029: use sh instead of bash
t4200: convert sed expression which operates on non-text file to perl
t4200: remove two unnecessary lines
t/annotate-tests.sh: avoid passing a non-newline terminated file to sed
t4118: avoid sed invocation on file without terminating newline
t4118: add missing '&&'
t8005: use egrep when extended regular expressions are required
git-clean doc: the command only affects paths under $(cwd)
improve error message in config.c
t4018-diff-funcname: add cpp xfuncname pattern to syntax test
...
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.
commit: teach --amend to carry forward extra headers
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.
merge: force edit and no-ff mode when merging a tag object
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.
commit: copy merged signed tags to headers of merge commit
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.
completion: don't leak variable from the prompt into environment
Commit e5b8eebc (completion: fix issue with process substitution not
working on Git for Windows, 2011-10-26) introduced a new variable in
__git_ps1_show_upstream(), but didn't declare it as local to prevent it
from leaking into the environment.
We may want to rewrite it like the following, but that can wait until the
next cycle.
while read key value
do
...
done <<-EOF
$(git config -z --get-regexp ...)
EOF
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The integrator tool will start allowing to pull a signed or an annotated
tag, i.e.
$ git pull $there tags/for-linus
and the description in the tag is used to convey a meaningful message from
the lieutenant to the integrator to justify the history being pulled.
Include the message in the pull request e-mail, as the same information is
useful in this context, too. It would encourage the lieutenants to write
meaningful messages in their signed tags.
* 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
merge: record tag objects without peeling in MERGE_HEAD
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.
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.
fmt-merge-msg: Add contents of merged tag in the merge message
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.
The current progress code really just counts commits.
This patch makes it count all objects, giving us a "total"
count close to what a repack would show. This is nice when
using "git gc", which will usually have just repacked the
whole repo.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
prune: show progress while marking reachable objects
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>
blame.c: Properly initialize strbuf after calling textconv_object(), again
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.
refs DWIMmery: use the same rule for both "git fetch" and others
"git log frotz" can DWIM to "refs/remotes/frotz/HEAD", but in the remote
access context, "git fetch frotz" to fetch what the other side happened to
have fetched from what it calls 'frotz' (which may not have any relation
to what we consider is 'frotz') the last time would not make much sense,
so the fetch rules table did not include "refs/remotes/%.*s/HEAD".
When the user really wants to, "git fetch $there remotes/frotz/HEAD" would
let her do so anyway, so this is not about safety or security; it merely
is about confusion avoidance and discouraging meaningless usage.
Specifically, it is _not_ about ambiguity avoidance. A name that would
become ambiguous if we use the same rules table for both fetch and local
rev-parse would be ambiguous locally at the remote side.
So for the same reason as we added rule to allow "git fetch $there v1.0"
instead of "git fetch $there tags/v1.0" in the previous commit, here is a
bit longer rope for the users, which incidentally simplifies our code.
merge: notice local merging of tags and keep it unwrapped
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.
pull: introduce a pull.rebase option to enable --rebase
Currently we either need to set branch.<name>.rebase for existing
branches if we'd like "git pull" to mean "git pull --rebase", or have
the forethought of setting "branch.autosetuprebase" before we create
the branch.
Introduce a "pull.rebase" option to globally configure "git pull" to
mean "git pull --rebase" for any branch.
This option will be considered at a lower priority than
branch.<name>.rebase, i.e. we could set pull.rebase=true and
branch.<name>.rebase=false and the latter configuration option would
win.
Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com> Reviewed-by: Fernando Vezzosi <buccia@repnz.net> Reviewed-by: Eric Herman <eric@freesa.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.
verify_packfile(): check as many object as possible in a pack
verify_packfile() checks for whole pack integerity first, then each
object individually. Once we get past whole pack check, we can
identify all objects in the pack. If there's an error with one object,
we should continue to check the next objects to salvage as many
objects as possible instead of stopping the process.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
cast variable in call to free() in builtin/diff.c and submodule.c
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>
Change a i18n-specific comparison in t/t7508-status.sh to use
test_i18ncmp instead. This was introduced in v1.7.6.3~11^2 and has
been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change a i18n-specific grep in t/t6030-bisect-porcelain.sh to use
test_i18ngrep instead. This was introduced in v1.7.7.2~5^2~11 and has
been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support sizes >=2G in various config options accepting 'g' sizes.
The config options core.packedGitWindowSize, core.packedGitLimit,
core.deltaBaseCacheLimit, core.bigFileThreshold, pack.windowMemory and
pack.packSizeLimit all claim to support suffixes up to and including
'g'. This implies that they should accept sizes >=2G on 64-bit
systems: certainly, specifying a size of 3g should not silently be
translated to zero or transformed into a large negative value due to
integer overflow. However, due to use of git_config_int() rather than
git_config_ulong(), that is exactly what happens:
% git config core.bigFileThreshold 2g
% git gc --aggressive # with extra debugging code to print out
# core.bigfilethreshold after parsing
bigfilethreshold: -2147483648
[...]
This is probably irrelevant for core.deltaBaseCacheLimit, but is
problematic for the other values. (It is particularly problematic for
core.packedGitLimit, which can't even be set to its default value in
the config file due to this bug.)
This fixes things for 32-bit platforms as well. They get the usual bad
config error if an overlarge value is specified, e.g.:
fatal: bad config value for 'core.bigfilethreshold' in /home/nix/.gitconfig
This is detected in all cases, even if the 32-bit platform has no size
larger than 'long'. For signed integral configuration values, we also
detect the case where the value is too large for the signed type but
not the unsigned type.
Signed-off-by: Nick Alcock <nix@esperi.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: do not store peeled tag object names in FETCH_HEAD
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]
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".
This is a FILE pointer in the case that we are sending our
output to a file. We originally used it to run ftell() to
determine whether data had been written to our file during
our last call to curl. However, as of the last patch, we no
longer care about that flag anymore. All uses of this struct
member are now just book-keeping that can go away.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c: Rely on select instead of tracking whether data was received
Since now select is used with the file descriptors of the http connections,
tracking whether data was received recently (and trying to read more in
that case) is no longer necessary. Instead, always call select and rely on
it to return as soon as new data can be read.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c: Use timeout suggested by curl instead of fixed 50ms timeout
Recent versions of curl can suggest a period of time the library user
should sleep and try again, when curl is blocked on reading or writing
(or connecting). Use this timeout instead of always sleeping for 50ms.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de> Helped-by: Daniel Stenberg <daniel@haxx.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
Instead of sleeping unconditionally for a 50ms, when no data can be read
from the http connection(s), use curl_multi_fdset() to obtain the actual
file descriptors of the open connections and use them in the select call.
This way, the 50ms sleep is interrupted when new data arrives.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de> Helped-by: Daniel Stenberg <daniel@haxx.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a username is already specified at the beginning of any HTTP
transaction (e.g. "git push https://user@hosting.example.com/project.git"
or "git ls-remote https://user@hosting.example.com/project.git"), the code
interactively asks for a password before calling into the libcurl library.
It is very likely that the reason why user included the username in the
URL is because the user knows that it would require authentication to
access the resource. Asking for the password upfront would save one
roundtrip to get a 401 response, getting the password and then retrying
the request. This is a reasonable optimization.
HOWEVER.
This is done even when $HOME/.netrc might have a corresponding entry to
access the site, or the site does not require authentication to access the
resource after all. But neither condition can be determined until we call
into libcurl library (we do not read and parse $HOME/.netrc ourselves). In
these cases, the user is forced to respond to the password prompt, only to
give a password that is not used in the HTTP transaction. If the password
is in $HOME/.netrc, an empty input would later let the libcurl layer to
pick up the password from there, and if the resource does not require
authentication, any input would be taken and then discarded without
getting used. It is wasteful to ask this unused information to the end
user.
Reduce the confusion by not trying to optimize for this case and always
incur roundtrip penalty. An alternative might be to document this and keep
this round-trip optimization as-is.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com> Helped-by: Jeff King <peff@peff.net> 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>
Since systems that omit strtoumax() will likely omit strtomax() too, and
likewise for strtoull() and strtoll(), we arrange for the make variables
NO_STRTOUMAX and NO_STRTOULL to cover both the signed and unsigned
functions, and define compatibility implementations for them.
Signed-off-by: Nick Alcock <nix@esperi.org.uk> 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>