On Mon, Aug 4, 2014 at 9:19 PM, Karsten Blees wrote:
> This raises the question why we read via mmap at all
The first version of the pack bitmap format I wrote for GitHub was 50%
faster to load than this one because it was designed to be mmapable.
Eventually we moved to the JGit-compatible bitmap
On Wed, Feb 26, 2014 at 11:41 AM, Michael Haggerty wrote:
> Since time is short, I already started on this. I wrote a first draft
> of an introduction for the students. I also started looking for
> microprojects. I started going through our source files alphabetically,
> and have already found
On Wed, Feb 26, 2014 at 12:16 PM, Duy Nguyen wrote:
> On Tue, Feb 25, 2014 at 10:41 PM, Jeff King wrote:
>> I'm pleased to announce that Git has been accepted to this year's Google
>> Summer of Code.
>>
>> Student proposals will start coming in on March 22. In the meantime
>> students will be rea
On Thu, Feb 13, 2014 at 10:45 PM, Thomas Rast wrote:
> Replace object loading/writing layer by libgit2
>
> Git reads objects from storage (loose and packed) through functions in
> sha1_file.c. Most commands only require very simple, opaque read and
> write access to the object storage. As a weat
On Fri, Jan 24, 2014 at 12:45 AM, Siddharth Agarwal wrote:
> Yes, we'd prefer to do that too. How do you actually do this, though? I
> don't see a way to pass `--honor-pack-keep` (shouldn't I pass in its
> inverse?) down to `git-pack-objects`.
We run with this patch in production, it may be of us
On Fri, Jan 24, 2014 at 12:44 AM, Jonathan Nieder wrote:
>> --- a/ewah/ewah_io.c
>> +++ b/ewah/ewah_io.c
>> @@ -112,23 +112,38 @@ int ewah_serialize(struct ewah_bitmap *self, int fd)
> [...]
>> +#if __BYTE_ORDER != __BIG_ENDIAN
>
> Is this portable?
We explicitly set the __BYTE_ORDER macros in `c
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano wrote:
> Stefan Näwe writes:
>
>> Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
>>> Will there be any change on how tarballs are distributed, taking into
>>> account that Google will be shutting down Google Code Downloads
>>> section[1][2]?
>
Sounds good. We don't really need the dump anyway.
On Sat, Dec 28, 2013 at 11:00 AM, Jeff King wrote:
> On Wed, Dec 25, 2013 at 11:08:57PM +0100, Erik Faye-Lund wrote:
>
>> On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote:
>> > From: Ramsay Jones
>> >
>> > Signed-off-by: Ramsay Jones
>> > Sign
On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano wrote:
>> Do we want to try this in 'next' post-1.8.5, or should I try to prod an
>> area expert like Shawn into doing another round of review?
>
> Yes ;-).
>
> I recall starting to read the series over and then got sidetracked
> in the middle and ne
Thank you Ramsay, all the patches look OK to me.
On Thu, Nov 7, 2013 at 11:19 PM, Jeff King wrote:
> On Thu, Nov 07, 2013 at 09:58:02PM +, Ramsay Jones wrote:
>
>> These patches fix various errors/warnings on the cygwin, MinGW and
>> msvc builds, provoked by the jk/pack-bitmap branch.
>
> Tha
On Oct 30, 2013, at 9:25 AM, Jeff King wrote:
> On Sat, Oct 26, 2013 at 09:55:36AM +0200, Thomas Rast wrote:
>
>>> The POSIX standard doesn't currently define a `nothll`/`htonll`
>>
>> typo: ntohll
>
> Thanks.
>
>>> function pair to perform network-to-host and host-to-network
>>> swaps of 64-
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote:
> There is a name clash under cygwin 1.7 (1.5 is OK)
> The following "first aid hot fix" works for me:
> /Torsten
If Cygwin declares its own bswap_64, wouldn't it be better to use it
instead of overwriting it with our own?
--
To unsubsc
On Mon, Oct 28, 2013 at 8:45 PM, Karsten Blees wrote:
>> The new `hashmap.c` covers the first case quite well (albeit slightly
>> more verbosely than I'd like), but in the second case it doesn't quite
>> work. Since the new hash needs to embed the "struct hashmap_entry" on
>> all its values (to al
On Mon, Oct 28, 2013 at 4:48 PM, Junio C Hamano wrote:
>> jk/pack-bitmap adds khash.h, which from a first glance looks like yet
>> another hash table implementation. I was just wondering if kb's new
>> hash tables can cover the need of pack-bitmap.c too so we can remove
>> khash.h later..
>
> Good
That was a very rude reply. :(
Please refrain from interacting with me in the ML in the future. I'l
do accordingly.
Thanks!
vmg
On Thu, Jun 27, 2013 at 3:11 AM, Shawn Pearce wrote:
> On Tue, Jun 25, 2013 at 4:08 PM, Vicent Martí wrote:
>> On Tue, Jun 25, 2013 at 11:17 PM,
I'm afraid I cannot reproduce the segfault locally (assuming you're
performing the rev-list on the git/git repository). Could you please
send me more information, and a core dump if possible?
On Tue, Jun 25, 2013 at 6:22 PM, Thomas Rast wrote:
> Vicent Marti writes:
>
>> Calling `git rev-list --
On Wed, Jun 26, 2013 at 1:00 AM, Junio C Hamano wrote:
>> @@ -156,6 +156,11 @@ do
>> fullbases="$fullbases pack-$name"
>> chmod a-w "$PACKTMP-$name.pack"
>> chmod a-w "$PACKTMP-$name.idx"
>> +
>> + test -f "$PACKTMP-$name.bitmap" &&
>> + chmod a-w "$PACKTMP-$name.bitmap"
On Wed, Jun 26, 2013 at 1:06 AM, Junio C Hamano wrote:
>> @@ -83,6 +84,9 @@ static struct progress *progress_state;
>> static int pack_compression_level = Z_DEFAULT_COMPRESSION;
>> static int pack_compression_seen;
>>
>> +static int bitmap_support;
>> +static int use_bitmap_index;
>
> OK.
>
>> @
On Wed, Jun 26, 2013 at 12:48 AM, Junio C Hamano wrote:
> After this, the function returns. The original did not add to the
> table the object name we are looking at, but the new code first adds
> it to the table with the unconditional kh_put_sha1() above. Is a
> call to kh_del_sha1() missing he
On Tue, Jun 25, 2013 at 5:58 PM, Thomas Rast wrote:
>
>> This is the technical documentation and design rationale for the new
>> Bitmap v2 on-disk format.
>
> Hrmpf, that's what I get for reading the series in order...
>
>> + The folowing flags are supported:
>
On Tue, Jun 25, 2013 at 11:17 PM, Junio C Hamano wrote:
> What case are you talking about?
>
> The n-th object must be one of these four types and can never be of
> more than one type at the same time, so a natural expectation from
> the reader is "If you OR them together, you will get the same se
On Tue, Jun 25, 2013 at 7:42 AM, Shawn Pearce wrote:
> I very much hate seeing a file format that is supposed to be portable
> that supports both big-endian and little-endian encoding.
Well, the bitmap index is not supposed to be portable, as it doesn't
get sent over the wire in any situation. Re
On Tue, Jun 25, 2013 at 3:08 PM, Peter Krefting wrote:
> endian(3) claims that glibc 2.9+ define be64toh() and htobe64() which should
> do what you are looking for. The manual page does mention them being named
> differently across OSes, though, so you may need to be careful with that.
I'm aware
23 matches
Mail list logo
