Re: What's cooking in git.git (May 2011, #14; Tue, 31)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2011, 19:21 UTC
Message-ID: <7v62opgxy2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DE5E1C3.8000904@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 11 quoted lines

> Am 6/1/2011 0:43, schrieb Junio C Hamano:
>> * ef/maint-win-verify-path (2011-05-27) 3 commits
>>  - verify_path: consider dos drive prefix
>>  - real_path: do not assume '/' is the path seperator
>>  - A Windows path starting with a backslash is absolute
>> 
>> J6t had a reasonable question in the discussion; has it been resolved?
>
> This particular question is resolved; I consider "verify_path: consider
> dos drive prefix" a good change. But I haven't had a chance to review the
> effects of the other two changes, yet.

The second one replaces strrchr(buf, '/') with find_last_dir_sep(buf), which I imagine would be a good change for Windows. If you are dealing with a pathname that came directly from the end user, you may see a backslash instead of a slash. If you are dealing with a pathname that is normalized earlier to use slashes, as you cannot have a backslash as a path component anyway, the change will not hurt, either (except for a slight performance penalty). The same thing can be said for the "starting with a backslash" patch.

 $ git grep -e "strrchr(.*, '/')" -e "strchr(.*, '/')"

will show a handful of instances that are not covered by the patch, that may or may not be converted in a similar way. I suspect that many of the hits are reading paths we internally generate (either by reading from the index or walking trees, concatenating paths components found with '/' in between) and should not have to be (and should not be) touched.