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 w
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
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 wrote:
> > > > +sub decode {
> > > > + my $orig = s
On Thu, Feb 13, 2014 at 5:12 AM, Jeff King 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 probably to h
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 wrote:
> > > +sub decode {
> > > + my $orig = shift;
> > > + my $decoded = eval { decode_utf8($orig, Encode::FB_CROAK) }
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
>>> wrote:
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
> We in t
On Wed, Feb 12, 2014 at 11:10:49PM +, Thomas Adam wrote:
> On 12 February 2014 20:59, Jeff King wrote:
> > +sub decode {
> > + my $orig = shift;
> > + my $decoded = eval { decode_utf8($orig, Encode::FB_CROAK) };
> > + return defined $decoded ?
>
> I'd still advocate checkin
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
> > wrote:
> >> On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
> >>> We in the chromium project have a keen interest in a
On 12 February 2014 20:59, Jeff King 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.
> + ($decod
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
> Stefan Zager writes:
>
> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup 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,
>
On Wed, Feb 12, 2014 at 12:27 PM, Stefan Zager wrote:
> On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano wrote:
>> Stefan Zager writes:
>>
>> Calls to write (and preparation of data to be written) will then
>> remain single-threaded, but it sounds like that codepath is not the
>> bottleneck in y
Jeff King 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).
t/lib-git-da
On Wed, Feb 12, 2014 at 11:06:43AM -0800, Junio C Hamano wrote:
> Jeff King 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,
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 main
I have the following alias defined:
sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
git pull && git co $cbr && git rebase $1; }; f"
The goal is to basically update a local branch which tracks a branch
on a remote, and then rebase my local topic branch onto that updated
local br
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
>
sza...@chromium.org writes:
> From 0a59547f3e95ddecf7606c5f259ae6177c5a104f Mon Sep 17 00:00:00 2001
Please drop this line.
> From: Stefan Zager
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 header, which is t
On Tue, Feb 11, 2014 at 06:09:10PM +0900, Yoshihiro Sugi wrote:
> diff-highlight split each hunks and compare them as byte sequences.
> it causes problems when diff hunks include multibyte characters.
> This change enable to work on such cases by decoding inputs and encoding
> output as utf8 stri
On Tue, Feb 11, 2014 at 11:29 AM, Junio C Hamano wrote:
> Shawn Pearce 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 lazy fetch if
> it is done ext
On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano wrote:
> Stefan Zager 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
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: FILE:
Stefan Zager 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 paths to be
checked
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
David Kastrup 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.
>
> Sig
On Wed, Feb 12, 2014 at 11:22 AM, Karsten Blees wrote:
> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
>> On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager wrote:
>>> On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund
>>> wrote:
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote:
>
> I
Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
> On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager wrote:
>> On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund wrote:
>>> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote:
I don't want to steal the thunder of my coworker, who wrote the
i
Stefan Zager 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 fixing whitespace
Stefan Zager writes:
> On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup 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 it's cutting into my
>>
Jeff King 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 on it with
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup wrote:
> Stefan Zager 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 worse.
>
> There is an o
>From 0a59547f3e95ddecf7606c5f259ae6177c5a104f Mon Sep 17 00:00:00 2001
From: Stefan Zager
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, the operations which
Stefan Zager writes:
> On Tue, Feb 11, 2014 at 11:29 PM, Chris Packham
> wrote:
>> Hi,
>>
>> On 12/02/14 14:57, Stefan Zager wrote:
>>> From b4796d9d99c03b0b7cddd50808a41413e45f1129 Mon Sep 17 00:00:00 2001
>>> From: Stefan Zager
>>> Date: Mon, 10 Feb 2014 16:55:12 -0800
>>> Subject: [PATCH] M
Stefan Zager writes:
> On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen 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
On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager wrote:
> On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund wrote:
>> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote:
>>>
>>> I don't want to steal the thunder of my coworker, who wrote the
>>> implementation. He plans to submit it upstream soon-
On Wed, Feb 12, 2014 at 10:33 AM, Matthieu Moy
wrote:
> Stefan Zager 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
On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund wrote:
> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager 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 lpOverlapped argument to Rea
Stefan Zager 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.
--
Matthieu Moy
http://www-
On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager wrote:
> On Wed, Feb 12, 2014 at 3:59 AM, Erik Faye-Lund wrote:
>> On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager wrote:
>>>
>>> We are particularly concerned with the performance of msysgit, and we
>>> have already chalked up a significant performanc
On Tue, Feb 11, 2014 at 11:29 PM, Chris Packham wrote:
> Hi,
>
> On 12/02/14 14:57, Stefan Zager wrote:
>> From b4796d9d99c03b0b7cddd50808a41413e45f1129 Mon Sep 17 00:00:00 2001
>> From: Stefan Zager
>> Date: Mon, 10 Feb 2014 16:55:12 -0800
>> Subject: [PATCH] Make the global packed_git variable
On Wed, Feb 12, 2014 at 3:59 AM, Erik Faye-Lund wrote:
> On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager wrote:
>>
>> We are particularly concerned with the performance of msysgit, and we
>> have already chalked up a significant performance gain by turning on
>> the threading code in pack-objects (
On Tue, Feb 11, 2014 at 7:43 PM, Duy Nguyen 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 "status"..) sho
On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen 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 it's probabl
Duy Nguyen writes:
> On Tue, Feb 11, 2014 at 2:11 AM, Junio C Hamano wrote:
>> On Mon, Feb 10, 2014 at 10:43 AM, Junio C Hamano wrote:
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print "auto packing in background.." when we actually
can do
Junio C Hamano writes:
> Kirill Smelkov 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 to manually verify t
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 endian
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 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=in
On Wed, Feb 12, 2014 at 3:22 PM, Erik Faye-Lund wrote:
> On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen wrote:
>> On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup wrote:
>>> Johannes Sixt writes:
>>>
Am 2/12/2014 13:55, schrieb David Kastrup:
> Johannes Sixt writes:
>
>> Running te
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
---
Sin
On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen wrote:
> On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup wrote:
>> Johannes Sixt writes:
>>
>>> Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt writes:
> Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
>>
On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup wrote:
> Johannes Sixt writes:
>
>> Am 2/12/2014 13:55, schrieb David Kastrup:
>>> Johannes Sixt writes:
>>>
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Hav
Johannes Sixt writes:
> Am 2/12/2014 13:55, schrieb David Kastrup:
>> Johannes Sixt 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 i
Am 2/12/2014 13:55, schrieb David Kastrup:
> Johannes Sixt 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?
>>
>> (gd
Johannes Sixt 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: D:\Src\mingw-git\t\trash
Am 2/12/2014 12:56, schrieb Erik Faye-Lund:
> On Wed, Feb 12, 2014 at 8:27 AM, Johannes Sixt 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
On Wed, Feb 12, 2014 at 2:54 AM, Stefan Zager 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 when working with r
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 https://github.com/apba
On Wed, Feb 12, 2014 at 8:27 AM, Johannes Sixt 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) run
> Starting pro
Am 12.02.2014 04:43, schrieb Duy Nguyen:
> On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson 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 lengthy operati
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
On Wed, Feb 12, 2014 at 9:53 AM, Joachim Breitner
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 _commit_ (3d7de37...).
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. Th
On Wed, Feb 12, 2014 at 1:06 AM, Junio C Hamano wrote:
> Johan Herland 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 could've been a
>> workaround
On Tue, Feb 11, 2014 at 11:59:02AM -0800, Junio C Hamano wrote:
> Kirill Smelkov 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
> >
> > c90483
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
> wrote:
> > judging from the documentation I got the impression that I can pass any
> > git object has to "git note -C " and it would stored as-is. But it
> > seems the
65 matches
Mail list logo
