From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: Steven Penny <svnpenn@gmail.com>,
git@vger.kernel.org, Johannes Sixt <j.sixt@viscovery.net>
Subject: Re: [PATCH 2/2] git-sh-setup: work around Cygwin path handling gotchas
Date: Mon, 21 May 2012 19:43:32 +0100 [thread overview]
Message-ID: <4FBA8CD4.3020001@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7vehqib4kk.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> I guess you won't be shocked to hear that I don't think this patch is
>> necessary. :-P
>
> That is more or less irrelevant, not in the sense that what you say is
> irrelevant, but in the sense that something can be worked around in a
> different way alone is not a good reason to reject a patch, if its benefit
> outweigh its costs.
I completely agree.
In case it was not clear, I was not suggesting that the patch be rejected on
the basis that the problem could be worked around in a different way.
> If I speculated in the other message is correct (in short, "In Cygwin
> world, Git is compiled to use POSIX paths and would not work with Windows
> paths."), I think this "problem" is fundamentally un"fix"able.
Yes, Cygwin is essentially just another POSIX target as far as Git is
concerned. Cygwin tries hard to provide a POSIX-like environment, but it is
not possible for it to completely hide the fact that the base OS is not
actually a POSIX system.
> And from Cygwin Git, your programs (like $EDITOR and hooks) will get POSIX
> paths. It is your programs' responsibility to turn them into Windows
> paths if/as necessary.
I would say that this is the only sensible way to proceed.
However, you could imagine adding code to accommodate external windows
programs. If we limit ourselves to the text editor, for example, I could
imagine something like the diff attached below to fix up the C based git
programs. (You would need to make similar changes to the shell and perl
scripts which launch the text editor).
I would not like to see a patch based on this (or any others like it) applied,
since it is going in the wrong direction. (Why do people use Cygwin git rather
than MinGW git and vice versa). Of course, it is not my decision to make ... :-P
>> Anyway, I applied this patch tonight to give it a go. The very first test
>> I tried failed. I've attached the log of the failing test below.
>> Note that it is attempting to use "ssh" to a "host" that ends in ".../C:".
>
> Of course. That is one typical symptom that suggests my speculation was
> correct.
Heh, I was surprised that it did as well as it did; after all, it passed 44
out of the 45 tests run (from t7400-submodule-basic.sh). ;-)
> So "I don't think this patch is necessary" is irrelevant, but "This patch
> is harmful; Git on Cygwin is never supposed to use Windows paths" is very
> relevant ;-)
I agree.
ATB,
Ramsay Jones
-- >8 --
diff --git a/editor.c b/editor.c
index d834003..cf36e62 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,9 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#ifdef __CYGWIN__
+# include <sys/cygwin.h>
+#endif
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
@@ -37,6 +40,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
+#ifdef __CYGWIN__
+ char win32_path[1024];
+
+ cygwin_conv_to_full_win32_path(path, win32_path);
+ args[1] = win32_path;
+#endif
if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
return error("There was a problem with the editor '%s'.",
-- 8< --
next prev parent reply other threads:[~2012-05-21 18:45 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-06 4:24 Git commit path vs rebase path Steven Penny
2012-05-07 17:27 ` Junio C Hamano
2012-05-08 6:22 ` Johannes Sixt
2012-05-08 6:44 ` Steven Penny
2012-05-08 7:06 ` Johannes Sixt
2012-05-08 7:11 ` Steven Penny
2012-05-08 17:02 ` Junio C Hamano
2012-05-08 17:25 ` Junio C Hamano
2012-05-08 22:47 ` Steven Penny
2012-05-09 21:54 ` Junio C Hamano
2012-05-09 23:14 ` Steven Penny
2012-05-10 18:10 ` Ramsay Jones
2012-05-11 4:35 ` Steven Penny
2012-05-13 22:58 ` Ramsay Jones
2012-05-13 23:42 ` Steven Penny
2012-05-14 6:02 ` Johannes Sixt
2012-05-15 17:32 ` Ramsay Jones
2012-05-16 5:52 ` Johannes Sixt
2012-05-17 18:30 ` Ramsay Jones
2012-05-17 19:19 ` Junio C Hamano
2012-05-16 18:00 ` [PATCH 0/2] " Junio C Hamano
2012-05-16 18:00 ` [PATCH 1/2] git-sh-setup: define workaround wrappers before they are used Junio C Hamano
2012-05-17 22:36 ` Ramsay Jones
2012-05-16 18:00 ` [PATCH 2/2] git-sh-setup: work around Cygwin path handling gotchas Junio C Hamano
2012-05-16 18:51 ` Steven Penny
2012-05-16 19:02 ` Junio C Hamano
2012-05-17 23:15 ` Ramsay Jones
2012-05-18 2:34 ` Junio C Hamano
2012-05-19 0:43 ` Steven Penny
2012-05-21 18:43 ` Ramsay Jones [this message]
2012-05-21 22:24 ` Junio C Hamano
2012-05-24 18:27 ` Ramsay Jones
-- strict thread matches above, loose matches on Subject: below --
2012-05-21 23:51 Matt Seitz (matseitz)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBA8CD4.3020001@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=svnpenn@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).