Re: Re* [PATCH v3 04/14] refs.c: add a new update_type field to ref_update
On Wed, Jun 18, 2014 at 2:10 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ronnie Sahlberg 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
>>> ---
>>> 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.
You are right. I think I recall this too on old c compilers on legacy
unix boxens.
I have fixed this and will resend the series.
I have also checked additional enums in the sources and found 3 more places.
I sent this as a single patch to the list with the subject :
"Subject: [PATCH] enums: remove trailing ',' after last item in enum"
> But there is a curious thing:
>
> git grep -A 'enum ' master -- \*.c
>
> tells me that builtin/clean.c would fail to compile for those folks.
Most likely. It might be that there are less and less people on
really old c-compilers these days.
>
> 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_SINGLETON01
>
Thanks
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re* [PATCH v3 04/14] refs.c: add a new update_type field to ref_update
Junio C Hamano writes:
> Ronnie Sahlberg 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
>> ---
>> 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 '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_SINGLETON01
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/14] refs.c: add a new update_type field to ref_update
Ronnie Sahlberg 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
> ---
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
