I'd like to switch to git-for-windows: what are the differences with git-bash ?

[Baldurien]

Hello,

I am interested in switching to Git for Windows, even if not at a final state. 

Honestly, that's not because of Git 2.*, but because of Bash 4 and other possibilities (like, it's might seem stupid, but grep --color ) it provides since I pretty much use Git Bash for the bash (90% of the time) part more so than the Git (10% of the time).

• how can I test both without harming previous install of git-bash ? (I'm using ConEmu, I tried to use git-bash.exe from portable.... but that create a new windows, guess I'll have to google it later). Note: I used the first option of the Git bash installed ("don't touch the PATH" thing).
  
• are the application available the same in git bash and git-for-windows? (I've found grep, find, sed, vim, curl, tar, ...) . Will it be possible to add them easily with the Pacman ?
  
• which application will gain something from git-for-windows ? (I often use find, xargs and grep to lookup in a file). 

So I tested a little the portable version, as far as I could tell:

- my prompt command no longer works ; probably because of bash 4

[00:48:02] /

$ echo $PS1

\e[0;36m[\e[1;36m\t\e[0m\e[0;36m]\e[0m \e[0;33m\w\e[0m$(__git_ps1 ' \e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')\n$

bash: command substitution: line 1: syntax error near unexpected token `)'

bash: command substitution: line 1: `__git_ps1 ' (%s)')'

It seems specific to MSYS2 : http://stackoverflow.com/questions/21517281/ps1-command-substitution

I did not try with backtick.

- vim also complains (due to Windows CRLF):

line    3:

E488: Trailing characters: number^M

line    4:

E488: Trailing characters: nowrap^M

line    5:

- find seems to be a lot faster than previously. 

Regards,
Baldurien

[Johannes Schindelin]

On 2015-07-24 01:10, Baldurien wrote:

> - how can I test both without harming previous install of git-bash ?

Use the portable Git available from
https://github.com/git-for-windows/git/releases/latest

> (I'm using ConEmu, I tried to use git-bash.exe from portable.... but
> that
> create a new windows, guess I'll have to google it later). Note: I
> used the
> first option of the Git bash installed ("don't touch the PATH"
> thing).

Search the issues for ConEmu:
https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=conemu
(there has been quite a bit of talk already)

> - are the application available the same in git bash and

> git-for-windows? (I've found grep, find, sed, vim, curl, tar, ...) .
> Will
> it be possible to add them easily with the Pacman ?

git-for-windows is the project, Git Bash is just one way to operate Git.
If you mean "all the command-line tools I am used to have available at
my finger tips in Linux" when you say "are the application available",
then: no. Only the tools that are required by Git itself will be
shipped. Pacman will *not* be shipped. If you want to use Pacman, you
will need to use MSys2 directly, or the Git SDK (which is basically a
friendly fork of MSys2).

> - which application will gain something from git-for-windows ? (I

> often
> use find, xargs and grep to lookup in a file).

As stated above, the installer of Git for Windows will support Git's own
scripts. If your scripts happen to work with those, you're in luck.
Otherwise you should use MSys2 to begin with because you are clearly not
interested *only* in Git (which, however, is all Git for Windows strives
to provide).

> So I tested a little the portable version, as far as I could tell:
>
> - my prompt command no longer works ; probably because of bash 4
>
> [00:48:02] /
> $ echo $PS1

> \e[0;36m[\e[1;36m\t\e[0m\e[0;36m]\e[0m \e[0;33m\w\e[0m*$(__git_ps1 '
> \e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')*\n$

> bash: command substitution: line 1: syntax error near unexpected token
> `)'
> bash: command substitution: line 1: `__git_ps1 ' (%s)')'
>
> It seems specific to MSYS2
> : http://stackoverflow.com/questions/21517281/ps1-command-substitution
> I did not try with backtick.

Why don't you try with backtick?

> - vim also complains (due to Windows CRLF):
>
> line 3:
> E488: Trailing characters: number^M
> line 4:
> E488: Trailing characters: nowrap^M
> line 5:

`dos2unix "$HOME/.vimrc"`

> - find seems to be a lot faster than previously.

Nice, although find(1) is not really what the Git project strives to
support explicitly.

Ciao,
Johannes

[Baldurien]

Hello,

Thanks for the answer.

I don't know if my question are more MSys2 related or GIT for Windows :

Le lundi 27 juillet 2015 20:52:03 UTC+2, Johannes Schindelin a écrit :

On 2015-07-24 01:10, Baldurien wrote:

>    - how can I test both without harming previous install of git-bash ?

Use the portable Git available from
https://github.com/git-for-windows/git/releases/latest

Is setting $HOME to whatever I want sufficient to isolate setting of Git 1.9.5 from those of Git 2.4.6 ?

Is it normal that by default it does not load ~/.bashrc ? (I tried a ~/_bashrc just to see if it was like vim and _vimrc, but did not work).

 

>    (I'm using ConEmu, I tried to use git-bash.exe from portable.... but
> that
>    create a new windows, guess I'll have to google it later). Note: I
> used the
>    first option of the Git bash installed ("don't touch the PATH"
> thing).

Search the issues for ConEmu:
https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=conemu
(there has been quite a bit of talk already)

Sorry, I needed to google it (and I did not, in fact, I copied my previous command line):.

For the actual Git 1.9.5, I was using:

"%ProgramFiles(x86)%\Git\bin\sh.exe" --login -i  -new_console:d:"E:\git":C:"%ConEmuDrive%\Program Files (x86)\Git\etc\git.ico"

But for the portable version, it is almost the same:

"D:\new\updates\PortableGit-2.4.6-5th-release-candidate-32-bit.7z\bin\bash.exe" --login -i  -new_console:d:"E:\git":C:"D:\new\updates\PortableGit-2.4.6-5th-release-candidate-32-bit.7z\usr\share\git\git-for-windows.ico"

 

>    - are the application available the same in git bash and
>    git-for-windows? (I've found grep, find, sed, vim, curl, tar, ...) .
> Will
>    it be possible to add them easily with the Pacman ?

git-for-windows is the project, Git Bash is just one way to operate Git.
If you mean "all the command-line tools I am used to have available at
my finger tips in Linux" when you say "are the application available",
then: no. Only the tools that are required by Git itself will be
shipped. Pacman will *not* be shipped. If you want to use Pacman, you
will need to use MSys2 directly, or the Git SDK (which is basically a
friendly fork of MSys2).

>    - which application will gain something from git-for-windows ? (I
> often
>    use find, xargs and grep to lookup in a file).

As stated above, the installer of Git for Windows will support Git's own
scripts. If your scripts happen to work with those, you're in luck.

I think most users like me were happy to find some power tool along with GIT, especially when you know how the cmd.exe is.

And that's exactly why I now tend to expect them from a Git for Windows update to still provide them, even if the gap is important (1.9.5 -> 2.4.6)

This is the problem when you bring some nice tool with other nicer tool ;) The people becomes greedy !

The few script I have are tied to GIT (or "git bash", because these are bash3 script). I've made some script to go from one repository to another because it is easier than typing cd myrepopath avoiding using external process unless really needed (because it is/was slow).

If I resume the most common apps I use (extract done using which) on a day to day basis:

$ ./configure.bash #simply check if which XXX is empty

checking for the presence of some tools...

found ls in PATH: /usr/bin/ls

found find in PATH: /usr/bin/find

found grep in PATH: /usr/bin/grep

found sed in PATH: /usr/bin/sed

found sort in PATH: /usr/bin/sort

found cut in PATH: /usr/bin/cut

found du in PATH: /usr/bin/du

found uniq in PATH: /usr/bin/uniq

found xargs in PATH: /usr/bin/xargs

found curl in PATH: /mingw32/bin/curl

found tar in PATH: /usr/bin/tar

found gzip in PATH: /usr/bin/gzip

found gunzip in PATH: /usr/bin/gunzip

error: could not find zip in PATH.

error: could not find unzip in PATH. <- present in git-1.9.5

I don't remember really using the zip/unzip command (I more often use 7-Zip GUI), but if I want them incorporated in my GIt for Windows env, do you confirm the proper way would be to:

1. Download Git SDK installer (see note below)

2. pacman -S whatever-package-contains-zip

3. Enjoy the whole.

4. Prepare an installer if I want to broadcast a copy on other post or use the portable stuff

Note: while using the Git SDK installer, I ran into the following errors: SF download server are offline (?) ; it was fixed by providing new mirror URL (see issue #702)

The file in /etc/pacman.d needs to be update manually, before relauching the git-sdk-installer-1.0.0-rc-3-64.7z.exe, eventually cleaning the database lock before.

By the way, in GIT 1.9.5 the VIM did not contain the runtime file {~9MiB), but there are now present in the portable PortableGit-2.4.6-5th-release-candidate-32-bit.7z.

Is that intended or due to the MSys2 package ?

Will it stays in future release ?

> So I tested a little the portable version, as far as I could tell:
>
> - my prompt command no longer works ; probably because of bash 4
>
> [00:48:02] /
> $ echo $PS1
> \e[0;36m[\e[1;36m\t\e[0m\e[0;36m]\e[0m \e[0;33m\w\e[0m*$(__git_ps1 '
> \e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')*\n$
> bash: command substitution: line 1: syntax error near unexpected token
> `)'
> bash: command substitution: line 1: `__git_ps1 ' (%s)')'
>
> It seems specific to MSYS2
> : http://stackoverflow.com/questions/21517281/ps1-command-substitution
> I did not try with backtick.

Why don't you try with backtick?

Because I hate backticks :) on AZERTY keyboard, \$() is far easier to type than backtick (Alt Gr + 7, then Space .... and another Alt Gr + 8 for the backslash). 

Well, with backticks it works (but I still hate them) although I need to backslashes the twice .:

git)    ps1_bits+="\`__git_ps1 '${space}\e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m'\`"        ;;

Instead of:

git)    ps1_bits+="\$(__git_ps1 '${space}\e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')"        ;;

> - vim also complains (due to Windows CRLF):
>
> line    3:
> E488: Trailing characters: number^M
> line    4:
> E488: Trailing characters: nowrap^M
> line    5:

`dos2unix "$HOME/.vimrc"`

Yes. While not using dos2unix, I've fixed this one.

But I don't understand why vim suddenly restrict _vimrc line ending to LF only (while the "_vimrc" filename is specific to windows). 

That, and the fact it can open CRLF encoded file without errors, make this one quite stupid - like the whole line encoding problem.

 

> - find seems to be a lot faster than previously.

Nice, although find(1) is not really what the Git project strives to
support explicitly.

For the fun facts: on my E:/git folder (a SSD), with 53415 files and 5.4GiO of data:

time find (with Git 2.4.6)

real    0m11.349s

user    0m2.277s

sys     0m3.244s

time find (with Git 1.9.5)

real    2m34.342s

user    0m4.461s

sys     0m12.277s

As you can see, you gain ... something :)

 

Ciao,
Johannes

[Johannes Schindelin]

Hi,

On 2015-07-28 01:28, Baldurien wrote:

> Le lundi 27 juillet 2015 20:52:03 UTC+2, Johannes Schindelin a écrit :
>
>> On 2015-07-24 01:10, Baldurien wrote:
>>
>> > - how can I test both without harming previous install of git-bash ?
>>
>> Use the portable Git available from
>> https://github.com/git-for-windows/git/releases/latest
>
> Is setting $HOME to whatever I want sufficient to isolate setting of
> Git
> 1.9.5 from those of Git 2.4.6 ?

That is not necessary unless you you want to use different
$HOME/.gitconfig settings.

> Is it normal that by default it does not load ~/.bashrc ? (I tried a
> ~/_bashrc just to see if it was like vim and _vimrc, but did not work).

Yes: https://github.com/git-for-windows/git/issues/191 Contributions
welcome!

>> > - which application will gain something from git-for-windows ? (I
>> > often
>> > use find, xargs and grep to lookup in a file).
>>
>> As stated above, the installer of Git for Windows will support Git's
>> own
>> scripts. If your scripts happen to work with those, you're in luck.
>>
> I think most users like me were happy to find some power tool along
> with
> GIT, especially when you know how the cmd.exe is.

> And that's exactly why I now tend to expect them from a *Git for
> Windows*

> update to still provide them, even if the gap is important (1.9.5 ->
> 2.4.6)

It is actually 1.9.5 -> 2.5.0 now.

> This is the problem when you bring some nice tool with other nicer tool
> ;)
> The people becomes greedy !

Well, I become greedy back: when do you start contributing? ;-)

> error: could not find zip in PATH.
> error: could not find unzip in PATH. <- present in git-1.9.5

It is true that it used to be in Git for Windows 1.9.5. It was added in
https://github.com/msysgit/msysgit/commit/e9b7f92b and it is very
unclear to me why it was added.

In general it would be a good idea to use MSys2 (or even Cygwin) if you
want to run general POSIX scripts on Windows (instead of abusing Git for
Windows for that purpose): they both come with proper package management
systems and many packages to choose from. If you must, you can also use
the Git SDK (which is essentially MSys2 pre-configured to build and
develop Git for Windows), but please note that the main purpose of the
Git SDK is really to support developers who want to contribute to Git
for Windows.

> I don't remember really using the zip/unzip command (I more often use
> 7-Zip
> GUI), but if I want them incorporated in my GIt for Windows env, do you
> confirm the proper way would be to:
>
> 1. Download Git SDK installer (see note below)
> 2. pacman -S whatever-package-contains-zip

You may want to run `pacman -Syu` before that to update the installed
packages and the package index.

> 3. Enjoy the whole.
> 4. Prepare an installer if I want to broadcast a copy on other post or
> use
> the portable stuff

Basically, yes.

> *Note:* while using the Git SDK installer, I ran into the following

> errors:
> SF download server are offline (?) ; it was fixed by providing new
> mirror
> URL (see issue #702

> <https://github.com/Alexpux/MINGW-packages/issues/702>)

> The file in /etc/pacman.d needs to be update manually, before
> relauching
> the git-sdk-installer-1.0.0-rc-3-64.7z.exe, eventually cleaning the
> database lock before.

The git-sdk-installer version 1.0.0 already fixed the issue.

> By the way, in GIT 1.9.5 the VIM did not contain the runtime file
> {~9MiB),
> but there are now present in the portable
> PortableGit-2.4.6-5th-release-candidate-32-bit.7z.
> Is that intended or due to the MSys2 package ?

It is most likely due to the MSys2 package. But which file are you
talking about?

> Will it stays in future release ?

You tell me! ;-)

Seriously, in the course of addressing
https://github.com/git-for-windows/git/issues/262 I went so far as to
export from process monitor all files that were used during a complete
run of the test suite (which passed BTW), and of regular interactive
usage like using vim and pushing via SSH. If some ~9MB file would have
not shown up in that list of files, I would definitely have had a look,
I think ;-)

But I like to be proven wrong on such things.

>> > So I tested a little the portable version, as far as I could tell:
>> >
>> > - my prompt command no longer works ; probably because of bash 4
>> >
>> > [00:48:02] /
>> > $ echo $PS1
>> > \e[0;36m[\e[1;36m\t\e[0m\e[0;36m]\e[0m \e[0;33m\w\e[0m*$(__git_ps1 '
>> > \e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')*\n$
>> > bash: command substitution: line 1: syntax error near unexpected token
>> > `)'
>> > bash: command substitution: line 1: `__git_ps1 ' (%s)')'
>> >
>> > It seems specific to MSYS2
>> > : http://stackoverflow.com/questions/21517281/ps1-command-substitution
>> > I did not try with backtick.
>>
>> Why don't you try with backtick?
>>
>
> Because I hate backticks :) on AZERTY keyboard, \$() is far easier to
> type
> than backtick (Alt Gr + 7, then Space .... and another Alt Gr + 8 for
> the
> backslash).
>
> Well, with backticks it works (but I still hate them) although I need
> to
> backslashes the twice .:
>

> git) ps1_bits+="*\`*__git_ps1
> '${space}\e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m'*\`*" ;;

>
> Instead of:
>
> git) ps1_bits+="\$(__git_ps1
> '${space}\e[0;31m(\e[1;31m%s\e[0m\e[0;31m)\e[0m')" ;;

Good to know. This tip would probably make for a good addition to our
wiki.

>> > - vim also complains (due to Windows CRLF):
>> >
>> > line 3:
>> > E488: Trailing characters: number^M
>> > line 4:
>> > E488: Trailing characters: nowrap^M
>> > line 5:
>>
>> `dos2unix "$HOME/.vimrc"`
>>
>>
> Yes. While not using dos2unix, I've fixed this one.
>
> But I don't understand why vim suddenly restrict _vimrc line ending to
> LF
> only (while the "_vimrc" filename is specific to windows).
> That, and the fact it can open CRLF encoded file without errors, make
> this
> one quite stupid - like the whole line encoding problem.

It is MSys2's vim, it is possible that a patch we carried in msysGit
still wants to be ported over. It would require a little bit of work;
Yet another excellent opportunity for you to contribute...

>> > - find seems to be a lot faster than previously.
>>
>> Nice, although find(1) is not really what the Git project strives to
>> support explicitly.
>>
>
> For the fun facts: on my E:/git folder (a SSD), with 53415 files and
> 5.4GiO
> of data:
>
> time find (with Git 2.4.6)
> real 0m11.349s
> user 0m2.277s
> sys 0m3.244s
>
> time find (with Git 1.9.5)
> real 2m34.342s
> user 0m4.461s
> sys 0m12.277s
>
> As you can see, you gain ... something :)

Indeed!

Thank you for the feedback! I am looking forward to more contributions
from you ;-)

Ciao,
Johannes

[Baldurien]

Hello,

I truncated the replies, because it is somehow unreadable using the web interface of Google Groups (eg: the Web interface sees the mail as HTML, with a variable width font, instead of fixed one..) 

> Is it normal that by default it does not load ~/.bashrc ? (I tried a 

> ~/_bashrc just to see if it was like vim and _vimrc, but did not work).

Yes: https://github.com/git-for-windows/git/issues/191 Contributions
welcome!

Nice. I sourced ~/.bashrc from ~/.bash_profile and it worked.

> This is the problem when you bring some nice tool with other nicer tool 
> ;) 
> The people becomes greedy ! 
Well, I become greedy back: when do you start contributing? ;-)  

Yeah.

If that is not too hard (I am mostly a Java developers, even though I'm doing C++ at work from time to time), I'm interested to add a small patch: the pwd -W result is wrong.

/usr/share/cygwin get translated to C:/Program Files/Git/usr/share/cygwin but it should be C:\Program Files\Git\usr\share\cygwin

The path separator is \, not /. This is particularly true in the Open file box... My use case is the following: I'm seeing git status, I want to open an external editor (like Notepad++), so I type pwd -W and copy/paste that in an Open File prompt or even do explorer $(echo $(pwd -W)/README.md |sed 's@/@\\@g' ), but I can't copy/paste the path as is.

This is more a problem with Windows XP, since Windows 7 comes with a search bar (below the title bar) that accept the /, but not the other. Yes, it is really stupid... like the long path by the way... And I'm sure that you can type \\127.0.0.1\<the long path> in the explorer...

And also I think that is more related to MSYS2 than Git for Windows. 

> error: could not find zip in PATH. 

> error: could not find unzip in PATH. <- present in git-1.9.5

It is true that it used to be in Git for Windows 1.9.5. It was added in
https://github.com/msysgit/msysgit/commit/e9b7f92b and it is very
unclear to me why it was added.

 

Well, I don't understand why unzip is here in 1.9.5 and not zip... 

How the hell do we zip file ? :)

 

In general it would be a good idea to use MSys2 (or even Cygwin) if you
want to run general POSIX scripts on Windows (instead of abusing Git for
Windows for that purpose): they both come with proper package management
systems and many packages to choose from. If you must, you can also use
the Git SDK (which is essentially MSys2 pre-configured to build and
develop Git for Windows), but please note that the main purpose of the
Git SDK is really to support developers who want to contribute to Git
for Windows.

I understand your point of view, since - as far as I understand - you provide a (native) git that sometimes requires bash/perl to work. Thus, I should not expect much from what is in the scope of those bash/perl script otherwise.

.

But I don't want to use both Git for Windows and Msys2: if I do it, 

- I would work with Msys2 bash 

- I would do git related stuff (commit, push, ...) using the Git for Windows MSYS2 env

This is not really practical, and I should either

- stick with Msys2 since they also provide a Git package but I don't know what are the differences (apart from "native" and long path support*)

- clone Git SDK and add the package I require.

I'm not in the case of a missing package/tool and I don't need POSIX that much. So I'll stick with Git for Windows, especially when the 2.5.0 is out, and:

- The tools I use (maven, java) expect Windows based path syntax/separator (ex: Java expect CLASSPATH to contains a ";" separator, not a ":"). 

- The other (find, grep) works... and find also accepts Windows syntax (find e:\git\externals works).

So I don't really see POSIX issues ... as long my own personal scripts works in Bash 4, that's fine by me.

* funny enough, Java supports them natively using UNC path too ... I often use a little class that delete such file left by some program. Which means that Java based client such as JGit should natively support those long path :)

 

> By the way, in GIT 1.9.5 the VIM did not contain the runtime file
> {~9MiB),
> but there are now present in the portable
> PortableGit-2.4.6-5th-release-candidate-32-bit.7z.
> Is that intended or due to the MSys2 package ?

It is most likely due to the MSys2 package. But which file are you
talking about?

> Will it stays in future release ?

You tell me! ;-)

Seriously, in the course of addressing
https://github.com/git-for-windows/git/issues/262 I went so far as to
export from process monitor all files that were used during a complete
run of the test suite (which passed BTW), and of regular interactive
usage like using vim and pushing via SSH. If some ~9MB file would have
not shown up in that list of files, I would definitely have had a look,
I think ;-)

But I like to be proven wrong on such things.

http://www.vim.org/download.php#pc "Runtime files vim##rt.zip vim74rt.zip"

With msysGit I downloaded the whole and dropped in the share folder.

In the preview I tested (2.4.6.windows.1), this is here too.

=> It is also in Git 2.5.0. And ... it is at least 9MiB zipped file (24 unzipped).  ... and I honestly thing that zip/unzip are smaller (but that's not a reason ;))

I think in the msysGit 1.9.5 release, this was truncated because stuff like edit mode are not really useful for GIT (apart from merging using vim ?)

Please review my edit:  https://github.com/git-for-windows/git/wiki/MSYS2-Notes (and for reference I edited it directly because it was easier for me and I did not see a way to fork the Wiki without the whole repo [which don't fork the wiki !]).

 

It is MSys2's vim, it is possible that a patch we carried in msysGit
still wants to be ported over. It would require a little bit of work;
Yet another excellent opportunity for you to contribute...

I don't think this should be "patched".

The same behavior occurs on my Gentoo 4.0.5-gentoo with VIM 7.4: if someone copy its _vimrc to his Linux home folder, then it will fail => the file, without CR, is "portable".

Or rather the patch should be "vim should accept CRLF in _vimrc" in Linux and Windows.

But like the path separator, CRLF is a real mess. 

Regards,

Baldurien

 

[Baldurien]

On vim runtimes: it is truncated in 1.9.5 (see portable version), and if you remove some locale from GIT, you should probably remove locales from the tutor directory of vim.

But I don't know vim enough to tell if it will break something or not.

Here is the content, sorted by size:

in 1.9.5:!

$ du -d1 -h -a vim74/|sort -k 1h

1.0K    vim74/ftoff.vim

12K     vim74/plugin

12K     vim74/scripts.vim

40K     vim74/menu.vim

56K     vim74/optwin.vim

68K     vim74/filetype.vim

100K    vim74/syntax

424K    vim74/autoload

1.9M    vim74/vim.exe

2.1M    vim74/tutor

4.7M    vim74/

in 2.5.0:

$ du -d1 -h -a vim74/|sort -k 1h

1.0K    vim74/delmenu.vim

1.0K    vim74/ftoff.vim

1.0K    vim74/ftplugof.vim

1.0K    vim74/indoff.vim

4.0K    vim74/bugreport.vim

4.0K    vim74/evim.vim

4.0K    vim74/ftplugin.vim

4.0K    vim74/gvimrc_example.vim

4.0K    vim74/indent.vim

4.0K    vim74/mswin.vim

4.0K    vim74/vimrc_example.vim

12K     vim74/scripts.vim

20K     vim74/rgb.txt

40K     vim74/menu.vim

40K     vim74/synmenu.vim

56K     vim74/optwin.vim

65K     vim74/plugin

72K     vim74/filetype.vim

73K     vim74/tools

77K     vim74/colors

140K    vim74/print

146K    vim74/compiler

149K    vim74/macros

282K    vim74/keymap

608K    vim74/ftplugin

649K    vim74/indent

1.8M    vim74/autoload

2.3M    vim74/tutor

3.3M    vim74/spell

6.0M    vim74/doc

6.1M    vim74/syntax

22M     vim74/

[Johannes Schindelin]

Hi Baldurien,

On 2015-08-19 00:43, Baldurien wrote:

> I'm interested to add a small patch: the pwd -W result is wrong.
>
> /usr/share/cygwin get translated to C:/Program
> Files/Git/usr/share/cygwin
> but it should be C:\Program Files\Git\usr\share\cygwin

That is more a philosophical matter, as forward slashes are accepted by
Windows in many cases (but not all, as you pointed out).

As for `pwd -W`, I guess that forward slashes were chosen because they
do not need to be escaped in shell arguments.

If you want to do something about that option, here are two important
notes:

- you *need* to make sure that existing users are unaffected by your
change. You cannot simply break other people's setups just because. So
maybe another option (`-X`, kind of an "upgraded" `-W`, incremented by
one) is the way to go?

- the patch in question is here:
https://github.com/git-for-windows/MSYS2-packages/blob/master/bash/0006-bash-4.3-add-pwd-W-option.patch.
In order to rebuild the bash, you will want to follow the description
here:
https://github.com/git-for-windows/git/wiki/Package-management#rebuild-packages.
Then you will want to run `git init && git add . && git commit -m base`
in /usr/src/MSYS2-packages/bash/src/bash-4.3/ and patch builtins/cd.def,
then test, then export the patch and add it to
/usr/src/MSYS2-packages/bash, then contribute it all by opening a Pull
Request.

>> error: could not find zip in PATH.
>>
>> error: could not find unzip in PATH. <- present in git-1.9.5
>>
>> It is true that it used to be in Git for Windows 1.9.5. It was added
>> in
>> https://github.com/msysgit/msysgit/commit/e9b7f92b

>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmsysgit%2Fmsysgit%2Fcommit%2Fe9b7f92b&sa=D&sntz=1&usg=AFQjCNHy1Anld3twgfU3imPP6N8UUbQBlA>

>> and it is very
>> unclear to me why it was added.
>>
>
> Well, I don't understand why unzip is here in 1.9.5 and not zip...
> How the hell do we zip file ? :)

You use `git archive` or the Windows Explorer, like everybody else :-P

Seriously again, if you really care about `zip.exe` enough, you will
install the Git SDK, build an installer (as described here:
https://github.com/git-for-windows/git/wiki/Making-an-installer), patch
`/usr/src/build-extra/make-file-list.sh` -- preferably only adding
`zip.exe`, not the entire `zip` package with documentation and stuff --
build another installer, compare the size, and then open a Pull Request
in https://github.com/git-for-windows/build-extra detailing why you want
it, and stating the penalty (i.e. the size difference of the installer).

> But I don't want to use both Git for Windows and Msys2

By using Git for Windows, you *already* use a stripped down MSys2. The
difference is not all that big, except that you have to configure Git
yourself instead of using the convenient end-user installer. And you
probably would want to install Start Menu shortcuts yourself, too. But
that's it.

>> > By the way, in GIT 1.9.5 the VIM did not contain the runtime file
>> > {~9MiB),
>> > but there are now present in the portable
>> > PortableGit-2.4.6-5th-release-candidate-32-bit.7z.
>> > Is that intended or due to the MSys2 package ?
>>
>> It is most likely due to the MSys2 package. But which file are you
>> talking about?
>>
>> > Will it stays in future release ?
>>
>> You tell me! ;-)
>>
>> Seriously, in the course of addressing
>> https://github.com/git-for-windows/git/issues/262 I went so far as to
>> export from process monitor all files that were used during a complete
>> run of the test suite (which passed BTW), and of regular interactive
>> usage like using vim and pushing via SSH. If some ~9MB file would have
>> not shown up in that list of files, I would definitely have had a
>> look,
>> I think ;-)
>>
>> But I like to be proven wrong on such things.
>>
>
> http://www.vim.org/download.php#pc "Runtime files vim##rt.zip
> vim74rt.zip"

What I meant is: What is the path to that runtime file inside a Git for
Windows installation. I am still a bit puzzled...

> I think in the msysGit 1.9.5 release, this was truncated because stuff
> like
> edit mode are not really useful for GIT (apart from merging using vim
> ?)

I use vim in edit mode pretty frequently. Unless you mean "ed" mode...

>> It is MSys2's vim, it is possible that a patch we carried in msysGit
>> still wants to be ported over. It would require a little bit of work;
>> Yet another excellent opportunity for you to contribute...
>>
>
> I don't think this should be "patched".
> The same behavior occurs on my Gentoo 4.0.5-gentoo with VIM 7.4: if
> someone
> copy its _vimrc to his Linux home folder, then it will fail => the
> file,
> without CR, is "portable".

Well, but Gentoo never had CR/LF line endings. Windows did, so we are in
a slightly different situation here.

I still think it would be a welcome contribution if you made MSys2's vim
accept CR/LF endings in its vimrc.

Ciao,
Johannes

[Johannes Schindelin]

Hi Baldurien,

On 2015-08-19 00:56, Baldurien wrote:
> On vim runtimes: it is truncated in 1.9.5

I guess I do not understand what you mean by "truncated". For me,
"truncated" means that a file is made shorter by cutting it off at some
offset.

Ciao,
Johannes

[Baldurien]

Hello,

By truncated I meant: the actual folder (in 1.9.5) is smaller than the one in 2.5.0 and vim runtime.