Re: [PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
On Sat, Dec 8, 2018 at 9:11 AM wrote: > Changes since V2: latest patch still fixes original issue - thanks > - Settled on a better name: > The common code is in compat/win32/path-utils.c/h > [...] > - The "DOS" moniker is still used for 2 reasons: > Windows inherited the "drive letter" concept from DOS, > and everybody (tm) familar with the code and the path handling > in Git is used to that wording. > Even if there was a better name, it needed to be addressed > in a patch series different from this one. > Here I want to fix a reported regression. i still disagree with this - but i understand if naming argument is out of scope for thread > And, before any cleanup is done, I sould like to ask if anybody > can build the code with VS and confirm that it works, please ? sorry but i am decidedly *not* interested in doing this. i use cygwin specifically so that i can avoid VS. hopefully someone else will be able to test. cheers
Re: [PATCH v2 1/3] git clone C:\cygwin\home\USER\repo' is working (again)
On Fri, Dec 7, 2018 at 11:04 AM wrote: > The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() > is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin > in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] > > Instead of duplicating the code, it is extracted into compat/mingw-cygwin.[ch] > Some need for refactoring and cleanup came up in the review, they are adressed > in a seperate commit. i have applied the 3 patches against current master, and my original test passes, so looks good to me. however like Johannes i take issue with the naming. as he said "mingw-cygwin" really isnt appropriate. ideally it would be "windows.h", but as that is conspicuously in use, something like these: - pc-windows - pc-win - win i disagree with him on using "win32" - that doesnt really make sense, as obviously you can compile 64-bit Git for Windows. if you wanted to go that route you would want to use something like: - windows-api - win-api - winapi further - i disagree with the "DOS" moniker being used at all. DOS is a defunkt operating system that i dont think Git has *ever* supported, so it doesnt make sense to be referring to it this way. again, a more approriate name would be something like "win_drive_prefix".
Re: [PATCH v1/RFC 1/1] 'git clone C:\cygwin\home\USER\repo' is working (again)
On Mon, Nov 26, 2018 at 11:23 PM Junio C Hamano wrote: > Sorry, but I do not see the connection to this question and the > above example. The reason why we strip C: is because the letter > that comes after that colon determines if we are talking about > absolute path (in other words, the current directory does not play a > role in determining which directory the path refers to), unlike the > POSIX codepath where it is always the first letter in the pathname. while it is true that "C:" and similar do not have a bearing on a path being absolute versus relative, it does have a bearing on what drive the entry is to be found. That is to say "C:\tmp\file.txt" does not equal "D:\tmp\file.txt". Starting with an absolute path like "C:\tmp\file.txt", after stripping that would yield "\tmp\file.txt" or "/tmp/file.txt". Starting with a relative path like "C:tmp\file.txt", after stripping that would yield "tmp\file.txt" or "tmp/file.txt". However in all cases we have lost the concept of what drive the file is located on, and Windows will assume the file exists on the current drive. So I would expect "git clone URL D:\tmp" to fail if the current directory is on "C:". Upon testing cross drive clones work fine though with this patch, so maybe the drive is added back at another place in the code.
Re: [PATCH v1/RFC 1/1] 'git clone C:\cygwin\home\USER\repo' is working (again)
On Mon, Nov 26, 2018 at 7:16 PM Junio C Hamano wrote: > I wonder if it makes the rest of the code simpler if we stripped > things like /cygdrive/c here exactly the sam way as we strip C: > For that, has_dos_drive_prefix() needs to know /cygdrive/[a-z], > which may not be a bad thing, I guess. Let's read on. With full paths, Cygwin can traverse drives: $ cd 'C:\Users' $ pwd /cygdrive/c/Users $ cd 'D:\Testing' $ pwd /cygdrive/d/Testing If you strip the drive, you can still navigate within the same drive: $ cd 'C:\Users' $ pwd /cygdrive/c/Users $ cd '\Windows' $ pwd /cygdrive/c/Windows but you can no longer traverse drives: $ cd '\Testing' sh: cd: \Testing: No such file or directory So a good first question for me would be: why are we stripping "C:" or similar in the first place? > - Is there a point in having cygwin specific variant of these, or >can we just borrow from mingw version (with some refactoring)? >Is there a point in doing so (e.g. if mingw plans to move to >reject forward slashes, attempting to share is pointless). I would say these could be merged into a "win.h" or similar. Cygwin typically leans toward the "/unix/style" while MINGW has been more tolerant of "C:\Windows\Style" and "C:/Mixed/Style" paths, i dont see that changing.
Re: [PATCH v1/RFC 1/1] 'git clone C:\cygwin\home\USER\repo' is working (again)
On Mon, Nov 26, 2018 at 11:32 AM wrote: > This is the first vesion of a patch. > Is there a chance that you test it ? I can confirm that this fixes the issue. Thank you!
Re: Cygwin Git with Windows paths
On Tue, Nov 20, 2018 at 4:36 AM Torsten Bögershausen wrote:
> Could you please post a "git diff" of your instrumented code,
> so that I/we can follow the debugging, especially what the printouts mean?
>
> I think we need to understand what is going on in abspath.c
>
diff --git a/abspath.c b/abspath.c
index 9857985..09548e5 100644
--- a/abspath.c
+++ b/abspath.c
@@ -14,6 +14,7 @@ int is_directory(const char *path)
/* removes the last path component from 'path' except if 'path' is root */
static void strip_last_component(struct strbuf *path)
{
+ printf("strip_last_component, path, [%s]\n", path->buf);
size_t offset = offset_1st_component(path->buf);
size_t len = path->len;
@@ -30,6 +31,8 @@ static void strip_last_component(struct strbuf *path)
/* get (and remove) the next component in 'remaining' and place it in 'next' */
static void get_next_component(struct strbuf *next, struct strbuf *remaining)
{
+ printf("get_next_component, next, [%s]\n", next->buf);
+ printf("get_next_component, remaining, [%s]\n", remaining->buf);
char *start = NULL;
char *end = NULL;
Re: Cygwin Git with Windows paths
On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote: > If nothing works, > it may help to add some fprintf(stderr,...) in the functions used > by 05b458c104708141d2f: > > strip_last_component(), > get_next_component() > real_path_internal() I didnt see any "real_path_internal" in the current codebase - however i added some "printf" to the other 2 and got this: $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk' get_next_component, next, [] get_next_component, remaining, [C:\cygwin64\tmp\goawk] Cloning into 'C:\cygwin64\tmp\goawk'... get_next_component, next, [] get_next_component, remaining, [C:\cygwin64\tmp\goawk/.git] fatal: Invalid path '/usr/local/cache/git/C:\cygwin64\tmp\goawk': No such file or directory
Re: Cygwin Git with Windows paths
On Sun, Nov 18, 2018 at 12:28 PM Torsten Bögershausen wrote: > Thanks for testing. > It looks as if there is more work to be done then just a simple patch. > > My last question for today: > Does > > git clone '/cgdrive/c/my/dir' > > work ? yes - these all work and resolve to same path: git clone /tmp/goawk git clone /cygdrive/c/cygwin64/tmp/goawk git clone /proc/cygdrive/c/cygwin64/tmp/goawk however i would caution that any fix should not rely on "C:", as users are allowed to install to other volumes such as "D:". Perhaps a better solution would be for Git to just take the path as is, rather than converting it to an absolute path?
Re: Cygwin Git with Windows paths
On Sun, Nov 18, 2018 at 11:15 AM Torsten Bögershausen wrote:
> But it may be that we need to pull in more stuff, similar to mingw,
> to get the C: stuff working, see
> "skip_dos_drive_prefix"
>
> And it may even be that we need a special handling for the "\" to be treated
> as "/".
>
> If you implement "skip_dos_drive_prefix" similar to mingw,
> (rename mingw into cygwin) does
>
> git clone C:/my/dir/
> work ?
I added this to "compat/cygwin.h":
#define has_dos_drive_prefix(path) \
(isalpha(*(path)) && (path)[1] == ':' ? 2 : 0)
int mingw_skip_dos_drive_prefix(char **path);
#define skip_dos_drive_prefix mingw_skip_dos_drive_prefix
and added this to "compat/cygwin.c":
int mingw_skip_dos_drive_prefix(char **path) {
int ret = has_dos_drive_prefix(*path);
*path += ret;
return ret;
}
but still, these dont work:
git clone C:/my/dir
git clone 'C:\my\dir'
Re: Cygwin Git with Windows paths
On Sun, Nov 18, 2018 at 9:41 AM Torsten Bögershausen wrote: > Thanks for the report > It seams as if "C:" is not recognized as an absolute path under > cygwin. > May be it should ? > > Does the following help ? (fully untested) that looks promising - but its not getting pulled in where it needs to be. perhaps another file need to be modified to utilize that macro?
Cygwin Git with Windows paths
Cygwin programs can handle Unix form paths: $ ls /var cache lib log run tmp and also Windows form paths: $ ls 'C:\cygwin64\var' cache lib log run tmp However current Cygwin Git cannot: $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk' Cloning into 'C:\cygwin64\tmp\goawk'... fatal: Invalid path '/home/Steven/C:\cygwin64\tmp\goawk': No such file or directory It seems the problem is that Git thinks the Windows form path is relative because it does not start with "/". A Git Bisect reveals this: 05b458c104708141d2fad211d79703b3b99cc5a8 is the first bad commit commit 05b458c104708141d2fad211d79703b3b99cc5a8 Author: Brandon Williams Date: Mon Dec 12 10:16:52 2016 -0800 real_path: resolve symlinks by hand The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole and not just an individual thread. Instead perform the symlink resolution by hand so that the calls to chdir() can be removed, making real_path one step closer to being reentrant. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano This causes problems for any non-Cygwin tools that might call Git: http://github.com/golang/go/issues/23155
Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send
On Sun, Jan 8, 2017 at 5:54 AM, Johannes Schindelin wrote: > I am curious: how do you build Git? I ask because I build Git on Windows > many times a day, and I did not encounter any link problems. My end goal is to build static native Windows Git via Cygwin and the mingw64-x86_64-gcc-core package. This is certainly possible but definitely not considered in the current Git codebase. I have a patch to config.mak.uname coming as well.
[PATCH] Makefile: put LIBS after LDFLAGS for imap-send
This matches up with the targets git-%, git-http-fetch, git-http-push and git-remote-testsvn. It must be done this way on Windows else lcrypto cannot find lgdi32 and lws2_32 Signed-off-by: Steven Penny <svnp...@gmail.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d861bd9..f0f65ea 100644 --- a/Makefile +++ b/Makefile @@ -2046,7 +2046,7 @@ git-%$X: %.o GIT-LDFLAGS $(GITLIBS) git-imap-send$X: imap-send.o $(IMAP_SEND_BUILDDEPS) GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ - $(LIBS) $(IMAP_SEND_LDFLAGS) + $(IMAP_SEND_LDFLAGS) $(LIBS) git-http-fetch$X: http.o http-walker.o http-fetch.o GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ -- 2.8.3
[PATCH] Makefile: POSIX windres
When environment variable POSIXLY_CORRECT is set, the "input -o output" syntax is not supported. http://cygwin.com/ml/cygwin/2017-01/msg00036.html Signed-off-by: Steven Penny <svnp...@gmail.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d861bd9..a2a1212 100644 --- a/Makefile +++ b/Makefile @@ -1816,7 +1816,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES git.res: git.rc GIT-VERSION-FILE $(QUIET_RC)$(RC) \ $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., ,$(GIT_VERSION) \ - -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@ + -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" -i $< -o $@ # This makes sure we depend on the NO_PERL setting itself. $(SCRIPT_PERL_GEN): GIT-BUILD-OPTIONS -- 2.8.3
[PATCH] gitk: Avoid issues with script path format
Tk’s wish for Windows can be built two ways win this provides a wish that uses GDI; it only understands Windows paths such as C:\foo\bar unix this provides a wish that uses X11; it understands Windows and Cygwin paths such as C:\foo\bar or /foo/bar Some Cygwin users will prefer to use the win version, as it avoids the large X11 dependency. However Cygwin passes the path /bin/gitk or similar and the win version of wish will not understand this. However wish does understand STDIN. Options such as --all will still work using this method as well. Signed-off-by: Steven Penny svnp...@gmail.com --- gitk-git/gitk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitk-git/gitk b/gitk-git/gitk index 90764e8..64a125d 100755 --- a/gitk-git/gitk +++ b/gitk-git/gitk @@ -1,6 +1,6 @@ #!/bin/sh # Tcl ignores the next line -*- tcl -*- \ -exec wish $0 -- $@ +exec wish $0 -- $@ # Copyright © 2005-2014 Paul Mackerras. All rights reserved. # This program is free software; it may be used, copied, modified -- 1.8.5.2 -- 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
[PATCH] web--browse: Use powershell on Windows
On Windows you can have either MinGW or Cygwin. As has been shown in this script
MinGW uses start while Cygwin uses cygstart. The cygstart command is
robust but the start command breaks on certain URLs
$ git web--browse 'http://wikipedia.org/wiki/Key__Peele'
'_Peele' is not recognized as an internal or external command,
operable program or batch file.
An alternative is to use PowerShell. PowerShell is a component of Windows and
will work with both MinGW and Cygwin.
Signed-off-by: Steven Penny svnp...@gmail.com
---
Documentation/git-web--browse.txt | 3 +--
git-web--browse.sh| 19 ---
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-web--browse.txt
b/Documentation/git-web--browse.txt
index 2de575f..02cccf9 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -33,8 +33,7 @@ The following browsers (or commands) are currently supported:
* lynx
* dillo
* open (this is the default under Mac OS X GUI)
-* start (this is the default under MinGW)
-* cygstart (this is the default under Cygwin)
+* powershell (this is the default under Windows)
* xdg-open
Custom commands may also be specified.
diff --git a/git-web--browse.sh b/git-web--browse.sh
index ebdfba6..72fbe32 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -34,7 +34,7 @@ valid_tool() {
firefox | iceweasel | seamonkey | iceape | \
chrome | google-chrome | chromium | chromium-browser | \
konqueror | opera | w3m | elinks | links | lynx | dillo | open | \
- start | cygstart | xdg-open)
+ powershell | xdg-open)
;; # happy
*)
valid_custom_tool $1 || return 1
@@ -124,13 +124,10 @@ if test -z $browser ; then
then
browser_candidates=open $browser_candidates
fi
- # /bin/start indicates MinGW
- if test -x /bin/start; then
- browser_candidates=start $browser_candidates
- fi
- # /usr/bin/cygstart indicates Cygwin
- if test -x /usr/bin/cygstart; then
- browser_candidates=cygstart $browser_candidates
+ # OS indicates Windows
+ if test -n $OS
+ then
+ browser_candidates=powershell $browser_candidates
fi
for i in $browser_candidates; do
@@ -179,11 +176,11 @@ konqueror)
;;
esac
;;
-w3m|elinks|links|lynx|open|cygstart|xdg-open)
+w3m|elinks|links|lynx|open|xdg-open)
$browser_path $@
;;
-start)
- exec $browser_path 'web-browse' $@
+powershell)
+ $browser_path saps '$@'
;;
opera|dillo)
$browser_path $@
--
1.8.5.3
--
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
git rebase -i and final newline
Sorry if I am drumming up and old issue here. I have noticed that with git rebase -i, if your final line contains a commit and no newline, git interprets that as remove this commit please. I feel that a commit should be removed only if the entire line is removed, that is the commit hash and title as well as the newline. I have noticed that the behavior is correct with git commit. Even if you omit the final newline after the commit message body, all text lines will be included. -- 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
