The program can decide at runtime not to use threading even if the support
is compiled in. In such a case, mutexes are not necessary and left
uninitialized. But the code incorrectly tried to take and release the
read_sha1_mutex unconditionally.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Fredrik Kuivinen <frekui@gmail.com>
* maint-1.6.6:
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
transport_get_remote_refs() in tranport.c checks transport->remote_refs
to determine whether transport->get_refs_list() should be invoked. The
logic is "if it is NULL, we haven't run ls-remote to find out yet".
However, transport->remote_refs could still be NULL while cloning from
an empty repository. This causes get_refs_list() to be run unnecessarily.
Introduce a flag, transport->got_remote_refs, to more explicitly record
if we have run transport->get_refs_list() already.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we encounter a symref that is dangling, in most cases we will warn
about it. The one exception is a dangling HEAD, as that indicates a
branch yet to be born.
However, the check in dwim_ref was not quite right. If we were fed
something like "HEAD^0" we would try to resolve "HEAD", see that it is
dangling, and then check whether the _original_ string we got was
"HEAD" (which it wasn't in this case). And that makes no sense; the
dangling thing we found was not "HEAD^0" but rather "HEAD".
Fixing this squelches a scary warning from "submodule summary HEAD" (and
consequently "git status" with status.submodulesummary set) in an empty
repo, as the submodule script calls "git rev-parse -q --verify HEAD^0".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git stash pop' option parsing used to remove the first argument
in --index mode. At the time this was implemented, this first
argument was always --index. However, since the invention of the -q
option in fcdd0e9 (stash: teach quiet option, 2009-06-17) you can
cause an internal invocation of
git stash drop --index
by running
git stash pop -q --index
which then of course fails because drop doesn't know --index.
To handle this, instead let 'git stash apply' decide what the future
argument to 'drop' should be.
Warning: this means that 'git stash apply' must parse all options that
'drop' can take, and deal with them in the same way. This is
currently true for its only option -q.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not double-backslash we forbid; backslashes are forbidden since
a4c2e699 (Disallow '\' in ref names, 2009-05-08)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When storing a message over IMAP (RFC 3501 6.3.11), the message should be
in the format of an RFC 2822 message; most notably, CRLF must be used as
a line terminator.
Convert "\n" line endings in the payload to CRLF before feeding it to
IMAP APPEND command.
Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, git-archive takes attributes from the tree being archived.
People however often wonder why their attempts to affect the way how the
command archives their tree by changing .gitattributes in their work tree
fail.
Add a bit of explanatory note to tell them how to achieve what they want
to do.
Noticed-by: Francois Marier
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running filter-branch with --prune-empty and --commit-filter reports:
"Cannot set --prune-empty and --filter-commit at the same time".
Change it to use the correct option name: --commit-filter
Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's hard to see the "how to commit" part of this message,
which users may want to cut and paste. On top of that,
having it in paragraph form means that a really long commit
name may cause ugly wrapping. Let's make it prettier, like:
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:
git commit -c HEAD~23
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we have a conflict, we advise the user to do:
git commit -c $sha1
This works fine, but is unnecessarily confusing and annoying
for the user to type, when:
git commit -c $the_thing_you_called_cherry_pick_with
works just as well.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gets rid of the fixed-size buffer and an unchecked
sprintf. That sprintf is actually OK as the only
variable-sized thing put in it is an abbreviated sha1, which
is bounded at 40 characters. However, the next patch will
change that to something unbounded.
Note that this function now returns an allocated buffer
instead of a static one; however, it doesn't matter as the
only caller exits immediately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These lines are really just lookup_commit_reference
re-implemented.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current message overflows on an 80-character terminal.
While we're at it, fix the spelling of 'committing'.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rebase calls this same function "--continue", which means
users may be trained to type it. There is no reason to
deprecate --resolved (or -r), so we will keep it as a
synonym.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell reports exit status only from the most downstream command
in a pipeline. In these tests, we want to make sure that the
command fails in a controlled way, and produces a correct error
message.
This issue was known by Jay who submitted the patch, and also was
pointed out by Hannes during the review process, but I forgot to
fix it up before applying. Sorry about that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
The last item in the enumerated refname rule was mistakenly made into
a sub-item of the 7th one. It should be the 8th one in the list on its
own.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The lack of quoting made the entire line disappear.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the client has requested side-band-64k capability, send any
of the internal error or warning messages in the muxed side-band
stream using the same band as our hook output, band #2. By putting
everything in one stream we ensure all messages are processed by
the side-band demuxer, avoiding interleaving between our own stderr
and the side-band demuxer's stderr buffers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to avoid the warnings (or later, test failures) about
updating the current branch. It was never my intention to have
this test deal with a repository with a working directory, and it
is a very old bug that the test even used a non-bare repository
for the remote side of the push operations.
This fixes the interleaved output error we were seeing as a test
failure by avoiding the giant warning message we were getting back
about updating the current branch being risky.
Its not a real fix, but is something we should do no matter what,
because the behavior will change in the future to reject, and the
test would break at that time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8424981: "Fix invalid read in quote_c_style_counted" introduced a test
that used "caractère spécial" as a directory name.
Git creates it as "caract\303\250re sp\303\251cial"
OS X stores it as "caracte\314\200re spe\314\201cial"
To work around this problem, use the already introduced $FN as the
directory name.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
blame: prevent a segv when -L given start > EOF
git-push: document all the status flags used in the output
Fix parsing of imap.preformattedHTML and imap.sslverify
git-add documentation: Fix shell quoting example
blame would segv if given -L <lineno> with <lineno> past the end of the file.
While we're fixing the bug, add test cases for an invalid <start> when called
as -L <start>,<end> or -L<start>.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
