Re* [PATCH v3 04/14] refs.c: add a new update_type field to ref_update
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 18, 2014, 21:10 UTC
- Message-ID
- <xmqqbntpj54t.fsf_-_@gitster.dls.corp.google.com>
- In-Reply-To
- <xmqqfvj2hs5g.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 29 quoted lines
> Ronnie Sahlberg <sahlberg@google.com> writes:
>
>> Add a field that describes what type of update this refers to. For now
>> the only type is UPDATE_SHA1 but we will soon add more types.
>>
>> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
>> ---
>> refs.c | 25 +++++++++++++++++++++----
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/refs.c b/refs.c
>> index 4e3d4c3..4129de6 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -3374,6 +3374,10 @@ int for_each_reflog(each_ref_fn fn, void *cb_data)
>> return retval;
>> }
>>
>> +enum transaction_update_type {
>> + UPDATE_SHA1 = 0,
>
> indent with SP?
>
> Unlike an array initialisation, e.g.
>
> int foo[] = { 1,2,3,4,5, };
>
> some compilers we support complain if enum definition ends with a
> trailing comma.I do recall we had fixes to drop the comma after the last element in enum definition in the past, in response real compilation breakages on some platforms. But there is a curious thing:
git grep -A<somenumber> 'enum ' master -- \*.c
tells me that builtin/clean.c would fail to compile for those folks.
Here is an off-topic "fix" that may no longer be needed.
builtin/clean.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c index 9a91515..27701d2 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -48,7 +48,7 @@ enum color_clean { CLEAN_COLOR_PROMPT = 2, CLEAN_COLOR_HEADER = 3, CLEAN_COLOR_HELP = 4, - CLEAN_COLOR_ERROR = 5, + CLEAN_COLOR_ERROR = 5 }; #define MENU_OPTS_SINGLETON 01