[PATCH 0/2] GSoC student

[PATCH 0/2] GSoC student

[Motroni Igor]

 Hi! My name is Motroni Igor and I'm a Russian student who wants to apply for the GSoC developing some cool stuff for Git. As a microproject, I've made two little changes in my Git fork.

  Modified flag field type in rev_list_info struct in bisect.h. There is
    no need for flag field to be signed, as it is not supposed to be
    used as decimal.
  Just a minor commit to trigger Travis Ci build

 bisect.h | 2 +-
 notes.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.5.0

[PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Motroni Igor]

From: Pontifik <motroniii@gmail.com>

Signed-off-by: Pontifik <motroniii@gmail.com>
---
 bisect.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bisect.h b/bisect.h
index acd12ef..a979a7f 100644
--- a/bisect.h
+++ b/bisect.h
@@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
 
 struct rev_list_info {
 	struct rev_info *revs;
-	int flags;
+	unsigned int flags;
 	int show_timestamp;
 	int hdr_termination;
 	const char *header_prefix;
-- 
2.5.0

[PATCH 2/2] Just a minor commit to trigger Travis Ci build

[Motroni Igor]

From: Pontifik <motroniii@gmail.com>

Signed-off-by: Pontifik <motroniii@gmail.com>
---
 notes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/notes.c b/notes.c
index 88cf474..6d7da1e 100644
--- a/notes.c
+++ b/notes.c
@@ -539,8 +539,8 @@ static unsigned char determine_fanout(struct int_node *tree, unsigned char n,
 	return fanout + 1;
 }
 
-/* hex SHA1 + 19 * '/' + NUL */
-#define FANOUT_PATH_MAX 40 + 19 + 1
+/* hex SHA1 + 19 * '/' + NUL = 60 */
+#define FANOUT_PATH_MAX 60
 
 static void construct_path_with_fanout(const unsigned char *sha1,
 		unsigned char fanout, char *path)
-- 
2.5.0

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Stefan Beller]

On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor <motroniii@gmail.com> wrote:
> From: Pontifik <motroniii@gmail.com>

Here is a good place to put reasoning for why this is a good idea.
I see you have a long subject, so maybe we can shorten the first line
(down to less than ~ 80 characters) and put the longer explanation
here.

How about:

  bisect: use unsigned for flag field

  The flags are usually used as a unsigned variable, because it makes
  bit operations easier to follow.



>
> Signed-off-by: Pontifik <motroniii@gmail.com>

>From Documentation/SubmittingPatches:
> Also notice that a real name is used in the Signed-off-by: line. Please
> don't hide your real name.

> ---
>  bisect.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bisect.h b/bisect.h
> index acd12ef..a979a7f 100644
> --- a/bisect.h
> +++ b/bisect.h
> @@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
>
>  struct rev_list_info {
>         struct rev_info *revs;
> -       int flags;
> +       unsigned int flags;

You can also drop the int here and make it just
unsigned.

>         int show_timestamp;
>         int hdr_termination;
>         const char *header_prefix;
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[work]

On 03/24/2016 10:51 PM, Stefan Beller wrote:
> On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor <motroniii@gmail.com> wrote:
>> From: Pontifik <motroniii@gmail.com>
> Here is a good place to put reasoning for why this is a good idea.
> I see you have a long subject, so maybe we can shorten the first line
> (down to less than ~ 80 characters) and put the longer explanation
> here.
>
> How about:
>
>    bisect: use unsigned for flag field
>
>    The flags are usually used as a unsigned variable, because it makes
>    bit operations easier to follow.
Yep, it's definitely a good idea to shorten subject in order to put more 
explanations in body of a message.
>
>
>> Signed-off-by: Pontifik <motroniii@gmail.com>
>  From Documentation/SubmittingPatches:
>> Also notice that a real name is used in the Signed-off-by: line. Please
>> don't hide your real name.
Yep, I didn't mean to hide my real name, but coming across lots of new 
stuff confused me in distinguishing whether I'm asked to enter real name 
or nickname :)
>> ---
>>   bisect.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/bisect.h b/bisect.h
>> index acd12ef..a979a7f 100644
>> --- a/bisect.h
>> +++ b/bisect.h
>> @@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
>>
>>   struct rev_list_info {
>>          struct rev_info *revs;
>> -       int flags;
>> +       unsigned int flags;
> You can also drop the int here and make it just
> unsigned.
In fact, I just wanted to keep this code clear to understand (as I see 
this). Unsigned short is also unsigned, but a reader should know that 
"unsigned" type stands for "unsigned int". Anyway, I'll keep this in 
mind in future, thanks a lot.
>>          int show_timestamp;
>>          int hdr_termination;
>>          const char *header_prefix;
>> --
>> 2.5.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Eric Sunshine]

