Dear Johan,
Am Mittwoch, den 12.02.2014, 00:52 +0100 schrieb Johan Herland:
On Tue, Feb 11, 2014 at 6:23 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
judging from the documentation I got the impression that I can pass any
git object has to git note -C hash and it would stored as-is.
On Tue, Feb 11, 2014 at 11:59:02AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@mns.spb.ru writes:
Sorry for the confusion. Could you please do the following:
Patches should be applied over to ks/tree-diff-walk
(74aa4a18). Before applying the patches, please cherry-pick
On Wed, Feb 12, 2014 at 1:06 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
There is currently no way the git notes commands will allow you to
store the 3d7de37 commit object directly as a note. There is also
(AFAICS) no easy workaround (git fast-import
Currently git notes add -C $object will read the raw bytes from $object,
and then copy those bytes into the note object, which is hardcoded to be
of type blob. This means that if the given $object is a non-blob (e.g.
tree or commit), the raw bytes from that object is copied into a blob
object.
On Wed, Feb 12, 2014 at 9:53 AM, Joachim Breitner
m...@joachim-breitner.de wrote:
Am Mittwoch, den 12.02.2014, 00:52 +0100 schrieb Johan Herland:
You would have a notes ref refs/notes/history whose tree would
contain an entry named e1bfac434ebd3135a3784f6fc802f235098eebd0
pointing to a
Dear Johan,
thanks for the patch!
Am Mittwoch, den 12.02.2014, 11:26 +0100 schrieb Johan Herland:
Here's another way to solve your problem, which should be fairly
transparent and performant:
Whenever you want to reference history of a commit (I'm using quotes
here, because we're not
Am 12.02.2014 04:43, schrieb Duy Nguyen:
On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson robb...@gentoo.org wrote:
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
We in the chromium project have a keen interest in adding threading to
git in the pursuit of performance for
On Wed, Feb 12, 2014 at 8:27 AM, Johannes Sixt j.s...@viscovery.net wrote:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating that addressed the problem in one way or another?
(gdb)
Hi,
I installed git 1.8.5.4 from source under $HOME/bin. My system is SUSE
Linux Enterprise Server 11 SP1 (x86_64). I followed instructions and
just run make make install.
After installation I cannot clone repos from https urls, getting the
following error:
$ git clone
On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager sza...@chromium.org wrote:
We in the chromium project have a keen interest in adding threading to
git in the pursuit of performance for lengthy operations (checkout,
status, blame, ...). Our motivation comes from hitting some
performance walls
Am 2/12/2014 12:56, schrieb Erik Faye-Lund:
On Wed, Feb 12, 2014 at 8:27 AM, Johannes Sixt j.s...@viscovery.net wrote:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating that addressed
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating that addressed the problem in one way or another?
(gdb) run
Starting program:
Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating that addressed the problem in one way or
Johannes Sixt j.s...@viscovery.net writes:
Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating
On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup d...@gnu.org wrote:
Johannes Sixt j.s...@viscovery.net writes:
Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following
On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup d...@gnu.org wrote:
Johannes Sixt j.s...@viscovery.net writes:
Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup
On Wed, Feb 12, 2014 at 3:22 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup d...@gnu.org wrote:
Johannes Sixt j.s...@viscovery.net writes:
Am 2/12/2014 13:55, schrieb David
On 2014-02-11 15.57, Cameron Taggart wrote:
After requesting this as
https://github.com/msysgit/msysgit/issues/164, I was told to take it
upstream, so here I am.
I would like a text=input feature added that has the same behavior as
text=auto, except that it defaults to core.autocrlf=input
Hi,
I find that I have little clue about how to convert the following brief
test script into some test to place in t/perf:
#!/bin/sh
rm -rf /tmp/git-test
mkdir /tmp/git-test
cd /tmp/git-test
git init
LIMIT=20
yes a|head -$LIMIT data
yes b|head -$LIMIT data2
git add data data2
git commit -m
On Wed, Feb 12, 2014 at 03:49:24PM +0100, Erik Faye-Lund wrote:
It seems the author of a201c20b41a2f0725977bcb89a2a66135d776ba2
assumes __BYTE_ORDER was guaranteed to always be defined, probably
fooled by the following check:
#if !defined(__BYTE_ORDER)
# error Cannot determine endianness
Junio C Hamano gits...@pobox.com writes:
Kirill Smelkov k...@mns.spb.ru writes:
Sorry for the confusion. Could you please do the following:
Patches should be applied over to ks/tree-diff-walk
(74aa4a18). Before applying the patches, please cherry-pick
c90483d9(tree-diff: no need
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 11, 2014 at 2:11 AM, Junio C Hamano gits...@pobox.com wrote:
On Mon, Feb 10, 2014 at 10:43 AM, Junio C Hamano gits...@pobox.com wrote:
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print auto packing in
On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen pclo...@gmail.com wrote:
I have no comments about thread safety improvements (well, not yet).
If you have investigated about git performance on chromium
repositories, could you please sum it up? Threading may be an option
to improve performance, but
On Tue, Feb 11, 2014 at 7:43 PM, Duy Nguyen pclo...@gmail.com wrote:
From v1.9 shallow clone should work for all push/pull/clone... so
history depth does not matter (on the client side). As for
gentoo-x86's large worktree, using index v4 and avoid full-tree
operations (e.g. status ., not
On Wed, Feb 12, 2014 at 3:59 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager sza...@chromium.org wrote:
We are particularly concerned with the performance of msysgit, and we
have already chalked up a significant performance gain by turning on
the
On Tue, Feb 11, 2014 at 11:29 PM, Chris Packham judge.pack...@gmail.com wrote:
Hi,
On 12/02/14 14:57, Stefan Zager wrote:
From b4796d9d99c03b0b7cddd50808a41413e45f1129 Mon Sep 17 00:00:00 2001
From: Stefan Zager sza...@chromium.org
Date: Mon, 10 Feb 2014 16:55:12 -0800
Subject: [PATCH] Make
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager sza...@google.com wrote:
On Wed, Feb 12, 2014 at 3:59 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager sza...@chromium.org wrote:
We are particularly concerned with the performance of msysgit, and we
have
Stefan Zager sza...@chromium.org writes:
I'm optimistic that parallelizing the stat calls will yield a further
improvement.
It has already been mentionned in the thread, but in case you overlooked
it: did you look at core.preloadindex? It seems at least very close to
what you want.
--
On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager sza...@google.com wrote:
I don't want to steal the thunder of my coworker, who wrote the
implementation. He plans to submit it upstream soon-ish. It relies
on using the
On Wed, Feb 12, 2014 at 10:33 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Stefan Zager sza...@chromium.org writes:
I'm optimistic that parallelizing the stat calls will yield a further
improvement.
It has already been mentionned in the thread, but in case you overlooked
it: did you
On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager sza...@google.com wrote:
On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager sza...@google.com wrote:
I don't want to steal the thunder of my coworker, who wrote the
Stefan Zager sza...@chromium.org writes:
On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen pclo...@gmail.com wrote:
I have no comments about thread safety improvements (well, not yet).
If you have investigated about git performance on chromium
repositories, could you please sum it up? Threading
Stefan Zager sza...@google.com writes:
On Tue, Feb 11, 2014 at 11:29 PM, Chris Packham judge.pack...@gmail.com
wrote:
Hi,
On 12/02/14 14:57, Stefan Zager wrote:
From b4796d9d99c03b0b7cddd50808a41413e45f1129 Mon Sep 17 00:00:00 2001
From: Stefan Zager sza...@chromium.org
Date: Mon, 10 Feb
From 0a59547f3e95ddecf7606c5f259ae6177c5a104f Mon Sep 17 00:00:00 2001
From: Stefan Zager sza...@chromium.org
Date: Mon, 10 Feb 2014 16:55:12 -0800
Subject: [PATCH] Make the global packed_git variable static to sha1_file.c.
This is a first step in making the codebase thread-safe. By and
large,
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Stefan Zager sza...@chromium.org writes:
Anything on Windows that touches a lot of files is miserable due to
the usual file system slowness on Windows, and luafv.sys (the UAC file
virtualization driver) seems to make it much
Jeff King p...@peff.net writes:
Agreed, but I think the only way to know the size of those fallouts is
to try it and see who complains. I would not normally be so cavalier
with git itself, but I think for the test infrastructure, we have a
small, tech-savvy audience that can help us iterate
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really, give the above patch a try. I am taking longer to finish it
than anticipated (with a lot due to procrastination but that is,
unfortunately, a large part of my workflow), and
Stefan Zager sza...@google.com writes:
If anyone has a recommendation for a less labor-intensive way to do
this in emacs, I'd be very grateful.
This is not do this in emacs, but here is a possible approach.
You can ask git diff about what you changed, and actually apply
the change while
Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager sza...@google.com wrote:
On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager sza...@google.com wrote:
I don't want to steal the
On Wed, Feb 12, 2014 at 11:22 AM, Karsten Blees karsten.bl...@gmail.com wrote:
Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager sza...@google.com wrote:
On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund kusmab...@gmail.com
wrote:
On Wed, Feb 12, 2014
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
When the tree-walker runs into an error, it just calls
die(), and the message is always corrupt tree file.
However, we are actually covering several cases here; let's
give the user a hint about what happened.
Let's also avoid using the word corrupt, which makes it
seem like the data bit-rotted on
Stefan Zager sza...@chromium.org writes:
... I used the Very Sleepy profiler
to see where all the time was spent on Windows: 55% of the time was
spent in OpenFile, and 25% in CloseFile (both in win32).
This is somewhat interesting.
When we check things out, checkout_paths() has a list of
I'll locally fix up these style issues before commenting on the patch.
Thanks.
ERROR: space required after that ',' (ctx:VxV)
#78: FILE: builtin/count-objects.c:111:
+ struct pack_data pd = {0,0,0};
^
ERROR: space required after that ',' (ctx:VxV)
#78:
On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Zager sza...@chromium.org writes:
... I used the Very Sleepy profiler
to see where all the time was spent on Windows: 55% of the time was
spent in OpenFile, and 25% in CloseFile (both in win32).
This is
On Tue, Feb 11, 2014 at 11:29 AM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
Why would you do this? Perhaps you need more time in your day
to consume tea or coffee. Set GIT_RTT and enjoy a beverage.
So the conclusion is that it is not practical to do a
sza...@chromium.org writes:
From 0a59547f3e95ddecf7606c5f259ae6177c5a104f Mon Sep 17 00:00:00 2001
Please drop this line.
From: Stefan Zager sza...@chromium.org
Please drop this line and instead have it in your e-mail header.
Date: Mon, 10 Feb 2014 16:55:12 -0800
The date in your e-mail
On Tue, Feb 11, 2014 at 03:58:27PM -0800, Junio C Hamano wrote:
Sure. One immediate complaint is that I would probably need to do
something like this in the build automation:
if testing a branch without this patch
then
: do nothing
else
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As a workaround to make life easier for third-party tools, the
upcoming major release will be called Git 1.9.0 (not Git 1.9).
The first
On Wed, Feb 12, 2014 at 11:06:43AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Agreed, but I think the only way to know the size of those fallouts is
to try it and see who complains. I would not normally be so cavalier
with git itself, but I think for the test
Jeff King p...@peff.net writes:
test_normalize_tristate GIT_TEST_DAEMON
Heh, great minds think alike. This is what I am playing with,
without committing (because I do like your ask config if this is a
kind of various boolean 'false' representations, which I haven't
managed to add to it).
On Wed, Feb 12, 2014 at 12:27 PM, Stefan Zager sza...@chromium.org wrote:
On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Zager sza...@chromium.org writes:
Calls to write (and preparation of data to be written) will then
remain single-threaded, but it sounds
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really, give the above patch a try. I am taking longer to finish it
than anticipated (with a lot due to
On 12 February 2014 20:59, Jeff King p...@peff.net wrote:
+sub decode {
+ my $orig = shift;
+ my $decoded = eval { decode_utf8($orig, Encode::FB_CROAK) };
+ return defined $decoded ?
I'd still advocate checking $@ here, rather than the defined $decoded check.
+
On Wed, Feb 12, 2014 at 11:10:49PM +, Thomas Adam wrote:
On 12 February 2014 20:59, Jeff King p...@peff.net wrote:
+sub decode {
+ my $orig = shift;
+ my $decoded = eval { decode_utf8($orig, Encode::FB_CROAK) };
+ return defined $decoded ?
I'd still advocate
On Wed, Feb 12, 2014 at 12:00:19PM +0100, Karsten Blees wrote:
Am 12.02.2014 04:43, schrieb Duy Nguyen:
On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson robb...@gentoo.org
wrote:
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
We in the chromium project have a keen
Am 13.02.2014 00:03, schrieb Mike Hommey:
On Wed, Feb 12, 2014 at 12:00:19PM +0100, Karsten Blees wrote:
Am 12.02.2014 04:43, schrieb Duy Nguyen:
On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson robb...@gentoo.org
wrote:
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
We in
On Wed, Feb 12, 2014 at 06:27:40PM -0500, Jeff King wrote:
On Wed, Feb 12, 2014 at 11:10:49PM +, Thomas Adam wrote:
On 12 February 2014 20:59, Jeff King p...@peff.net wrote:
+sub decode {
+ my $orig = shift;
+ my $decoded = eval { decode_utf8($orig, Encode::FB_CROAK)
On Thu, Feb 13, 2014 at 5:12 AM, Jeff King p...@peff.net wrote:
lib-httpd was never designed to be included from anywhere except the
beginning of the file. But that wouldn't be right for t5537, because it
wants to run some of the tests, even if apache setup fails. The right
way to do it is
On Thu, Feb 13, 2014 at 01:17:54AM +, brian m. carlson wrote:
On Wed, Feb 12, 2014 at 06:27:40PM -0500, Jeff King wrote:
On Wed, Feb 12, 2014 at 11:10:49PM +, Thomas Adam wrote:
On 12 February 2014 20:59, Jeff King p...@peff.net wrote:
+sub decode {
+ my $orig =
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
To this end, I'd like to start submitting patches that make the code
base generally more thread-safe and thread-friendly. Right after this
email, I'm going to send the first such patch, which makes the global
list of pack files
Thank you Torsten. Could some one help me clarify what this means?
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
This ensures that all files that git considers to be text will have
normalized (LF) line endings in the repository. The core.eol
configuration variable controls
63 matches
Mail list logo
