Re: [PATCH 1/4] diff.h: extend "flags" field to 64 bits because we're out of bits

2 messages, 2 authors, 2016-06-16 · open the first message on its own page

Re: [PATCH 1/4] diff.h: extend "flags" field to 64 bits because we're out of bits

From: Junio C Hamano <hidden>
Date: 2016-06-16 02:19:46

Nguyễn Thái Ngọc Duy  [off-list ref] writes:
Current flags field is 32-bits, all used except one bit and we need one
more bit is needed for to toggle i-t-a behavior. The 9th bit could be
reused for this, but we could just extend it to 64 bits now to give room
for more future flags.
Isn't it a better option to add new things as separate words (or a
separate bit:1 field)?  Is this 32nd thing envisioned to be added
going to be used everywhere like the existing flag bits, or can it
be handled like "use_color", "break_opt", "show_rename_progress"?

Re: [PATCH 1/4] diff.h: extend "flags" field to 64 bits because we're out of bits

From: Duy Nguyen <hidden>
Date: 2016-06-16 02:19:46

On Tue, Jun 7, 2016 at 2:45 AM, Junio C Hamano [off-list ref] wrote:
Nguyễn Thái Ngọc Duy  [off-list ref] writes:
quoted
Current flags field is 32-bits, all used except one bit and we need one
more bit is needed for to toggle i-t-a behavior. The 9th bit could be
reused for this, but we could just extend it to 64 bits now to give room
for more future flags.
Isn't it a better option to add new things as separate words (or a
separate bit:1 field)?  Is this 32nd thing envisioned to be added
going to be used everywhere like the existing flag bits, or can it
be handled like "use_color", "break_opt", "show_rename_progress"?
It could probably live as a separate bitfield, or an int. What scares
me is "flags" sometimes is backed up then restored, but it's probably
ok. But we need to extend this "flags" eventually, don't we? I don't
think people will stop adding new  DIFF_OPT_ flags.
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help