On Thu, Mar 24, 2016 at 4:01 PM, work <motroniii@gmail.com> wrote:
> On 03/24/2016 10:51 PM, Stefan Beller wrote:
>> On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor <motroniii@gmail.com>
>> wrote:
>>> From: Pontifik <motroniii@gmail.com>
>>
>> Here is a good place to put reasoning for why this is a good idea.
>> I see you have a long subject, so maybe we can shorten the first line
>> (down to less than ~ 80 characters) and put the longer explanation
>> here.
>>
>> How about:
>>
>>    bisect: use unsigned for flag field
>>
>>    The flags are usually used as a unsigned variable, because it makes
>>    bit operations easier to follow.
>
> Yep, it's definitely a good idea to shorten subject in order to put more
> explanations in body of a message.

It is also very important is to explain that you audited all clients
of this field and found that none of them treat the sign bit specially
(for instance, by checking the value with '< 0' or some such),
therefore such a change is safe, in addition to making the code
clearer.

As an example, a diligent reviewer may wonder why you changed this
field to 'unsigned' but not the 'flags' variable in
rev-list.c:show_bisect_vars() to which this field is assigned. This is
something your re-roll of the patch should take into consideration.

>>> diff --git a/bisect.h b/bisect.h
>>> index acd12ef..a979a7f 100644
>>> --- a/bisect.h
>>> +++ b/bisect.h
>>> @@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct
>>> commit_list *list,
>>>
>>>   struct rev_list_info {
>>>          struct rev_info *revs;
>>> -       int flags;
>>> +       unsigned int flags;
>>
>> You can also drop the int here and make it just
>> unsigned.
>
> In fact, I just wanted to keep this code clear to understand (as I see
> this). Unsigned short is also unsigned, but a reader should know that
> "unsigned" type stands for "unsigned int". Anyway, I'll keep this in mind in
> future, thanks a lot.

While it's true that 'unsigned short' is indeed never negative, the
clueful reader should never accidentally interpret bare 'unsigned' as
anything other than the native word size. However, I think what Stefan
really meant is that, in this code base, it is (somewhat) more common
to declare these "flags" variables as 'unsigned' rather than 'unsigned
int':

    % git grep -E 'unsigned\s+flags' | wc -l
    80
    % git grep -E 'unsigned\s+int\s+flags' | wc -l
    57

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Stefan Beller]

