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 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 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 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
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 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]?
>
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 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 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
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 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 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-
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 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
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 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 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 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 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 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"
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 --
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,
23 matches
Mail list logo
