Am 16.04.2013 18:55, schrieb Ivan Lyapunov:
git version 1.8.2.1 crashes on my ArchLinux x86_64 on git log command
gdb bt is attached
git log | less
does not crash in same repo
I cannot share a repo for a debug purposes since it's private repo of
my employer
but I can perform any
First, lest I forget again: Thank you, Ivan, for the very useful
bug report!
Am 16.04.2013 21:45, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
Does this patch help?
pretty.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Am 08.04.2013 20:36, schrieb BJ Hargrave:
Git 1.8.2.1 includes commit bd54cf17 - archive: handle commits with
an empty tree
Test 2 of t5004-archive-corner-cases, tar archive of empty tree is
empty, fails on Mac OS X 10.8.3 (with XCode 4.6.1) since the tar
command exits with return code 1 on
Make it a bit clearer that --worktree-attributes is about files in the
working tree (checked out files, possibly changed) and not the current
working directory ($PDW). Link to the ATTRIBUTES section, which has
more details.
Reported-by: Amit Bakshi ambak...@gmail.com
Signed-off-by: Rene Scharfe
Am 08.04.2013 23:05, schrieb Jeff King:
On Mon, Apr 08, 2013 at 02:36:05PM -0400, BJ Hargrave wrote:
Git 1.8.2.1 includes commit bd54cf17 - archive: handle commits with an
empty tree
Test 2 of t5004-archive-corner-cases, tar archive of empty tree is
empty, fails on Mac OS X 10.8.3 (with
In addition to --summary-limit n support the form --summary-limit=n,
for consistency with other parameters and commands.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
git-submodule.sh | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
Am 24.03.2013 05:55, schrieb Junio C Hamano:
However, the same compiler still thinks {elem,path,mode}1 can be
used uninitialized (but not {elem,path,mode}2). The craziness I
reported in the previous message is also the same. With this patch
on top to swap the side we inspect first, the
Am 22.03.2013 17:21, schrieb Jeff King:
Of the 8 patches, this is the one I find the least satisfying, if only
because I do not think gcc's failure is because of complicated control
flow, and rearranging the code would only hurt readability.
Hmm, let's see if we can help the compiler follow
Am 19.03.2013 22:36, schrieb Josh Rowe:
Yes, Dedup is in fact a Server-only feature.
Is there an easier way to reproduce the issue than registering and
downloading the Windows Server 2012 evaluation version? It's not that
hard, admittedly, but still.
The reparse point could be decoded as
Am 20.03.2013 21:43, schrieb Josh Rowe:
If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd
with some deduped files. I'm not sure if that will be readable, but
I would hazard a guess that it would be. It definitely will not be
readable on Win7.
It would be nice if you could
Am 18.03.2013 22:20, schrieb Josh Rowe:
On Windows with an NTFS volume with Deduplication enabled, Git
believes that deduplicated files are symlinks. It then fails to be
able to do anything with the file. This can be repro-ed by creating
an NTFS volume with dedup, creating some duplicate
Am 17.03.2013 08:10, schrieb Junio C Hamano:
@@ -1158,16 +1159,16 @@ static void diagnose_invalid_sha1_path(const char
*prefix,
if (!get_tree_entry(tree_sha1, fullname,
sha1, mode)) {
die(Path '%s' exists, but not
Am 17.03.2013 06:40, schrieb Jeff King:
We do have the capability to roll out to one or a few of our servers
(the granularity is not 0.2%, but it is still small). I'm going to try
to keep us more in sync with upstream git, but I don't know if I will
get to the point of ever deploying master or
As a follow-up to 60d24dd25 (Makefile: fold XDIFF_H and VCSSVN_H into
LIB_H), let the unconditional additions to LIB_H form a single sorted
list. Also drop the duplicate entry for xdiff/xdiff.h, which was easy
to spot after sorting.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
The only caller of diagnose_invalid_sha1_path() extracts a substring from
an object name by creating a NUL-terminated copy of the interesting part.
Add a length parameter to the function and thus avoid the need for an
allocation, thereby simplifying the code.
Signed-off-by: Rene Scharfe
We use the function git_deflate_init() -- which wraps the zlib function
deflateInit() -- to initialize compression of ZIP file entries. This
results in compressed data prefixed with a two-bytes long header and
followed by a four-bytes trailer. ZIP file entries consist of ZIP
headers and raw
Currently ZIP archive entries of files with export-subst attribute are
broken if they are stored uncompressed.
We get the size of a file from sha1_object_info(), but this number is
likely wrong for files whose contents are changed due to export-subst
placeholder expansion. We use
Am 23.02.2013 15:31, schrieb Ville Skyttä:
Signed-off-by: Ville Skyttä ville.sky...@iki.fi
---
Documentation/RelNotes/1.7.5.4.txt | 2 +-
Documentation/RelNotes/1.7.8.txt | 2 +-
Retroactively changing release notes for older versions is not worth it,
I
Am 31.01.2013 18:28, schrieb Greg KH:
I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully). The diff of a hex dump
of the tar archives shows the following difference:
--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
Am 15.01.2013 00:36, schrieb Junio C Hamano:
It appears that memcmp() uses the usual one word at a time
comparison and triggers valgrind in a callback of bsearch() used in
the refname search. I can easily trigger problems in any script
with test_commit (e.g. sh t0101-at-syntax.sh --valgrind
Am 15.01.2013 21:27, schrieb Andreas Schwab:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
+return '\0' - ent-name[key-len];
You need to cast to unsigned char first to make it consistent with
memcmp and strcmp.
Thanks for catching this!
-- 8 --
Subject: [PATCH] refs: use strncmp
This conversion avoids the need for magic string length numbers in the
code. And unlike memcmp(), prefixcmp() is careful to not run over the
end of a string.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
pretty.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Am 10.01.2013 01:18, schrieb Junio C Hamano:
Adam Spiers g...@adamspiers.org writes:
On Wed, Jan 9, 2013 at 11:49 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Brace expansion is not required by POSIX and not supported by dash nor
NetBSD's sh. Explicitly list all combinations instead
Brace expansion is not required by POSIX and not supported by dash nor
NetBSD's sh. Explicitly list all combinations instead.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t0008-ignores.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
The test fails for me on NetBSD 6.0.1 and reports:
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
error: bug in the test
Am 08.01.2013 21:39, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t=x; a ${t:+$t}
1-x-
$ t=x y; a ${t:+$t}
2-x-y
$ t=x y; a ${t:+x y}
1-x y
Am 07.01.2013 06:16, schrieb Jonathan Nieder:
René Scharfe wrote:
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable
Am 07.01.2013 09:45, schrieb Jonathan Nieder:
René Scharfe wrote:
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
. ./test-lib.sh
GIT_UNZIP=${GIT_UNZIP:-unzip}
+test_lazy_prereq UNZIP '
+ $GIT_UNZIP -v /dev
Am 07.01.2013 09:52, schrieb Jonathan Nieder:
René Scharfe wrote:
Only add a symlink to the repository if both the filesystem and
unzip support symlinks. To check the latter, add a ZIP file
containing a symlink, created like this with InfoZIP zip 3.0:
$ echo sample text textfile
We record the uncompressed and compressed sizes and the CRC of streamed
files as zero in the local header of the file. The actual values are
recorded in an extra data descriptor after the file content, and in the
usual ZIP directory entry at the end of the archive.
While we know the compressed
Fix a bug in two scripts that call unzip, use the opportunity for a small
cleanup, move all ZIP related tests out of t5000 and finally skip testing
symlinks if unzip doesn't support them.
The first one allows running t5000 with the unzip from pkgsrc manually on
NetBSD, which succeeds. The last
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's
This change makes the code smaller and we can put it at the top of
the script, its rightful place as setup code.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t0024-crlf-archive.sh | 12 +---
t/t5000-tar-tree.sh | 12 +---
2 files changed, 10 insertions(+), 14
Only add a symlink to the repository if both the filesystem and
unzip support symlinks. To check the latter, add a ZIP file
containing a symlink, created like this with InfoZIP zip 3.0:
$ echo sample text textfile
$ ln -s textfile symlink
$ zip -y infozip-symlinks.zip
Am 24.12.2012 21:49, schrieb Junio C Hamano:
I've been running testsuite on a few platforms that are unfamiliar
to me, and was bitten by BSD implementation of tar that do not grok
the extended pax headers. I've already fixed one in t9502 [*1*]
where we produce a tarball with git archive and
Am 05.01.2013 21:11, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
Anyway, I don't think the pax headers are to blame here.
Hmph, I am reasonably sure I saw a test that created an archive from
a commit (hence with pax header), asked platform tar to either list
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
Git's isprint includes
control space characters (10-13). According to glibc-2.14.1 on C
locale on Linux, this is wrong. This patch fixes it.
isprint() is not in master, yet. Can we perhaps still introduce it in
such a way that we never have
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
Git's ispace does not include 11 and 12. [...]
According to glibc-2.14.1 on C locale on Linux, this is wrong.
11 and 12 being vertical tab (\v) and form-feed (\f). This lack goes
back to the introduction of git's own character classifier
Am 01.11.2012 03:58, schrieb Felipe Contreras:
On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote:
Johannes Schindelin johannes.schinde...@gmx.de wrote:
On Wed, 31 Oct 2012, Felipe Contreras wrote:
It doesn't get any more obvious than that. But to each his own.
In my
Am 21.10.2012 12:40, schrieb Johan Herland:
When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD'
to delete refs/heads/master), we would remove the loose ref, but a packed
version of the same ref would remain, the end result being that instead of
deleting refs/heads/master we
Am 16.10.2012 18:09, schrieb Junio C Hamano:
Having said all that, I think your patch is going in the right
direction. If somebody had a symbolic ref in refs/heads/, the
removal should remove it, not the pointee, which may not even
exist. Does branch -d sym work correctly with your patch
Move the code to perform checks on the tip commit of a branch
to its own function.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
builtin/branch.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/builtin/branch.c
Provide a small helper function for deleting branch config sections.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
builtin/branch.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 852019e..97c7361 100644
If a branch that is to be deleted happens to be a symref to another
branch, the current code removes the targeted branch instead of the
one it was called for.
Change this surprising behaviour and delete the symref branch
instead.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
Before a branch is deleted, we check that it points to a valid
commit. With -d we also check that the commit is a merged; this
check is not done with -D.
The reason for that is that commits pointed to by branches should
never go missing; if they do then something broke and it's better
to stop
git branch reports the abbreviated hash of the head commit of
a deleted branch to make it easier for a user to undo the
operation. For symref branches this doesn't help. Print the
symref target instead for them.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
builtin/branch.c | 19
Am 15.10.2012 10:50, schrieb Johan Herland:
Basically, there is a master branch, and an alias symref to
master. When we naively try to delete the symref with git branch -d
alias, it ends up:
- NOT deleting the alias symref
- DELETING the master loose ref
- NOT deleting the master
When delete_ref is called on a symref then it locks its target and then
either deletes the target or the symref, depending on whether the flag
REF_NODEREF was set in the parameter delopt.
Instead, simply pass the flag to lock_ref_sha1_basic, which will then
either lock the target or the symref,
Am 15.10.2012 20:34, schrieb Jeff King:
On Mon, Oct 15, 2012 at 07:47:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto gitter.spi...@gmail.com wrote:
Very clear analysis. Well written. Perhaps is it the time to update
http://git-scm.com/book/ch6-1.html
Am 14.10.2012 04:35, schrieb Nguyễn Thái Ngọc Duy:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
ctype.c | 18 ++
git-compat-util.h | 13 +
2 files changed, 31 insertions(+)
diff --git a/ctype.c b/ctype.c
index faeaf34..b4bf48a 100644
---
Am 14.10.2012 15:25, schrieb Nguyen Thai Ngoc Duy:
On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
With that, couldn't you squeeze the other two classes into the existing
sane_type?
No there are still conflicts: 9, 10 and 13 as spaces (vs controls) and
123
Sorry for being late. Just wanted to try out this new feature and
ended up reading this old thread.
Am 15.09.2012 01:18, schrieb Junio C Hamano:
t/perf/perf-lib.sh | 1 +
t/test-lib.sh | 26 --
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git
Hi,
I found a way to make unzip respect the UTF-8 flag in ZIP files:
Apparently (from looking at the source) an extended field needs to be
present in order for it to even look at general purpose flag 11. I sent
a patch to add an extended timestamp field that fits the bill.
Here are new
Am 18.09.2012 23:12, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
WindowsInfo-ZIP unzip
7-Zip PeaZip builtin Linux msysgit Windows
7-Zip 9.20 0 0 4626
Hello again,
so two weeks have passed, and I've moved at a glacial pace towards a
method how to measure compatibility of our generated ZIP files. Sorry,
I just keep getting distracted.
Anyway, the idea is to have a bunch of files with names using different
scripts, zip them with several
Set general purpose flag 11 if we encounter a path that contains
non-ASCII characters. We assume that all paths are given as UTF-8; no
conversion is done.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
Changes from previous version: Stop using has_non_ascii(), which does
slightly
The UTF-8 flag seems to be ignored by unzip unless we also mark the
archive entry as coming from a Unix system. This is done by setting the
field creator_version (version made by in the standard[1]) to 0x03NN.
The NN part represents the version of the standard supported by us, and
this patch
Am 09.09.2012 23:58, schrieb Marcus Karlsson:
Make git-grep optionally omit the parts of the line before and after the
match.
Signed-off-by: Marcus Karlsson m...@acc.umu.se
---
Documentation/git-grep.txt | 8 +++-
builtin/grep.c | 2 ++
grep.c | 7 +--
Am 04.09.2012 23:03, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
+ if (has_non_ascii(path)) {
Do we want to treat \033 as ascii in this codepath? The function
primarily is used by the log formatter to see if we need 8-bit CTE
when writing out in the e-mail
Am 31.08.2012 00:26, schrieb Jeff King:
Ping on this stalled discussion.
Sorry, I got distracted by other stuff again. I did some experiments,
though, and here's a preliminary result.
It seems like there are two separate issues here:
1. Knowing the encoding of pathnames in the
Am 11.08.2012 00:47, schrieb Junio C Hamano:
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
when I create a git repository, add a file containing utf-8 characters
or umlauts (like öäü.txt), commit and then export the HEAD revision to a
zip archive using git archive --format zip -o
Am 11.08.2012 01:53, schrieb Sven Strickroth:
Am 11.08.2012 00:47 schrieb Junio C Hamano:
Do you know in what encoding the pathnames are _expected_ to be
stored in zip archives?
re-encoding to latin1 does not always work and may break double byte
totally (e.g. chinese or japanese).
PKZIP
Am 28.07.2012 20:46, schrieb Ramsay Jones:
Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh.
I tried, among other things, to provoke a failure thus:
$ for i in $(seq 100); do
if ! ./t7810-grep.sh -i -v; then
break;
fi
done
$
but,
1101 - 1163 of 1163 matches
Mail list logo
