headers
Paul Mackerras | 1 May 2009 01:47
Picon
Favicon

Re: [PATCH] gitk: restore pane sizes when using ttk widgets

Pat Thoyts wrote:

>   This patch applies the saved pane sizes for the ttk widgets. The
>   ttk paned window does not have a paneconfigure subcommand but we
>   can set the sash position once the widget gets mapped.

Thanks.  I folded that into your "Use themed tk widgets" patch and
applied it on the dev branch.  There's still one little thing that
doesn't look quite right: the .tf.lbar.gdttype drop-down list
initially comes up empty (it should start out saying "containing") and
it is also a little too short.  How do we fix that?

Paul.
Permalink | Reply | 0 comments |
headers
Paul Mackerras | 1 May 2009 01:50
Picon
Favicon

Re: [PATCH] Another update of Russian translation

Junio Hamano wrote:

> Thanks; I've been holding off to pull from either you or Paulus (CC'ed)
> but I should before the coming weekend.  Do you want an -rc4 just to make
> sure, or can your changes become directly the final?

I've pushed Alex Riesen's Russian translation now, so please pull my
gitk repository.

Thanks,
Paul.
Permalink | Reply | 1 comment |
headers
Steven Noonan | 1 May 2009 02:23
Gravatar

Re: Why Git is so fast

On Thu, Apr 30, 2009 at 2:36 PM, Kjetil Barvik <barvik <at> broadpark.no> wrote:
> * "Shawn O. Pearce" <spearce <at> spearce.org> writes:
> |>      4) The "static inline void hashcpy(....)" in cache.h could then
> |>         maybe be written like this:
> |
> | Its already done as "memcpy(a, b, 20)" which most compilers will
> | inline and probably reduce to 5 word moves anyway.  That's why
> | hashcpy() itself is inline.
>
>  But would the compiler be able to trust that the hashcpy() is always
>  called with correct word alignment on variables a and b?
>
>  I made a test and compiled git with:
>
>    make USE_NSEC=1 CFLAGS="-march=core2 -mtune=core2 -O2 -g2 -fno-stack-protector" clean all
>
>  compiler: gcc (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) 4.3.3
>  CPU: Intel(R) Core(TM)2 CPU T7200  <at>  2.00GHz GenuineIntel
>
>  Then used gdb to get the following:
>
> (gdb) disassemble write_sha1_file
> Dump of assembler code for function write_sha1_file:
> 0x080e3830 <write_sha1_file+0>: push   %ebp
> 0x080e3831 <write_sha1_file+1>: mov    %esp,%ebp
> 0x080e3833 <write_sha1_file+3>: sub    $0x58,%esp
> 0x080e3836 <write_sha1_file+6>: lea    -0x10(%ebp),%eax
> 0x080e3839 <write_sha1_file+9>: mov    %ebx,-0xc(%ebp)
> 0x080e383c <write_sha1_file+12>:        mov    %esi,-0x8(%ebp)
> 0x080e383f <write_sha1_file+15>:        mov    %edi,-0x4(%ebp)
(Continue reading)

Permalink | Reply | 4 comments |
headers
James Pickens | 1 May 2009 03:25
Picon

Re: Why Git is so fast

On Thu, Apr 30, 2009, Steven Noonan <steven <at> uplinklabs.net> wrote:
> A bit off topic, but the results are rather interesting to me, and I
> think I see a weakness in how GCC is doing this on Intel. Someone
> please correct me if I'm wrong, but the PowerPC code seems much better
> because it can yield very high instruction-level parallelism. It does
> 5 loads and then 5 stores, using 4 registers for temporary storage and
> 2 registers for pointers.
>
> I realize the Intel x86 architecture is quite constrained in that it
> has so few general purpose registers, but there has to be better code
> than what GCC emitted above. It seems like the processor would stall
> because of the quantity of sequential inter-dependent instructions
> that can't be done in parallel (mov to memory that depends on a mov to
> eax, etc).

There aren't any unnecessary dependencies.  Take this sequence:

1:        movl    (%edx), %eax
2:        movl    %eax, (%ecx)
3:        movl    4(%edx), %eax
4:        movl    %eax, 4(%ecx)

There are two unavoidable dependencies - #2 depends on #1, and #4
depends on #3.  #3 does not depend on #2, even though they both
use %eax, because #3 is a write to %eax.  So whatever was in %eax
before #3 is irrelevant.  The processor knows this and will use
register renaming to execute #1 and #3 in parallel, and #2 and #4
in parallel.

James
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Mercer | 1 May 2009 03:49
Picon
Gravatar

Permissions of objects within shared repo

Hi

We have a shared repository with the following config:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedrepository = 1
[receive]
        denyNonFastforwards = true

Users push their commits to the repository over ssh, all users are in
group 1000 and so far everything seems to be working OK. However I
have noticed that something seems to be strange with the permissions
of the objects, e.g.:

