On Thu, 2 Jan 2014, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> > On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
> >> See https://github.com/msysgit/git/pull/80.
> > Thanks Sebastian!
> > However, since the git.git project is not comfortable with the concept
> > of pull requests (which is why you submitted this patch via mail), I
> > believe that we have to explain the rationale in the commit message.
> > So here goes my attempt:
> Thanks; the conclusion is correct --- you need a good commit message in
> the recorded history. That does not have anything to do with
> integrating with pulling from subsystem maintainers, which we regularly
I should have pointed out that I was talking about the concept of pull
requests, not the concept of accepting pull requests from dedicated
> > On Linux, we can get away with assuming that the directory separator
> > is a forward slash, but that is wrong in general. For that purpose,
> > the is_dir_sep() function was introduced a long time ago. By using it
> > in safe_create_leading_directories(), we proof said function for use
> > on platforms where the directory separator is different from Linux'.
> Perhaps with s|Linux|POSIX|,
No, for two reasons:
* OpenVMS supports POSIX, yes? And OpenVMS does not have the forward slash
as directory separator but instead the dot, yes?
* it would be dishonest. The reason is not that we looked at the POSIX
standard when we determined how to implement
safe_create_leading_directories(), but at Linux.
> but more importantly, was there a specific error scenario that triggered
> this change?
Yes, the concrete use case that triggered the pull request whose change we
did not accept but instead would prefer Sebastian's patch is where a user
git clone <URL> C:\directory
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