On Thu, Mar 24, 2016 at 3:56 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Thu, Mar 24, 2016 at 4:01 PM, work <motroniii@gmail.com> wrote:
>> On 03/24/2016 10:51 PM, Stefan Beller wrote:
>>> On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor <motroniii@gmail.com>
>>> wrote:
>>>> From: Pontifik <motroniii@gmail.com>
>>>
>>> Here is a good place to put reasoning for why this is a good idea.
>>> I see you have a long subject, so maybe we can shorten the first line
>>> (down to less than ~ 80 characters) and put the longer explanation
>>> here.
>>>
>>> How about:
>>>
>>>    bisect: use unsigned for flag field
>>>
>>>    The flags are usually used as a unsigned variable, because it makes
>>>    bit operations easier to follow.
>>
>> Yep, it's definitely a good idea to shorten subject in order to put more
>> explanations in body of a message.
>
> It is also very important is to explain that you audited all clients
> of this field and found that none of them treat the sign bit specially
> (for instance, by checking the value with '< 0' or some such),
> therefore such a change is safe, in addition to making the code
> clearer.
>
> As an example, a diligent reviewer may wonder why you changed this
> field to 'unsigned' but not the 'flags' variable in
> rev-list.c:show_bisect_vars() to which this field is assigned. This is
> something your re-roll of the patch should take into consideration.
>
>>>> diff --git a/bisect.h b/bisect.h
>>>> index acd12ef..a979a7f 100644
>>>> --- a/bisect.h
>>>> +++ b/bisect.h
>>>> @@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct
>>>> commit_list *list,
>>>>
>>>>   struct rev_list_info {
>>>>          struct rev_info *revs;
>>>> -       int flags;
>>>> +       unsigned int flags;
>>>
>>> You can also drop the int here and make it just
>>> unsigned.
>>
>> In fact, I just wanted to keep this code clear to understand (as I see
>> this). Unsigned short is also unsigned, but a reader should know that
>> "unsigned" type stands for "unsigned int". Anyway, I'll keep this in mind in
>> future, thanks a lot.
>
> While it's true that 'unsigned short' is indeed never negative, the
> clueful reader should never accidentally interpret bare 'unsigned' as
> anything other than the native word size. However, I think what Stefan
> really meant is that, in this code base, it is (somewhat) more common
> to declare these "flags" variables as 'unsigned' rather than 'unsigned
> int':
>
>     % git grep -E 'unsigned\s+flags' | wc -l
>     80
>     % git grep -E 'unsigned\s+int\s+flags' | wc -l
>     57

This is what I meant. (I did not give my grep terms as reasoning as they were
not as exactly as yours. Redoing the search using your more exact terms
however makes me wonder if my advice was the right thing.

% git grep -E 'unsigned\s+int\s+flags' ./*.h | wc -l
16
% git grep -E 'unsigned\s+flags' ./*.h | wc -l
17

So there is no pattern that the version without int is more common.
Maybe my exposure to the code was accidentally in a way such that
I ever only saw the version without int.

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> Maybe my exposure to the code was accidentally in a way such that
> I ever only saw the version without int.

The older part of the code tends to spell flag words with "unsigned"
without "int", which is primarily historical fault of mine.

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[work]

Yep. Thanks for your remarks. I have made a bit more research about 
using old rev_list_info struct (with signed int flag) and realized, that 
it doesn't appear in expressions, where using signed integer will differ 
from unsigned one.
I'll take using 'unsigned' instead of 'unsigned int' in account, so if 
needed, I can remake the patch in order to get it accepted.

On 03/25/2016 09:18 AM, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> Maybe my exposure to the code was accidentally in a way such that
>> I ever only saw the version without int.
> The older part of the code tends to spell flag words with "unsigned"
> without "int", which is primarily historical fault of mine.
>

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

[Eric Sunshine]

[please respond inline rather than top-posting]

On Fri, Mar 25, 2016 at 8:53 AM, work <motroniii@gmail.com> wrote:
> On 03/25/2016 09:18 AM, Junio C Hamano wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>> Maybe my exposure to the code was accidentally in a way such that
>>> I ever only saw the version without int.
>>
>> The older part of the code tends to spell flag words with "unsigned"
>> without "int", which is primarily historical fault of mine.
>
> Yep. Thanks for your remarks. I have made a bit more research about using
> old rev_list_info struct (with signed int flag) and realized, that it
> doesn't appear in expressions, where using signed integer will differ from
> unsigned one.
> I'll take using 'unsigned' instead of 'unsigned int' in account, so if
> needed, I can remake the patch in order to get it accepted.

If I read Junio's response correctly, "unsigned int" is indeed
preferred over "unsigned", so no need to change that part, but the
commit message needs improvement, and other reviewer comments should
be addressed.

And, yes, the expectation is that you will re-roll the patch (one or
more times) in response to issues pointed out by reviewers. As a GSoC
applicant, this is especially important since a big part of working on
this project is being responsive to review comments, and GSoC mentors
will examine your reviewer interaction when selecting applicants.