[ram <at> g3 ~]$ cd /path/to/repo.git/objects/00/
[ram <at> g3 00]$ ls -l
total 43
-r--r--r--+ 1 user1           1000  2729 Apr 19 13:13
028ade623678384fca34c51e0ea3ae91b8a50d
-r--r--r--+ 1 user1           1000 10697 Apr 20 21:19
0d9f5769a65081bf95d64b0a23b62b55095f2f
-r--r--r--+ 1 user2           1000   297 Apr 17 10:00
2b3138d14b41d5a01308edd32e8af5ad4c4886
-r--r--r--+ 1 user3           1000   169 Apr  9 12:03
8ab284186f0ceb450d86e3ff1eca486eb6f5b3
-r--r--r--+ 1 user4           1000   846 Apr 27 16:51
90192a4a1843e5849129312ac3bc98766c4c85
(Continue reading)

Permalink | Reply | 3 comments |
headers
Junio C Hamano | 1 May 2009 06:12
Picon
Picon
Favicon
Gravatar

Re: [PATCH] Another update of Russian translation

Paul Mackerras <paulus <at> samba.org> writes:

> Junio Hamano wrote:
>
>> Thanks; I've been holding off to pull from either you or Paulus (CC'ed)
>> but I should before the coming weekend.  Do you want an -rc4 just to make
>> sure, or can your changes become directly the final?
>
> I've pushed Alex Riesen's Russian translation now, so please pull my
> gitk repository.

Thanks.
Permalink | Reply | 0 comments |
headers
Dmitry Potapov | 1 May 2009 07:24
Picon

Re: Why Git is so fast

On Thu, Apr 30, 2009 at 10:36:03PM +0200, Kjetil Barvik wrote:
>      4) The "static inline void hashcpy(....)" in cache.h could then
>         maybe be written like this:
> 
>   static inline void hashcpy(unsigned long sha_dst[5], const unsigned long sha_src[5])
>   {
>        sha_dst[0] = sha_src[0];
>        sha_dst[1] = sha_src[1];
>        sha_dst[2] = sha_src[2];
>        sha_dst[3] = sha_src[3];
>        sha_dst[4] = sha_src[4];
>   }
> 
>         And hopefully will be compiled to just 5 store/more
>         instructions, or at least hopefully be faster than the currently
>         memcpy() call. But mabye we get more compiled instructions compared
>         to a single call to memcpy()?

Good compilers can inline memcpy and should produce more efficient code
for the target architecture, which can be faster than manually written.
On x86_64, memcpy() requires only 3 load/store operations to copy SHA-1
while the above code requires 5 operations.

Dmitry
Permalink | Reply | 2 comments |
headers
Robin H. Johnson | 1 May 2009 08:17
Picon
Favicon
Gravatar

Re: Weird growth in packfile during initial push

On Wed, Apr 29, 2009 at 04:57:37PM -0700, Junio C Hamano wrote:
> > And the code matches this theory as well.  Can you try this patch if you 
> > have a chance?
> Is there any progress on this?
Sorry, I was just away for 2 weeks, only got back late yesterday. I'll
try to get to it in the next few days unless Nicolas beats me to it.

--

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Permalink | Reply | 0 comments |
headers
Felipe Contreras | 1 May 2009 10:26
Picon
Gravatar

Re: [PATCH 5/7] user-manual: use SHA-1 instead of SHA1 or sha1

On Mon, Apr 6, 2009 at 11:14 AM, Junio C Hamano <gitster <at> pobox.com> wrote:
> Thanks.
>
> This also seems to depend on the missing 3/7 but I've managed.  I retitled
> it to "user-manual: the name of the hash function is SHA-1, not sha1".

You missed one in the Trust section. I'll send a patch.

--

-- 
Felipe Contreras
Permalink | Reply | 0 comments |
headers
Felipe Contreras | 1 May 2009 10:37
Picon
Gravatar

Re: [PATCH 6/7] user-manual: add global config section

On Sun, Apr 5, 2009 at 12:47 PM, Junio C Hamano <gitster <at> pobox.com> wrote:
> Felipe Contreras <felipe.contreras <at> gmail.com> writes:
>
>> Signed-off-by: Felipe Contreras <felipe.contreras <at> gmail.com>
>> ---
>>  Documentation/user-manual.txt |   30 ++++++++++++++++++++++++++++++
>>  1 files changed, 30 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index 3278aa7..a3032c7 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>>  <at>  <at>  -40,6 +40,36  <at>  <at>  without any explanation.
>>  Finally, see <<todo>> for ways that you can help make this manual more
>>  complete.
>
> I think a "getting started" section near the beginning of the manual is a
> good idea (and ll.40- is a very early part of the manual).
>
> For that "introductory" purpose, however, I'd suggest showing how they
> appear in the actual .git/config file first in the editor and then show a
> way to use the "git config" command as an alternative.

I disagree. Opening ~/.gitconfig will just open an empty file for the
new users, afterwards they'll just scratch their heads wondering, now
what?

If you first teach them to do 'git config --global color.ui auto'
they'll blindly enter the command but then when they open the file
they'll say "ahhh, so that's what happens".
(Continue reading)

Permalink | Reply | 3 comments |

Gmane