Johannes Sixt wrote:
> Am 5/14/2012 0:58, schrieb Ramsay Jones:
>> BTW, Johannes, earlier you said commit be39048 ("git-sh-setup.sh: Add an pwd()
>> function for MinGW", 17-04-2012) would fix the problem on MinGW; I'm not so
>> sure it will.
>
>> [...] problem (*which MinGW shares*) is that the
>> pwd() function is defined *after* the code that sets $GIT_DIR from which the
>> rebase state directory name is derived (see git-sh-setup.sh lines 223-239).
>
> Good catch!
>
> Nevertheless, if I set GIT_EDITOR to "notepad", 'git rebase -i' works to
> some degree. Leaving aside that it does not understand LF line endings, it
> opens the git-rebase-todo file; I can edit and save it. That is, it looks
> like a usable Windows style path was passed to Notepad. (This is with
> MinGW git, of course.)
>
I was about to, confidently, proclaim that it should fail when
you run that rebase from a subdirectory ... Unfortunately, it
seems to work! *ahem*
The reason I was confident, is simply that I have seen this
pattern:
p= ...some path...
p=$(cd "$p" && pwd)
many times while debugging scripts on MinGW, so I 'know' that if
p is initially a relative path, then the result is an absolute
windows path. For example, while cwd is /home/ramsay/git then:
.git => C:/msysgit/msysgit/home/ramsay/git/.git
Whereas if p is initially an absolute windows path, then the result
is a POSIX-like path, viz:
C:/msysgit/msysgit/home/ramsay/git/.git => /usr/home/ramsay/git/.git
If you combine that with the behaviour of 'git rev-parse', thus:
$ cd /home/ramsay/git
$ git rev-parse --git-dir
.git
$ cd xdiff
$ git rev-parse --git-dir
C:/msysgit/msysgit/home/ramsay/git/.git
$
you should see "git rebase -i" invoking the editor with a POSIX
path.
[BTW, I have noticed that I sometimes get different behaviour when
I type this stuff into an interactive shell. :(]
Anyway, a bit of debugging shows that I was right, kinda! :-D
I placed a "set -x" in git-sh-setup (line 222) just before the code
to set up GIT_DIR and ran git-rebase like so:
$ cd /home/ramsay/git
$ GIT_EDITOR=false ./bin-wrappers/git rebase -i master uname >ttt 2>&1
$ cd xdiff
$ GIT_EDITOR=false ../bin-wrappers/git rebase -i master uname >sss 2>&1
$ diff ../ttt sss | more
which showed that in the subdirectory case, git was indeed invoking
the editor with a POSIX-like path. (The output files, ttt and sss, show
some other interesting/odd behaviour).
['uname' is an old branch of mine that, currently, is based on v1.7.10]
The reason it works, despite the above, is clear if you now run:
$ GIT_EDITOR=args ../bin-wrappers/git rebase -i master uname
...
+++ git var GIT_EDITOR
++ GIT_SEQUENCE_EDITOR=args
++ eval args '"$@"'
+++ args /usr/home/ramsay/git/.git/rebase-merge/git-rebase-todo
argv[0] = 'C:\msysgit\msysgit\home\ramsay\bin\args.exe'
argv[1] = 'C:/msysgit/msysgit/home/ramsay/git/.git/rebase-merge/git-rebase-todo'
++ die_abort 'Could not execute editor'
++ rm -rf /usr/home/ramsay/git/.git/rebase-merge
++ die 'Could not execute editor'
++ die_with_status 1 'Could not execute editor'
++ status=1
++ shift
++ echo 'Could not execute editor'
Could not execute editor
++ exit 1
[I'm sure you can guess what the args program looks like!]
So, the msys "path munging" of program arguments saves the day!
HTH
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html