This change is not completely faithful: instead of initializing all fields
to 0, we choose to initialize command and subcommand to -1 (instead of
defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
it makes no difference at all, but future-proofs the code to require
explicit as
This change is not completely faithful: instead of initializing all fields
to 0, we choose to initialize command and subcommand to -1 (instead of
defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
it makes no difference at all, but future-proofs the code to require
explicit as
Johannes Schindelin writes:
> This change is not completely faithful: instead of initializing all fields
> to 0, we choose to initialize command and subcommand to -1 (instead of
> defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
> it makes no difference at all, but future-
This change is not completely faithful: instead of initializing all fields
to 0, we choose to initialize command and subcommand to -1 (instead of
defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
it makes no difference at all, but future-proofs the code to require
explicit as
Johannes Schindelin writes:
> This change is not completely faithful: instead of initializing all fields
> to 0, we choose to initialize command and subcommand to -1 (instead of
> defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
> it makes no difference at all, but future-
This change is not completely faithful: instead of initializing all fields
to 0, we choose to initialize command and subcommand to -1 (instead of
defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
it makes no difference at all, but future-proofs the code to require
explicit as
Hi Kuba,
On Mon, 29 Aug 2016, Jakub Narębski wrote:
> W dniu 29.08.2016 o 11:19, Dennis Kaarsemaker pisze:
> > On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote:
> >
> >> +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL,
> >> NULL, NULL, 0, 0, NULL }
> >
> > Thi
W dniu 29.08.2016 o 11:19, Dennis Kaarsemaker pisze:
> On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote:
>
>> +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL,
>> NULL, NULL, 0, 0, NULL }
>
> This looked off to me, as it replaces memset(..., 0, ...) so is not
> 1
Hi Dennis,
On Mon, 29 Aug 2016, Dennis Kaarsemaker wrote:
> On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote:
>
> > +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL,
> > NULL, NULL, 0, 0, NULL }
>
> This looked off to me, as it replaces memset(..., 0, ...) so i
On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote:
> +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL,
> NULL, 0, 0, NULL }
This looked off to me, as it replaces memset(..., 0, ...) so is not
100% equivalent. But the changed functions both set opts.action an
Signed-off-by: Johannes Schindelin
---
builtin/revert.c | 6 ++
sequencer.h | 1 +
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 4e69380..7365559 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -178,10 +178,9 @@ static vo
On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager wrote:
> Forwarding to msysgit for any guidance about win equivalents for
> PTHREAD_MUTEX_INITIALIZER or __attribute__((constructor)).
As you've probably already guessed, PTHREAD_MUTEX_INITIALIZER isn't
supported in our pthreads-emulator. I did send o
Howdy,
Is there any policy on making static initializers thread-safe? I'm
working on an experimental patch to introduce threading, but I'm
running into a few non-thread-safe bits like this, in convert.c:
static const char *conv_attr_name[] = {
"crlf", "ident
13 matches
Mail list logo
