From: Junio C Hamano Date: Wed, 01 Jun 2011 19:21:09 GMT Subject: Re: What's cooking in git.git (May 2011, #14; Tue, 31) Message-ID: <7v62opgxy2.fsf@alter.siamese.dyndns.org> In-Reply-To: <4DE5E1C3.8000904@viscovery.net> Johannes Sixt writes: > 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.