2017-07-16 3:30 GMT+08:00 Jean-Noël Avila :
>
>
> A few remarks on i18n:
>
> * commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for
> timestamps") does not play well with i18n framework. The static string
> concatenation cannot be correctly interpreted by msgmerge. I don't know
> how w
Hey guys, please see the below patch. (please read commit message
first and then the following:)
In particular I'd like to hear comments about the changes I made to
how smudging works.
I am not confident on whether it is a good way to permanently fix the problem.
I'm wondering if there's a better w
On Sun, Jul 16, 2017 at 2:13 PM, Dave Borowitz wrote:
> On Sun, Jul 16, 2017 at 3:43 PM, Shawn Pearce wrote:
>> True... but... in my "android" example repository we have 866,456 live
>> refs. A block size of 64k needs only 443 blocks, and a 12k index, to
>> get the file to compress to 28M (vs. 62
On Sun, Jul 16, 2017 at 3:43 PM, Shawn Pearce wrote:
> True... but... in my "android" example repository we have 866,456 live
> refs. A block size of 64k needs only 443 blocks, and a 12k index, to
> get the file to compress to 28M (vs. 62M packed-refs).
>
> Index records are averaging 28 bytes per
On Sun, Jul 16, 2017 at 12:43 PM, Shawn Pearce wrote:
> On Sun, Jul 16, 2017 at 10:33 AM, Michael Haggerty
> wrote:
>
>> * The tuning parameter number_of_restarts currently trades off space
>> (for the full refnames and the restart_offsets) against the need to
>> read and parse more ref_records
On Sun, Jul 16, 2017 at 10:33 AM, Michael Haggerty wrote:
> Thanks for your reftable proposal.
Thanks for your time reading the proposal. I really was looking
forward to your insights on this project.
> It would solve a lot of scalability
> problems that we currently have, and do it in a way tha
The git UI can be improved by addressing the error messages to those
they help: inexperienced and casual git users. To this intent, it is
helpful to make sure the terms used in those messages can be understood
by this segment of users, and that they guide them to resolve the
problem.
In particular
Hi all,
I have started a new translation af.po at:
(https://github.com/jbviviers/git-po)
The translation is far from complete. Should I wait until it is all
done before I submit the patch, or is it better to submit as I go
along?
Although it is unlikely that someone else is busy with the same th
Thanks for your reftable proposal. It would solve a lot of scalability
problems that we currently have, and do it in a way that is
implementable in both C and Java, which is very nice.
There are two mostly orthogonal components to your proposal:
1. What does a single reftable file look like?
2. H
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S.
I know this may seem inappropriate so i ask for your forgiveness but i wish to
get to know you better, if I may be so bold. I consider myself an easy-going
man, adventurous, honest and fun loving person but I am curr
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S.
I know this may seem inappropriate so i ask for your forgiveness but i wish to
get to know you better, if I may be so bold. I consider myself an easy-going
man, adventurous, honest and fun loving person but I am curre
On Sun, Jul 16, 2017 at 05:18:27PM +0200, René Scharfe wrote:
> > it looks like assumptions about struct layout are pervasive and part of
> > the on-disk format. Yuck. :(
>
> Assuming that there is no padding probably even works for the platforms
> the code currently supports (basically x86), but
From: "Jonathan Tan"
Sent: Tuesday, July 11, 2017 8:48 PM
These patches are part of a set of patches implementing partial clone,
as you can see here:
https://github.com/jonathantanmy/git/tree/partialclone
In that branch, clone with batch checkout works, as you can see in the
README. The code a
Am 16.07.2017 um 16:04 schrieb Jeff King:
> On Sun, Jul 16, 2017 at 02:17:37PM +0200, René Scharfe wrote:
>
>> -static void stat_data_from_disk(struct stat_data *to, const struct
>> stat_data *from)
>> +static void stat_data_from_disk(struct stat_data *to, const unsigned char
>> *data)
>> {
>>
On Sun, Jul 16, 2017 at 03:42:09PM +0200, Jan Danielsson wrote:
> > 1. Drop the pruning (in which case deleted branches from the sync may
> > accumulate, but depending on the patterns that may or may not be a
> > problem).
>
>I don't think that's a problem. Or rather, I'd be will
From: "Philip Oakley"
From: "Stefan Beller"
Sent: Tuesday, July 11, 2017 2:06 AM
A symbolic ref can currently only point at (another symbolic) ref.
However are use cases for symbolic refs to point at other things
representing a commit-ish, such as gitlink entries in other
repositories. In thi
On Sun, Jul 16, 2017 at 02:17:37PM +0200, René Scharfe wrote:
> -static void stat_data_from_disk(struct stat_data *to, const struct stat_data
> *from)
> +static void stat_data_from_disk(struct stat_data *to, const unsigned char
> *data)
> {
> - to->sd_ctime.sec = get_be32(&from->sd_ctime.s
On 07/16/17 12:10, Jeff King wrote:
>>This seems to accomplish everything I want except that the the "git
>> push" deletes any branches I have created on my self-hosted
>> repository.
>
> A mirrored push is basically:
>
> - push all refs, i.e., a "+refs/*:refs/*" refspec
>
> - enable --p
From: "Stefan Beller"
Sent: Tuesday, July 11, 2017 2:06 AM
A symbolic ref can currently only point at (another symbolic) ref.
However are use cases for symbolic refs to point at other things
representing a commit-ish, such as gitlink entries in other
repositories. In this use case we can use su
The untracked cache is stored on disk by concatenating its memory
structures without any padding. Consequently some of the structs are
not aligned at a particular boundary when the whole extension is read
back in one go. That's only OK on platforms without strict alignment
requirements, or for by
From: "Junio C Hamano"
Sent: Wednesday, July 12, 2017 10:29 PM
William Duclot writes:
- The original said "When you have resolved this problem", without
giving a guidance how to resolve, and without saying what the
problem is. The updated one says "conflict" to clarify the
"problem
Am 16.07.2017 um 13:15 schrieb René Scharfe:
Am 16.07.2017 um 13:08 schrieb Jeff King:
On Sun, Jul 16, 2017 at 01:06:45PM +0200, René Scharfe wrote:
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b8514a0029..adf572da68 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -36
On Sun, Jul 16, 2017 at 01:10:50PM +0200, René Scharfe wrote:
> > And I was pleased to see that after setting OPENSSL_SHA1, the answer to
> > "how far" is "we are there". Yay.
>
> True with GCC, but not with Clang 3.9. A patch for alignment issues in
> dir.c is coming up..
Good to know that the
Am 16.07.2017 um 13:08 schrieb Jeff King:
On Sun, Jul 16, 2017 at 01:06:45PM +0200, René Scharfe wrote:
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b8514a0029..adf572da68 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -362,7 +362,7 @@ static void prune_index(struct i
Exit early when asked to prune an index that contains no entries to
begin with. This avoids pointer arithmetic on istate->cache, which is
possibly NULL in that case.
Found with Clang's UBSan.
Signed-off-by: Rene Scharfe
---
Messed up whitespace when sending this the first time.
builtin/ls-fil
Am 16.07.2017 um 12:47 schrieb Jeff King:
On Sun, Jul 16, 2017 at 06:45:32AM -0400, Jeff King wrote:
I was playing with SANITIZE=undefined after René's patches to see how
far we had left to go. I forgot to turn off sha1dc, which causes most
programs to die due to the unaligned loads. That means
On Sun, Jul 16, 2017 at 01:06:45PM +0200, René Scharfe wrote:
> > > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > > index b8514a0029..adf572da68 100644
> > > --- a/builtin/ls-files.c
> > > +++ b/builtin/ls-files.c
> > > @@ -362,7 +362,7 @@ static void prune_index(struct index_state *ist
Am 16.07.2017 um 12:41 schrieb Jeff King:
On Sat, Jul 15, 2017 at 10:11:20PM +0200, René Scharfe wrote:
Exit early when asked to prune an index that contains no
entries to begin with. This avoids pointer arithmetic on
istate->cache, which is possibly NULL in that case.
Found with Clang's UBSa
Am 16.07.2017 um 12:17 schrieb Jeff King:
On Sat, Jul 15, 2017 at 07:18:56PM +0200, René Scharfe wrote:
-- >8 --
Subject: [PATCH] Makefile: allow combining UBSan with other sanitizers
Multiple sanitizers can be specified as a comma-separated list. Set
the flag NO_UNALIGNED_LOADS even if Undef
On Sun, Jul 16, 2017 at 06:45:32AM -0400, Jeff King wrote:
> I was playing with SANITIZE=undefined after René's patches to see how
> far we had left to go. I forgot to turn off sha1dc, which causes most
> programs to die due to the unaligned loads. That means git-archive in
> t5000 generates no ou
The test_copy_bytes() function claims to read up to N bytes,
or until it gets EOF. But we never handle EOF in our loop,
and a short input will cause perl to go into an infinite
loop of read() getting zero bytes.
Signed-off-by: Jeff King
---
I was playing with SANITIZE=undefined after René's patch
On Sat, Jul 15, 2017 at 10:11:20PM +0200, René Scharfe wrote:
> Exit early when asked to prune an index that contains no
> entries to begin with. This avoids pointer arithmetic on
> istate->cache, which is possibly NULL in that case.
>
> Found with Clang's UBSan.
Makes sense. We could use MOVE_
On Sat, Jul 15, 2017 at 09:36:20PM +0200, René Scharfe wrote:
> Similar to COPY_ARRAY (introduced in 60566cbb58), add a safe and
> convenient helper for moving potentially overlapping ranges of array
> entries. It infers the element size, multiplies automatically and
> safely to get the size in b
On Sun, Jul 16, 2017 at 06:27:04AM -0400, Jeff King wrote:
> On Sat, Jul 15, 2017 at 09:22:50PM +0200, René Scharfe wrote:
>
> > Simplify the implementation and allow callers to use expressions with
> > side-effects by turning the macros get_be16, get_be32 and put_be32 into
> > inline functions.
On Sat, Jul 15, 2017 at 09:22:50PM +0200, René Scharfe wrote:
> Simplify the implementation and allow callers to use expressions with
> side-effects by turning the macros get_be16, get_be32 and put_be32 into
> inline functions.
>
> Signed-off-by: Rene Scharfe
> ---
> All these redundant casts st
On Sat, Jul 15, 2017 at 07:18:56PM +0200, René Scharfe wrote:
> -- >8 --
> Subject: [PATCH] Makefile: allow combining UBSan with other sanitizers
>
> Multiple sanitizers can be specified as a comma-separated list. Set
> the flag NO_UNALIGNED_LOADS even if UndefinedBehaviorSanitizer is not
> the
On Sun, Jul 16, 2017 at 02:59:23AM +0200, Jan Danielsson wrote:
>This seems to accomplish everything I want except that the the "git
> push" deletes any branches I have created on my self-hosted
> repository.
A mirrored push is basically:
- push all refs, i.e., a "+refs/*:refs/*" refspec
Am 16.07.2017 um 12:03 schrieb Jeff King:
On Sun, Jul 16, 2017 at 10:07:57AM +0200, Johannes Sixt wrote:
Am 14.07.2017 um 22:08 schrieb Jeff King:
The implementation on this doesn't seem overly complex. My main concerns
are what we're asking from the filesystem in terms of atomicity, and
what
On Sun, Jul 16, 2017 at 10:07:57AM +0200, Johannes Sixt wrote:
> Am 14.07.2017 um 22:08 schrieb Jeff King:
> > The implementation on this doesn't seem overly complex. My main concerns
> > are what we're asking from the filesystem in terms of atomicity, and
> > what possible races there are.
>
> O
On Sat, Jul 15, 2017 at 11:01:47PM -0700, Shawn Pearce wrote:
> > How deep would you anticipate stacks getting? Would it be feasible for
> > the tip to contain the names of the tables in the entire chain? If we're
> > talking about 20 (or even 32) bytes per name, you could still fit over a
> > hun
Am 14.07.2017 um 22:08 schrieb Jeff King:
The implementation on this doesn't seem overly complex. My main concerns
are what we're asking from the filesystem in terms of atomicity, and
what possible races there are.
One of the failure modes is that on Windows a file cannot be deleted
while it i
41 matches
Mail list logo