Re: Why is ident_is_sufficient different on Windows?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Max Horn <max@xxxxxxxxx> writes:

> static int ident_is_sufficient(int user_ident_explicitly_given)
> {
> #ifndef WINDOWS
> 	return (user_ident_explicitly_given & IDENT_MAIL_GIVEN);
> #else
> 	return (user_ident_explicitly_given == IDENT_ALL_GIVEN);
> #endif
> }
>
>
> According to git blame, this was introduced here:
>
> commit 5aeb3a3a838b2cb03d250f3376cf9c41f4d4608e
> Author: Junio C Hamano <gitster@xxxxxxxxx>
> Date:   Sun Jan 17 13:54:28 2010 -0800
>
>     user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere
>
>
> The commit message sounds as if this was only a refactoring, but
> the patch to me look as if it changes behaviour, too. Of course
> this could very well be false, say due to code elsewhere that
> already caused Windows to behave differently; I wouldn't know.
>
> Still, I wonder: Why does this difference exist?

Sorry but I do not recall why these ifdefs are there.  The commit
did this to builtin-commit.c:

-               if (user_ident_explicitly_given != IDENT_ALL_GIVEN)
+               if (!user_ident_sufficiently_given())

I would have written the function to always check with ALL_GIVEN
myself, and it is very likely that I was *not* the person who
noticed that the function needs to behave differently on Windows, as
I do not do Windows.

I suspect somebody from the Windows camp saw a patch I posted
without the ifdef, noticed that there is a problem to expect
IDENT_NAME_GIVEN to be set on Windows for some reason, and resulted
in a reroll of the function in that shape.

I didn't find anything in the list archive, though.  So I am
stumped.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]