Before objects are sent, the respective ref is locked. However,
without this patch, the lock is lifted before the last object for
that ref was sent. As a consequence, the lock data was accessed
after the lock structure was free()d.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
c1795bb (Unify whitespace checking) incorrectly made the
checking function return without incrementing the line numbers
when there is no whitespace problem is found on a '+' line.
This resurrects the earlier behaviour.
Noticed and reported by Jay Soffian. The test script was stolen
from Jay's independent fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a bug in the hg-to-git convertor introduced by commit
1bc7c13af9: when searching the changeset
parents, 'hg log' returns an extra space at the end of the line, which
confuses the .split(' ') based tokenizer:
Traceback (most recent call last):
File "hg-to-git.py", line 123, in <module>
hgchildren[mparent] += ( str(cset), )
KeyError: ''
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function is intended to be fed one logical line at a time to
inspect, but a QP encoded raw input line can have more than one
lines, just like BASE64 encoded one.
Quoting LF as =0A may be unusual but RFC2045 allows it.
The issue was noticed and fixed by Jay Soffian. JC added a test
to protect the fix from regressing later.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git_config_string" to simplify code where "cmd" is set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git_config_string" to simplify "config.c" code
where "excludes_file" is set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git_config_string" to simplify "config.c" code
where "editor_program" is set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git_config_string" to simplify "config.c" code
where "pager_program" is set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many places we just check if a value from the config file is not
NULL, then we duplicate it and return 0. This patch introduces the new
'git_config_string' function to do that.
This function is also used to refactor some code in 'config.c'.
Refactoring other files is left for other patches.
Also not all the code in "config.c" is refactored, because the function
takes a "const char **" as its first parameter, but in many places a
"char *" is used instead of a "const char *". (And C does not allow
using a "char **" instead of a "const char **" without a warning.)
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not necessary to check if value != NULL before calling
'parse_lldiff_command' as there is already a check inside this
function.
By the way this patch also improves the existing check inside
'parse_lldiff_command' by using:
return config_error_nonbool(var);
instead of:
return error("%s: lacks value", var);
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the tree object we have asked for is deltafied in the packfile and
the delta did not apply correctly or was not able to be decompressed
from the packfile then we can get back NULL instead of the tree data.
This is (part of) the reason why read_sha1_file() can return NULL, so
we need to also handle it the same way.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original problem was that the parsers for configuration files were
getting confused by seeing as nicknames remotes that involved
directory-changing characters. In particular, the branches config file
for ".." was particularly mystifying on platforms that can open
directories and read odd data from them.
The validation function was written by Junio Hamano (with a typo
corrected).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Christian Couder noticed that there still were a handcrafted error()
call that we should have converted to config_error_nonbool() where
parse_lldiff_command() parses the configuration file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests in 't1300-repo-config.sh' did not check what happens when
an empty value like the following is used in the config file:
[emptyvalue]
variable =
Also it was not checked that a variable with no value like the
following:
[novalue]
variable
gives a boolean "true" value, while an ampty value gives a boolean
"false" value.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default value of @mergerx uses \W, which matches a non-word
character; this means that commit messages like "Merging FOO" are not
matched by default; using \b, which matches a word boundary, instead of
\W fixes that.
This change was suggested by Frédéric Brière through
http://bugs.debian.org/463468
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It makes no sense to suggest "git reset HEAD" since we have
no HEAD commit. This actually used to work but regressed in
f26a0012.
wt_status_print_cached_header was updated to take the whole
wt_status struct rather than just the reference field.
Previously the various code paths were sometimes sending in
s->reference and sometimes sending in NULL, making the
decision on whether this was an initial commit before we
even got to this function. Now we must check the initial
flag here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to use "cat-file commit $commit" to extract the original
author information from existing commit, but an earlier commit
5ac2715 (Consistent message encoding while reusing log from an
existing commit) changed it to use "git show -s $commit". If
you have a file in your work tree that can be interpreted as a
valid object name (e.g. "HEAD"), this conversion will not work.
Disambiguate by marking the end of revision parameter on the
comand line with an explicit "--" to fix this.
This breakage is most visible with rebase when a file called
"HEAD" exists in the worktree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git-upload-pack has to spawn git-pack-objects, it has to make sure
that the latter can be found in the PATH. Without this patch an attempt
to clone or pull via ssh from a server fails if the git tools are not in
the standard PATH on the server even though git clone or git pull were
invoked with --upload-pack=/path/to/git-upload-pack.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to a typo, the commit subject was shell expanded in the bisect log.
That is, if you had some shell pattern in the commit subject, bisect
would happily put all matching file names into the log.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix '-M' description. Old one reads as if the user can somehow "see"
the default regex when using -M along with -m.
Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 9c2174350c.
Nico analyzed and found out that this does not really help, and
I agree with it.
By the time this gets into action and data is actively thrown
away, performance simply goes down the drain due to the data
constantly being reloaded over and over and over and over and
over and over again, to the point of virtually making no
relative progress at all. The previous behavior of enforcing
the memory limit by dynamically shrinking the window size at
least had the effect of allowing some kind of progress, even if
the end result wouldn't be optimal.
And that's the whole point behind this memory limiting feature:
allowing some progress to be made when resources are too limited
to let the repack go unbounded.
The Tk Framework moved its location in 10.5 compared to 10.4
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Tested-by: Seth Falcon <seth@userprimary.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
user.{name,email}, core.{pager,editor,excludesfile,whitespace} and
i18n.{commit,logoutput}encoding all expect string values.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.external, diff.*.command, diff.color.*, color.diff.* and
diff.*.funcname configuration variables expect a string value.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gc.reflogexpire and gc.reflogexpireunreachable configuration expect
a string value suitable for calling approxidate() with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is used to report misconfigured configuration file that does not
give any value to a non-boolean variable, e.g.
[section]
var
It is perfectly fine to say it if the section.var is a boolean (it means
true), but if a variable expects a string value it should be flagged as
a configuration error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.
We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).
While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
