All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Michael Ward <mward@smartsoftwareinc.com>,
	git@vger.kernel.org, Derrick Stolee <dstolee@microsoft.com>,
	Jeff King <peff@peff.net>
Subject: Re: Git 2 force commits but Git 1 doesn't
Date: Tue, 23 Jun 2020 19:13:39 +0000	[thread overview]
Message-ID: <20200623191339.GT6531@camp.crustytoothpaste.net> (raw)
In-Reply-To: <83e99359-2c24-d8cd-bd4a-6ba90ed54b7f@web.de>

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

On 2020-06-23 at 16:42:48, René Scharfe wrote:
> We could save 4 bytes on x64 by reducing FLAG_BITS from 29 to 28, by the
> way.  Increasing it to 32 would be free.  That's because parsed (1),
> type (3) and flags (29) currently occupy 33 bits, which are padded to 8
> bytes.  And bits 22-24 are only used by builtin/show-branch.c, so it
> should be easy to tighten the flags range just a bit.  Weird.

Actually, as you've just shown, we're already using 8 bytes, so
increasing FLAG_BITS to 60 wouldn't actually allocate any additional
memory.  Unfortunately, C11 says that a "bit-field shall have a type
that is a qualified or unqualified version of _Bool, signed int,
unsigned int, or some other implementation-defined type," so using
uint64_t here wouldn't be portable.  So in that case we may want to
shrink it to be just 4 bytes.

> > Assuming we don't want to do that right now, may I have your sign-off
> > for the following code, René, so I can add it to a patch along with my
> > test?
> >
> >> diff --git a/http-push.c b/http-push.c
> >> index 822f326599..99adbebdcf 100644
> >> --- a/http-push.c
> >> +++ b/http-push.c
> >> @@ -70,10 +70,10 @@ enum XML_Status {
> >>  #define LOCK_REFRESH 30
> >>
> >>  /* Remember to update object flag allocation in object.h */
> >> -#define LOCAL    (1u<<16)
> >> -#define REMOTE   (1u<<17)
> >> -#define FETCHING (1u<<18)
> >> -#define PUSHING  (1u<<19)
> >> +#define LOCAL    (1u<<11)
> >> +#define REMOTE   (1u<<12)
> >> +#define FETCHING (1u<<13)
> >> +#define PUSHING  (1u<<14)
> >>
> >>  /* We allow "recursive" symbolic refs. Only within reason, though */
> >>  #define MAXDEPTH 5
> >> diff --git a/object.h b/object.h
> >> index b22328b838..a496d2e4e1 100644
> >> --- a/object.h
> >> +++ b/object.h
> >> @@ -67,7 +67,7 @@ struct object_array {
> >>   * builtin/blame.c:                        12-13
> >>   * bisect.c:                                        16
> >>   * bundle.c:                                        16
> >> - * http-push.c:                                     16-----19
> >> + * http-push.c:                          11-----14
> >>   * commit-graph.c:                                15
> >>   * commit-reach.c:                                  16-----19
> >>   * sha1-name.c:                                              20
> >>
> 
> You're welcome to use it.  Not sure if a sign-off is necessary, but
> here you have it:
> 
> Signed-off-by: René Scharfe <l.s.r@web.de>

Thanks.  You did the work here and I'd much prefer to add your sign-off
to give you credit for that.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2020-06-23 19:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 19:40 Git 2 force commits but Git 1 doesn't Michael Ward
2020-06-22 20:21 ` brian m. carlson
2020-06-22 20:30   ` Michael Ward
2020-06-22 20:31     ` Michael Ward
2020-06-22 20:43     ` brian m. carlson
2020-06-22 20:52       ` Michael Ward
2020-06-22 21:09         ` brian m. carlson
2020-06-22 22:17           ` Michael Ward
2020-06-23  1:05             ` brian m. carlson
2020-06-23  8:59               ` René Scharfe
2020-06-23 15:30                 ` brian m. carlson
2020-06-23 16:42                   ` René Scharfe
2020-06-23 19:13                     ` brian m. carlson [this message]
2020-06-24 13:05                     ` René Scharfe
2020-06-23 20:21               ` [PATCH] http-push: ensure unforced pushes fail when data would be lost brian m. carlson
2020-06-23 21:28                 ` Eric Sunshine
2020-06-23 21:50                   ` brian m. carlson
2020-06-23 21:52                 ` [PATCH v2] " brian m. carlson
2020-06-23 22:41                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200623191339.GT6531@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=mward@smartsoftwareinc.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.