{"thread":{"id":"24753","subject":"Use of field flags in struct object","startedAt":"2010-08-16T08:21:04Z","lastAt":"2010-08-25T18:55:51Z","messageCount":2,"participants":["Nguyen Thai Ngoc Duy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"148183","messageId":"AANLkTikvP1oKAiFNVwZ+kqy=jLhUKP1RRET8cq=XeyzT@mail.gmail.com","threadId":"24753","inReplyTo":null,"subject":"Use of field flags in struct object","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-08-16T08:21:04Z","receivedAt":"2010-08-16T08:21:04Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nThe \"flags\" field in struct object (object.h) is used in a lot of\nplaces. The thing is, the bit definition of this field is distributed\nacross files (16 according to my \"object.flags |=\" grep). This makes\nit quite easy for one function to misunderstand a bit set by another\nfunction, for a different purpose. For instance, in upload-pack.c,\nthere is a comment:\n\n/* bits #0..7 in revision.h, #8..10 in commit.c */\n\nwhich is no longer true as commit.c has moved on and used another set\nof bits (16..19). Luckily, commit.c seems to clean its flags. But\nthere's a chance we will get bit definition overlap again.\n\nShould all of those bit definitions be gathered in one place instead?\n-- \nDuy\n"},{"id":"148985","messageId":"7v7hjesers.fsf@alter.siamese.dyndns.org","threadId":"24753","inReplyTo":"AANLkTikvP1oKAiFNVwZ+kqy=jLhUKP1RRET8cq=XeyzT@mail.gmail.com","subject":"Re: Use of field flags in struct object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-25T18:55:51Z","receivedAt":"2010-08-25T18:55:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:\n\n> The \"flags\" field in struct object (object.h) is used in a lot of\n> places. The thing is, the bit definition of this field is distributed\n> across files (16 according to my \"object.flags |=\" grep). This makes\n> it quite easy for one function to misunderstand a bit set by another\n> function, for a different purpose. For instance, in upload-pack.c,\n> there is a comment:\n>\n> /* bits #0..7 in revision.h, #8..10 in commit.c */\n>\n> which is no longer true as commit.c has moved on and used another set\n> of bits (16..19). Luckily, commit.c seems to clean its flags. But\n> there's a chance we will get bit definition overlap again.\n>\n> Should all of those bit definitions be gathered in one place instead?\n\nIn the medium term, probably yes.  In longer term, we would probably need\nto rethink how these flag bits are managed.  Some users of these bits\nmight want to be migrated to the decorate API, for example.  It may also\nbe a possible improvement to move some bits that are only relevant to\ncommit objects (e.g.  left-right traversal, treesame, boundary) to struct\ncommit and additionally widen the bitfields there.\n"}]}