On Sun, Nov 09, 2014 at 02:49:58PM +0100, René Scharfe wrote:
> -- >8 --
> Subject: [PATCH] trailer: use CHILD_PROCESS_INIT in apply_command()
>
> Initialize the struct child_process variable cp at declaration time.
> This is shorter, saves a function call and prevents using the variable
> before
Am 29.10.2014 um 18:21 schrieb Jeff King:
> On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
>> diff --git a/trailer.c b/trailer.c
>> index 8514566..7ff036c 100644
>> --- a/trailer.c
>> +++ b/trailer.c
>> @@ -237,7 +237,7 @@ static const char *apply_command(const char *command,
>> con
From: "Jeff King"
On Wed, Nov 05, 2014 at 01:35:21PM -, Philip Oakley wrote:
>> 2. Including two lines, like:
[...]
I believe that the 'two HEADs' mechanism would also fall foul of the
'duplicate refs' warning (untested).
It didn't in my very brief testing of what I posted above, but ma
On Wed, Nov 05, 2014 at 01:35:21PM -, Philip Oakley wrote:
> >> 2. Including two lines, like:
> [...]
> I believe that the 'two HEADs' mechanism would also fall foul of the
> 'duplicate refs' warning (untested).
It didn't in my very brief testing of what I posted above, but maybe
there is so
From: "Jeff King"
Subject: Re: [PATCH] use child_process_init() to initialize struct
child_process variables
On Tue, Nov 04, 2014 at 01:56:15PM -0800, Junio C Hamano wrote:
>> 2. Including two lines, like:
>>
>> $sha1 HEAD\0symref=refs/heads/
From: "Junio C Hamano"
Sent: Monday, November 03, 2014 11:42 PM
Jeff King writes:
I peeked at libgit2 and I think it does not support bundles at all
yet,
so that is safe. Grepping for "bundle" in dulwich turns up no hits,
either.
Looks like JGit does support them. I did a very brief test, a
Jeff King writes:
> The bundle code is not bound by this historical legacy, and could do it
> in a different (and more efficient and flexible) way. But it is probably
> saner to just keep them identical. It makes the code simpler, and having
> bundle as the only transport which has the extra flex
On Tue, Nov 04, 2014 at 01:56:15PM -0800, Junio C Hamano wrote:
> >> 2. Including two lines, like:
> >>
> >> $sha1 HEAD\0symref=refs/heads/master
> >> $sha1 HEAD
> >>
> >> which JGit does the right thing with (and git.git seems to, as
> >> well).
> >
> > Sounds sensible
Junio C Hamano writes:
> Jeff King writes:
>
>> I peeked at libgit2 and I think it does not support bundles at all yet,
>> so that is safe. Grepping for "bundle" in dulwich turns up no hits,
>> either.
>>
>> Looks like JGit does support them. I did a very brief test, and it seems
>> to silently
Jeff King writes:
> I peeked at libgit2 and I think it does not support bundles at all yet,
> so that is safe. Grepping for "bundle" in dulwich turns up no hits,
> either.
>
> Looks like JGit does support them. I did a very brief test, and it seems
> to silently ignore a HEAD ref that has the NUL
On Mon, Nov 03, 2014 at 10:26:48AM -0800, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
> > This certainly looks the way to go. The one extra question would be
> > whether the symref should be included by default when HEAD is present,
> > or only if there was possible ambiguity between the o
"Philip Oakley" writes:
> This certainly looks the way to go. The one extra question would be
> whether the symref should be included by default when HEAD is present,
> or only if there was possible ambiguity between the other listed
> refs.
Just include the "\0symref=..." for any symbolic ref y
From: "Jeff King"
On Fri, Oct 31, 2014 at 02:48:17PM -0700, Junio C Hamano wrote:
Programs that read a pack data stream unpack-objects were originally
designed to ignore cruft after the pack data stream ends, and
because the bundle file format ends with pack data stream, you
should have been a
On Fri, Oct 31, 2014 at 02:48:17PM -0700, Junio C Hamano wrote:
> Programs that read a pack data stream unpack-objects were originally
> designed to ignore cruft after the pack data stream ends, and
> because the bundle file format ends with pack data stream, you
> should have been able to append
"Philip Oakley" writes:
> As a side project (slow time) I've been looking at the loss of the
> HEAD symbolic ref when multiple heads are bundled that point at the
> same rev. That is, when the HEAD detection heuristic fails.
It think you are talking about the logic used by the "clone", where
-
From: "Jeff King"
On Wed, Oct 29, 2014 at 12:16:05PM -0700, Junio C Hamano wrote:
Probably three helper functions:
- The first is to find tops and bottoms (this translates fuzzy
specifications such as "--since 30.days" into a more concrete
revision range "^A ^B ... Z" to establish bund
On Wed, Oct 29, 2014 at 12:16:05PM -0700, Junio C Hamano wrote:
> Probably three helper functions:
>
> - The first is to find tops and bottoms (this translates fuzzy
>specifications such as "--since 30.days" into a more concrete
>revision range "^A ^B ... Z" to establish bundle prerequis
On Thu, Oct 30, 2014 at 11:07:39AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] bundle: split out a helper function to create a pack data
s/a pack data/pack data/
> The create_bundle() function, while it does one single logical thing
> and tries to do it well, that single logical t
Junio C Hamano writes:
> Probably three helper functions:
>
> - The first is to find tops and bottoms (this translates fuzzy
>specifications such as "--since 30.days" into a more concrete
>revision range "^A ^B ... Z" to establish bundle prerequisites),
>which is done by running a "r
Jeff King writes:
> On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
>
>> --- a/bundle.c
>> +++ b/bundle.c
>> @@ -381,7 +381,7 @@ int create_bundle(struct bundle_header *header, const
>> char *path,
>> write_or_die(bundle_fd, "\n", 1);
>>
>> /* write pack */
>> -mems
On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
> --- a/bundle.c
> +++ b/bundle.c
> @@ -381,7 +381,7 @@ int create_bundle(struct bundle_header *header, const
> char *path,
> write_or_die(bundle_fd, "\n", 1);
>
> /* write pack */
> - memset(&rls, 0, sizeof(rls));
>
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: René Scharfe
Sent: Tuesday, October 28, 2014 16:59
To: Git Mailing List
Cc: Junio C Hamano
Subject: [PATCH] use child_process_init() to initialize struct child_process
variables
Call child_process_init
Call child_process_init() instead of zeroing the memory of variables of
type struct child_process by hand before use because the former is both
clearer and shorter.
Signed-off-by: Rene Scharfe
---
bundle.c | 2 +-
column.c | 2 +-
trailer.c | 2 +-
transport-helper.c
23 matches
Mail list logo
