msysgit - Project Hosting on Google Code

Yesterday 27 hours ago issue 367 (The installer does not offer the option of using putty, even...) commented on by rreppel - Agreed. had to troubleshoot/Google this because plink wasn't in the path. Might be better to give an explicit choice with a good default. Agreed. had to troubleshoot/Google this because plink wasn't in the path. Might be better to give an explicit choice with a good default. 44 hours ago issue 80 (git-clone fails when repo contains UTF-8 filepath) commented on by kusmabite - Issue 376 has been merged into this issue. Issue 376 has been merged into this issue. 44 hours ago issue 376 (UTF8 issues) changed by kusmabite - Please search the issue tracker before filing new bugs in the future. Status: Duplicate Please search the issue tracker before filing new bugs in the future. Status: Duplicate 47 hours ago issue 376 (UTF8 issues) reported by kurtharriger - For some reason there are some files in our repository containing the trademark symbol as part of the filename (generated by some documentation tool) and these files are not correctly recognized by native windows applications. What steps will reproduce the problem? 1. open git bash 2. mkdir /c/test/; cd /c/test/ 2. touch $(printf "msys\342\204\242") # special character not displayed in cmd window but appears correct 3. ls msys??? 4. ls -1 \| sed -ne 'l' msys\342\204\242$ 5 open C:\test in windows explorer # file name appears as garbage msysâ„¢ # cross check results with cygwin 6. open cygwin bash 7. cd /cygdrive/c/test 8. ls -1 \| sed -ne 'l' msys\303\242\342\200\236\302\242$ # huh, where did the extra characters come from? 9. touch $(printf "cygwin\342\204\242") cygwin\342\204\242$ msys\303\242\342\200\236\302\242$\ 10. open c:\test with windows explorer msysâ„¢ cygwin™ What is the expected output? What do you see instead? Trademark symbol should be correctly created in filename when viewed in windows explorer. msys™ What version of the product are you using? On what operating system? Git-1.6.5.1-preview20091022.exe For some reason there are some files in our repository containing the trademark symbol as part of the filename (generated by some documentation tool) and these files are not correctly recognized by native windows applications. What steps will reproduce the problem? 1. open git bash 2. mkdir /c/test/; cd /c/test/ 2. touch $(printf "msys\342\204\242") # special character not displayed in cmd window but appears correct 3. ls msys??? 4. ls -1 \| sed -ne 'l' msys\342\204\242$ 5 open C:\test in windows explorer # file name appears as garbage msysâ„¢ # cross check results with cygwin 6. open cygwin bash 7. cd /cygdrive/c/test 8. ls -1 \| sed -ne 'l' msys\303\242\342\200\236\302\242$ # huh, where did the extra characters come from? 9. touch $(printf "cygwin\342\204\242") cygwin\342\204\242$ msys\303\242\342\200\236\302\242$\ 10. open c:\test with windows explorer msysâ„¢ cygwin™ What is the expected output? What do you see instead? Trademark symbol should be correctly created in filename when viewed in windows explorer. msys™ What version of the product are you using? On what operating system? Git-1.6.5.1-preview20091022.exe Last 7 days Nov 30, 2009 issue 375 (git clone fails ) Status changed by johannes.schindelin - Thank you! I close this issue, as it seems you identified the issues. Status: Closed Thank you! I close this issue, as it seems you identified the issues. Status: Closed Nov 30, 2009 issue 375 (git clone fails ) commented on by lukas.sobik - I checked the firewall settings at my office and git clone is failing because of them. The second problem depends on a special repo which has NTFS-illegal filenames. I checked the firewall settings at my office and git clone is failing because of them. The second problem depends on a special repo which has NTFS-illegal filenames. Nov 27, 2009 issue 261 (can't chmod 600 ~/.ssh/id_rsa when system drive is ntfs form...) commented on by johannes.schindelin - It was made _quite_ clear that if you cannot fix the issues yourself, Git for Windows is not for you. It was made _quite_ clear that if you cannot fix the issues yourself, Git for Windows is not for you. Nov 27, 2009 issue 261 (can't chmod 600 ~/.ssh/id_rsa when system drive is ntfs form...) commented on by subdigital - I really wish this issue would be reopened. I have the same exact issue on my Windows 7 box. On my Win XP box I don't have this problem, but I suspect I have some slightly different configuration there that I am not seeing. I really wish this issue would be reopened. I have the same exact issue on my Windows 7 box. On my Win XP box I don't have this problem, but I suspect I have some slightly different configuration there that I am not seeing. Nov 27, 2009 issue 375 (git clone fails ) Labels changed by johannes.schindelin - From your report is not clear what options you selected, e.g. whether chose Plink as your SSH helper. Labels: Priority-Low From your report is not clear what options you selected, e.g. whether chose Plink as your SSH helper. Labels: Priority-Low Nov 27, 2009 issue 375 (git clone fails ) reported by lukas.sobik - What steps will reproduce the problem? 1. Clone any repo from github except one of my own: $ git clone git://github.com/jquery/jquery.git Initialized empty Git repository in c:/Workspace/jquery/.git/ fatal: read error: Invalid argument What is the expected output? What do you see instead? fatal: read error: Invalid argument What version of the product are you using? On what operating system? MSysGit 1.6.5.1-preview20091022, Windows XP SP3 (German) Please provide any additional information below. When I try to bypass the git protocol and use http instead, everything works: $ git clone http://github.com/jquery/jquery.git Some repos still don't work, but I can't see there any differences. The error I get there is: $ error: git checkout-index: unable to create file Snippets Pushing, pulling, cloning from my own repos is working flawless. What steps will reproduce the problem? 1. Clone any repo from github except one of my own: $ git clone git://github.com/jquery/jquery.git Initialized empty Git repository in c:/Workspace/jquery/.git/ fatal: read error: Invalid argument What is the expected output? What do you see instead? fatal: read error: Invalid argument What version of the product are you using? On what operating system? MSysGit 1.6.5.1-preview20091022, Windows XP SP3 (German) Please provide any additional information below. When I try to bypass the git protocol and use http instead, everything works: $ git clone http://github.com/jquery/jquery.git Some repos still don't work, but I can't see there any differences. The error I get there is: $ error: git checkout-index: unable to create file Snippets Pushing, pulling, cloning from my own repos is working flawless. Nov 27, 2009 issue 374 (unable to stat japanesse characters ) reported by takushi - What steps will reproduce the problem? 1.try to add existin files... 2. one directory is called "ショートカット"(japanese characters) 3.fatal: unable to stat "ショートカット" What version of the product are you using? On what operating system? git version 1.6.5.1.1367.gcd48 Windows 7 What steps will reproduce the problem? 1.try to add existin files... 2. one directory is called "ショートカット"(japanese characters) 3.fatal: unable to stat "ショートカット" What version of the product are you using? On what operating system? git version 1.6.5.1.1367.gcd48 Windows 7 Nov 26, 2009 issue 363 (Can not push the changes to git) commented on by Thomas.Mohaupt - Switching from plink to tortoiseplink seems to solve the issue. (http://portletwork.blogspot.com/2009/01/problem-with-git-on-windows.html) ThoMo Switching from plink to tortoiseplink seems to solve the issue. (http://portletwork.blogspot.com/2009/01/problem-with-git-on-windows.html) ThoMo Nov 26, 2009 issue 363 (Can not push the changes to git) commented on by Thomas.Mohaupt - Same for me: git version 1.6.5.1.1367.gcd48 E:\projects\privat\couchapp>git push -v git@github.com:ThoMo/couchapp.git trace: built-in: git 'push' '-v' 'git@github.com:ThoMo/couchapp.git' Pushing to git@github.com:ThoMo/couchapp.git trace: run_command: 'D:\Program Files\putty\plink.exe' '-batch' 'git@github.com' 'git-receive-pack '\''ThoMo/couchapp.git'\''' trace: run_command: 'pack-objects' '--all-progress' '--revs' '--stdout' '--thin' '--delta-base-offset' trace: built-in: git 'pack-objects' '--all-progress' '--revs' '--stdout' '--thin' '--delta-base-offset' Counting objects: 296, done. Delta compression using up to 2 threads. Compressing objects: 100% (104/104), done. Writing objects: 100% (280/280), 826.21 KiB \| 20 KiB/s, done. Total 280 (delta 167), reused 279 (delta 167) Unable to read from standard input fatal: The remote end hung up unexpectedly Same for me: git version 1.6.5.1.1367.gcd48 E:\projects\privat\couchapp>git push -v git@github.com:ThoMo/couchapp.git trace: built-in: git 'push' '-v' 'git@github.com:ThoMo/couchapp.git' Pushing to git@github.com:ThoMo/couchapp.git trace: run_command: 'D:\Program Files\putty\plink.exe' '-batch' 'git@github.com' 'git-receive-pack '\''ThoMo/couchapp.git'\''' trace: run_command: 'pack-objects' '--all-progress' '--revs' '--stdout' '--thin' '--delta-base-offset' trace: built-in: git 'pack-objects' '--all-progress' '--revs' '--stdout' '--thin' '--delta-base-offset' Counting objects: 296, done. Delta compression using up to 2 threads. Compressing objects: 100% (104/104), done. Writing objects: 100% (280/280), 826.21 KiB \| 20 KiB/s, done. Total 280 (delta 167), reused 279 (delta 167) Unable to read from standard input fatal: The remote end hung up unexpectedly Nov 26, 2009 issue 373 ('git svn clone' does not work with ipv6 host server) reported by aweiker - What steps will reproduce the problem? 1. git svn clone https://some.host.using.only.ipv6/svn/trunk What is the expected output? What do you see instead? I would expect the clone to actually pull down the source. Instead I get an error saying that it can not resolve the hostname. Initialized empty Git repository in c:/src/tmp/trunk/.git/ RA layer request failed: PROPFIND request failed on '/svn/trunk': PROPFIND of '/svn/trunk': Could not resolve hostname `some.svn.host.using.only.ipv6': No address associated with name (https://some.svn.host.using.only.ipv6 at D:\utils\git/libexec/git- core/git-svn line 1699 What version of the product are you using? On what operating system? git version 1.6.4.msysgit.0 git-svn 1.6.5.1.1367.gcd48 OS: Windows 7 x64 Please provide any additional information below. It looks like by default most subversion binaries for windows are built with IPv6 disabled. The only version I could find are the ones from SlikSVN, so I'm assuming the libraries being included here are similar in that they are not compiled with IPv6 enabled. Issue 182 is a related IPv6 issue which was resolve earlier this year. What steps will reproduce the problem? 1. git svn clone https://some.host.using.only.ipv6/svn/trunk What is the expected output? What do you see instead? I would expect the clone to actually pull down the source. Instead I get an error saying that it can not resolve the hostname. Initialized empty Git repository in c:/src/tmp/trunk/.git/ RA layer request failed: PROPFIND request failed on '/svn/trunk': PROPFIND of '/svn/trunk': Could not resolve hostname `some.svn.host.using.only.ipv6': No address associated with name (https://some.svn.host.using.only.ipv6 at D:\utils\git/libexec/git- core/git-svn line 1699 What version of the product are you using? On what operating system? git version 1.6.4.msysgit.0 git-svn 1.6.5.1.1367.gcd48 OS: Windows 7 x64 Please provide any additional information below. It looks like by default most subversion binaries for windows are built with IPv6 disabled. The only version I could find are the ones from SlikSVN, so I'm assuming the libraries being included here are similar in that they are not compiled with IPv6 enabled. Issue 182 is a related IPv6 issue which was resolve earlier this year. Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by jch2355 - (offtopic: how do I indicate which comment I am referring to with this system?) Regarding #15, I thought the topic of this is about "installer message" and the intended audience was people who want to start with git, not necessarily people who already know git from elsewhere and want to have the same git also on Windows, so requiring prior knowledge of git terminology goes against the purpose, I think. Regarding #16, there is a big difference between "dumb and does not know what a directory is" and "accepted terminology in the circle is folder not directory". My earlier suggestion was all about the latter. Both are about using words that are familiar to the targeted audience. (offtopic: how do I indicate which comment I am referring to with this system?) Regarding #15, I thought the topic of this is about "installer message" and the intended audience was people who want to start with git, not necessarily people who already know git from elsewhere and want to have the same git also on Windows, so requiring prior knowledge of git terminology goes against the purpose, I think. Regarding #16, there is a big difference between "dumb and does not know what a directory is" and "accepted terminology in the circle is folder not directory". My earlier suggestion was all about the latter. Both are about using words that are familiar to the targeted audience. Last 30 days Nov 25, 2009 issue 372 (testing) Status changed by patthoyts - do your testing elsewhere Status: Closed do your testing elsewhere Status: Closed Nov 25, 2009 issue 372 (testing) reported by RaphaelBizerra2 - zaa zaa Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sschuberth - I second that, and was about to write the same thing. I second that, and was about to write the same thing. Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by johannes.schindelin - I am really against "folder", as I completely disagree with the notion that Windows users are so dumb that they do not even know what a directory is. Windows users are no idiots. And I am also against "working tree", because that really is only understood by people who have read the Git manual, while "working directory" is something most (if not all) developers understand. I am really against "folder", as I completely disagree with the notion that Windows users are so dumb that they do not even know what a directory is. Windows users are no idiots. And I am also against "working tree", because that really is only understood by people who have read the Git manual, while "working directory" is something most (if not all) developers understand. Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by khomoutov - Git manuals do not use neither "directory" nor "folder", they call it "working tree", see [1]. May be we should use this for not to create additional source of coufusion. 1. http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html Git manuals do not use neither "directory" nor "folder", they call it "working tree", see [1]. May be we should use this for not to create additional source of coufusion. 1. http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by jch2355 - I suspect "directory" is a bad wording, working or not. If your target audience is Windows users, shouldn't you be saying "folder", not "directory"? I suspect "directory" is a bad wording, working or not. If your target audience is Windows users, shouldn't you be saying "folder", not "directory"? Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by johannes.schindelin - Okay, so y'all convinced me that autocrlf _should_ be mentioned. So here's my take: 1) let's use the term "working directory" as in "the files in your working directory". 2) yes, I think "input" is an important option; I use it in at least one of the projects where I collaborate with others. Okay, so y'all convinced me that autocrlf _should_ be mentioned. So here's my take: 1) let's use the term "working directory" as in "the files in your working directory". 2) yes, I think "input" is an important option; I use it in at least one of the projects where I collaborate with others. Nov 25, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sschuberth - OK, so the common sense seems to be to mention the autocrlf setting. Now we need to decide whether 1) it's OK use terms like "checkout" and "commit", 2) to mention the "input" option at all. From my side, the answer to 1) is yes, for the reasons given in #5. Maybe a good compromise would be to combine the bullet captions in #7 with my texts in #3. Regarding 2), I tend to mention it although it probably is not useful on Windows, just because we then have completely documented autocrlf on that wizard page, and because with the texts in #3 it gives a hint to Unix admins which might be the best choice if they also setup a Unix development machine after setting up the Windows machines for a cross-platform project. OK, so the common sense seems to be to mention the autocrlf setting. Now we need to decide whether 1) it's OK use terms like "checkout" and "commit", 2) to mention the "input" option at all. From my side, the answer to 1) is yes, for the reasons given in #5. Maybe a good compromise would be to combine the bullet captions in #7 with my texts in #3. Regarding 2), I tend to mention it although it probably is not useful on Windows, just because we then have completely documented autocrlf on that wizard page, and because with the texts in #3 it gives a hint to Unix admins which might be the best choice if they also setup a Unix development machine after setting up the Windows machines for a cross-platform project. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by patthoyts - I'll second sam's comment there. Mentioning the git config flag however briefly should provide guidance on where to look later it someone wants to adjust it and for people who actually have read the manual it explains clearly what is being set. I'll second sam's comment there. Mentioning the git config flag however briefly should provide guidance on where to look later it someone wants to adjust it and for people who actually have read the manual it explains clearly what is being set. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sam@robots.org.uk - Whatever the proposed wording, I would really prefer core.autocrlf to be mentioned for each option. Otherwise how is one supposed to change the setting after installation? Even if one manages to work out that the core.autocrlf setting is the right thing to change, one has no idea which of the three options correspond to the current setting, and if one is familiar with the settings as worded in the installer, one has no idea how to link their descriptions with the actual core.autocrlf setting. I understand the wish to make the installation process as easy as possible, but I think not mentioning the setting just makes things harder in the long run. Git is an extremely technical tool, and in my experience, obscuring the core.autocrlf setting in this way makes it harder to use. There is no way around knowing about the existence of this setting, and the ramifications for each of the options; my users had to deal with conflicts caused by the third option for some time before I had a chance to research the issue, work out that I had to set core.autocrlf=true, set it on their machines, then do another checkout of all the files that were affected, making sure to preserve their local modifications during the process. As for the use of 'input'... according to the current installer text, it can result in problems when the user wants to process text files with msys/cygwin tools. Whatever the proposed wording, I would really prefer core.autocrlf to be mentioned for each option. Otherwise how is one supposed to change the setting after installation? Even if one manages to work out that the core.autocrlf setting is the right thing to change, one has no idea which of the three options correspond to the current setting, and if one is familiar with the settings as worded in the installer, one has no idea how to link their descriptions with the actual core.autocrlf setting. I understand the wish to make the installation process as easy as possible, but I think not mentioning the setting just makes things harder in the long run. Git is an extremely technical tool, and in my experience, obscuring the core.autocrlf setting in this way makes it harder to use. There is no way around knowing about the existence of this setting, and the ramifications for each of the options; my users had to deal with conflicts caused by the third option for some time before I had a chance to research the issue, work out that I had to set core.autocrlf=true, set it on their machines, then do another checkout of all the files that were affected, making sure to preserve their local modifications during the process. As for the use of 'input'... according to the current installer text, it can result in problems when the user wants to process text files with msys/cygwin tools. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by khomoutov - Well, I did not propose to remove extensive descriptions, my suggestion was to remove mentions of "checkout" from what was proposed in comment #3. Well, I did not propose to remove extensive descriptions, my suggestion was to remove mentions of "checkout" from what was proposed in comment #3. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by kusmabite - If we're dumbing it down, how about simply: 1) Convert line endings (recommended) 2) Leave line endings alone I mean, do we really need to support setting autocrlf to "input" from the installer? What kind of users would want this setting on Windows? If we're dumbing it down, how about simply: 1) Convert line endings (recommended) 2) Leave line endings alone I mean, do we really need to support setting autocrlf to "input" from the installer? What kind of users would want this setting on Windows? Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by khomoutov - What about this? 1) Force CRLF in the working copy and LF in the repository 2) Allow any line endings in the working copy, force LF in the repository 3) Disable any line ending conversions The second clause is probably longer than required for a wizard page though. In the third clause "convesrions" can be replaced with "processing", I think. What about this? 1) Force CRLF in the working copy and LF in the repository 2) Allow any line endings in the working copy, force LF in the repository 3) Disable any line ending conversions The second clause is probably longer than required for a wizard page though. In the third clause "convesrions" can be replaced with "processing", I think. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by johannes.schindelin - The problem is not so much that the word "checkout" would be unknown. The problem is that it means totally different things in different SCMs. For example, in Subversion, a checkout is the act of updating your local data to the upstream version. With some other SCM (I have been told), it means the action when version goes for a test-ride through the whole build farm and regression tests, to be labeled as either failed or successful in the end. To much ambiguity, if you ask me. The problem is not so much that the word "checkout" would be unknown. The problem is that it means totally different things in different SCMs. For example, in Subversion, a checkout is the act of updating your local data to the upstream version. With some other SCM (I have been told), it means the action when version goes for a test-ride through the whole build farm and regression tests, to be labeled as either failed or successful in the end. To much ambiguity, if you ask me. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sschuberth - The original reasoning is not very convincing for me either, but nevertheless I felt the need for improvement. The current text still is too Unix centric and implies that files in the repository (not working tree) always have to have LF line endings, whereas the most natural thing for a Windows-only developer probably would be to set autocrlf=false and commit CRLF line endings. I also don't agree that we cannot assume that a word like "checkout" is commonly known. After all, our users are not end-users, but developers, and "checkout" is used in other VCS, too. Mentioning the corresponding autocrlf setting is somewhat optional (thus in parenthesis), but might be of interest to the more technical people. The original reasoning is not very convincing for me either, but nevertheless I felt the need for improvement. The current text still is too Unix centric and implies that files in the repository (not working tree) always have to have LF line endings, whereas the most natural thing for a Windows-only developer probably would be to set autocrlf=false and commit CRLF line endings. I also don't agree that we cannot assume that a word like "checkout" is commonly known. After all, our users are not end-users, but developers, and "checkout" is used in other VCS, too. Mentioning the corresponding autocrlf setting is somewhat optional (thus in parenthesis), but might be of interest to the more technical people. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by johannes.schindelin - Sorry to spoil the party, but I think assuming that "Checkout" is a known noun is assuming too much. I also would not mention the "core.autocrlf" config variable, as the whole point of the installer is to be user-friendly (very much including those people who did not read a single line of Git documentation before running the installer). I also take exception to the OP's notion that the source _files_ are anything but the entities in the working directory. The things in Git's internal object data bases are no files. Really. Sorry to spoil the party, but I think assuming that "Checkout" is a known noun is assuming too much. I also would not mention the "core.autocrlf" config variable, as the whole point of the installer is to be user-friendly (very much including those people who did not read a single line of Git documentation before running the installer). I also take exception to the OP's notion that the source _files_ are anything but the entities in the working directory. The things in Git's internal object data bases are no files. Really. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sschuberth - Here's what I came up with (note that I made core.autocrlf=true, which is the recommended default, the first option now): 1) Checkout Windows-style, commit Unix-style line endings Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true"). 2) Checkout as-is, commit Unix-style line endings Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Unix ("core.autocrlf" is set to "input"). 3) Checkout as-is, commit as-is Git will not perform any conversions when checking out or committing text files. Choosing this option is not recommended for cross-platform projects ("core.autocrlf" is set to "false"). I also had to shorten some lines to make them fit onto the wizard page. Does that sound good to you? Here's what I came up with (note that I made core.autocrlf=true, which is the recommended default, the first option now): 1) Checkout Windows-style, commit Unix-style line endings Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true"). 2) Checkout as-is, commit Unix-style line endings Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Unix ("core.autocrlf" is set to "input"). 3) Checkout as-is, commit as-is Git will not perform any conversions when checking out or committing text files. Choosing this option is not recommended for cross-platform projects ("core.autocrlf" is set to "false"). I also had to shorten some lines to make them fit onto the wizard page. Does that sound good to you? Nov 24, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by Johannes.Sixt - Just for the record: I said in comment #4 that I can't get any combinations of i18n.commitencoding, i18n.logoutputencoding, and LESSCHARSET to work correctly for commit messages (as opposed to patch text). But now I found what my problem was, and things now work as expected. Both 'LESSCHARST=dos' and '=latin1' work. The reason was that I incorrectly had 'encoding cp1252' in the commit object (i.e., i18n.commitencoding=cp1252) when the commit text was actually encoded in cp850. Hence, when I used 'git log', the cp850 commit messsage was taken as cp1252 and converted to cp850; of course, this messed up the umlauts. Just for the record: I said in comment #4 that I can't get any combinations of i18n.commitencoding, i18n.logoutputencoding, and LESSCHARSET to work correctly for commit messages (as opposed to patch text). But now I found what my problem was, and things now work as expected. Both 'LESSCHARST=dos' and '=latin1' work. The reason was that I incorrectly had 'encoding cp1252' in the commit object (i.e., i18n.commitencoding=cp1252) when the commit text was actually encoded in cp850. Hence, when I used 'git log', the cp850 commit messsage was taken as cp1252 and converted to cp850; of course, this messed up the umlauts. Nov 24, 2009 issue 371 (git-am doesn't work in Build Git-1.6.5.1-preview20091022.exe) reported by yzugsr - * What steps will reproduce the problem? 1. Update msysgit version to Git-1.6.5.1-preview20091022 2. git format-patch --stdlayout a..b > mb 3. git am -3 < mb * What is the expected output? What do you see instead? I got an unexpected error: "patch It does not apply to blobs recorded in its index". * What version of the product are you using? On what operating system? This error occurs in Git-1.6.5.1-preview20091022. After that, I tried to install deprecated version Git-1.6.4-preview20090730, and 1.6.4 works fine. * What steps will reproduce the problem? 1. Update msysgit version to Git-1.6.5.1-preview20091022 2. git format-patch --stdlayout a..b > mb 3. git am -3 < mb * What is the expected output? What do you see instead? I got an unexpected error: "patch It does not apply to blobs recorded in its index". * What version of the product are you using? On what operating system? This error occurs in Git-1.6.5.1-preview20091022. After that, I tried to install deprecated version Git-1.6.4-preview20090730, and 1.6.4 works fine. Nov 24, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) Status changed by sschuberth - Status: Closed Status: Closed Nov 24, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by ccoroom - Both export LESSCHARSET=latin1 from Git Bash and set LESSCHARSET=latin1 from cmd work fine. So, I don't need to turn off pager. Thank you for your kindness. Both export LESSCHARSET=latin1 from Git Bash and set LESSCHARSET=latin1 from cmd work fine. So, I don't need to turn off pager. Thank you for your kindness. Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) Owner changed by sschuberth - Owner: sschuberth Owner: sschuberth Nov 24, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) Status changed by sschuberth - I've also been unhappy with the wording for quite a while and will come up with something new. Status: Accepted I've also been unhappy with the wording for quite a while and will come up with something new. Status: Accepted Nov 24, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by sschuberth - Note it should be "LESSCHARSET", not "LESSCHARST" :-) This Korean page [1] suggests to use "export LESSCHARSET=latin1" (from Git Bash, you also need to use "export" rather than "set"). Alternatively, you could use "git config pager.log off" to disable paging for "log" in general, or maybe you could set "core.pager" to a pager that properly handles Korean characters. [1] http://kltp.kldp.net/stories.php?story=03/02/10/4828717&topic=3 Note it should be "LESSCHARSET", not "LESSCHARST" :-) This Korean page [1] suggests to use "export LESSCHARSET=latin1" (from Git Bash, you also need to use "export" rather than "set"). Alternatively, you could use "git config pager.log off" to disable paging for "log" in general, or maybe you could set "core.pager" to a pager that properly handles Korean characters. [1] http://kltp.kldp.net/stories.php?story=03/02/10/4828717&topic=3 Nov 23, 2009 issue 370 (descriptions for autocrlf setting in installer totally mysti...) reported by sam@robots.org.uk - I just can't reconcile the text in the installer with the three possible settings of core.autocrlf. It appears that the three options in the installer are, input, true and false respectively. But when I read the description for the second option, it doesn't sound like the same option that git-config(5) describes at all! "Use Windows style line endings: choose this if your source code uses a Carraige Return and a Line Feed character to end lines" When I see 'source code', I think of the files in their purest, checked-in form. So I interpret that description as the exact opposite of what it really means! I would rather label the options as follows: 1. Checkout and commit Unix-style line endings Git will use an LF character to end lines when checking out text files. When committing text files, CRLF line endings will be converted to LF. This corresponds to setting 'core.autocrlf' to 'input'. 2. Checkout Windows-style line endings, commit Unix-style line endings Git will convert LF characters into CRLF characters when checking out text files. When committing text files, CRLF line endings will be converted to LF. This corresponds to setting 'core.autocrlf' to 'true'. 3. Disable autocrlf conversion Git will not perform any conversions between CRLF and LF line endings at all. This corresponds to setting 'core.autocrlf' to 'false'. I just can't reconcile the text in the installer with the three possible settings of core.autocrlf. It appears that the three options in the installer are, input, true and false respectively. But when I read the description for the second option, it doesn't sound like the same option that git-config(5) describes at all! "Use Windows style line endings: choose this if your source code uses a Carraige Return and a Line Feed character to end lines" When I see 'source code', I think of the files in their purest, checked-in form. So I interpret that description as the exact opposite of what it really means! I would rather label the options as follows: 1. Checkout and commit Unix-style line endings Git will use an LF character to end lines when checking out text files. When committing text files, CRLF line endings will be converted to LF. This corresponds to setting 'core.autocrlf' to 'input'. 2. Checkout Windows-style line endings, commit Unix-style line endings Git will convert LF characters into CRLF characters when checking out text files. When committing text files, CRLF line endings will be converted to LF. This corresponds to setting 'core.autocrlf' to 'true'. 3. Disable autocrlf conversion Git will not perform any conversions between CRLF and LF line endings at all. This corresponds to setting 'core.autocrlf' to 'false'. Nov 23, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by ccoroom - I can see the correct commit message by using git --no-pager log Thank you for your help. But, "set LESSCHARST=dos" doesn't work for me. Things are not that easy for the Korean text. :) Anyway, is it patchable? or Do I have to use --no-pager option all the time? I can see the correct commit message by using git --no-pager log Thank you for your help. But, "set LESSCHARST=dos" doesn't work for me. Things are not that easy for the Korean text. :) Anyway, is it patchable? or Do I have to use --no-pager option all the time? Nov 23, 2009 issue 368 (PLink not working with Git GUI 1.6.5.1) commented on by jim_p...@sbcglobal.net - Thanks for the suggestion and comments. I was finally able to get GIT to work with Plink. One comment: 1. I did start a Plink session before installing GIT. Even with a Plink session running I never able to get the installer to recognize PLink was running. My work around: 1. I finally just installed GIT 1.6.5.1. 2. I changed the Plink path to removes spaces. I changed the directory from: c:\program files\putty to c:\putty. 3. I set the environment variable GIT_SSH to the new path. c:\putty\plink.exe. With these changes GIT is now functioning properly. Thanks for the suggestion and comments. I was finally able to get GIT to work with Plink. One comment: 1. I did start a Plink session before installing GIT. Even with a Plink session running I never able to get the installer to recognize PLink was running. My work around: 1. I finally just installed GIT 1.6.5.1. 2. I changed the Plink path to removes spaces. I changed the directory from: c:\program files\putty to c:\putty. 3. I set the environment variable GIT_SSH to the new path. c:\putty\plink.exe. With these changes GIT is now functioning properly. Nov 23, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by Johannes.Sixt - The problem here is that the output is passed through 'less'. 'less' does not understand non-ASCII characters and writes them in the way that you see. You can test this theory by using git --no-pager log If this displays correctly, then the problem is with 'less'. If I set set LESSCHARST=dos I can see umlauts in patch text. But I live "in codepage 850", which makes things easy. However, I can't get a combination of i18n.commitencoding, i18n.logoutputencoding, and LESSCHARSET that would display umlauts in the commit message. The problem here is that the output is passed through 'less'. 'less' does not understand non-ASCII characters and writes them in the way that you see. You can test this theory by using git --no-pager log If this displays correctly, then the problem is with 'less'. If I set set LESSCHARST=dos I can see umlauts in patch text. But I live "in codepage 850", which makes things easy. However, I can't get a combination of i18n.commitencoding, i18n.logoutputencoding, and LESSCHARSET that would display umlauts in the commit message. Nov 23, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by ccoroom - I have already tried a True Type font that contains Korean characters. I think that a console window font is not a problem. If I had a font problem, I have to see broken log text rather than escaped text like "<C7><D1><B1><DB>" I have already tried a True Type font that contains Korean characters. I think that a console window font is not a problem. If I had a font problem, I have to see broken log text rather than escaped text like "<C7><D1><B1><DB>" Nov 23, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by sschuberth - It just came to my mind that using the above installer alone probably won't fix your issue as it sets the console windows to use the Lucida Console font, which IMHO lacks the Korean characters you need. So you would have to manually specify a different True Type font for your console window under "System Menu" -> "Properties" -> "Font". It just came to my mind that using the above installer alone probably won't fix your issue as it sets the console windows to use the Lucida Console font, which IMHO lacks the Korean characters you need. So you would have to manually specify a different True Type font for your console window under "System Menu" -> "Properties" -> "Font". Nov 23, 2009 issue 369 (i18n.logoutputencoding configuration doesn't work properly.) commented on by sschuberth - Have you also set the console window to use a True Type font instead of a raster font? Please try the preliminary installer at http://threekings.tk/tmp/Git-668.exe which introduces an according option in the installer. That installer was meant to test a fix for issue #358 , which you might also want to take a look at. Have you also set the console window to use a True Type font instead of a raster font? Please try the preliminary installer at http://threekings.tk/tmp/Git-668.exe which introduces an according option in the installer. That installer was meant to test a fix for issue #358 , which you might also want to take a look at. Nov 23, 2009 issue 366 (Pushing to IIS WebDAV produces error on http-push) Owner changed by sschuberth - Owner: sschuberth Owner: sschuberth Nov 23, 2009 issue 366 (Pushing to IIS WebDAV produces error on http-push) Status changed by sschuberth - Status: Accepted Status: Accepted Nov 23, 2009 issue 367 (The installer does not offer the option of using putty, even...) commented on by sschuberth - Issue 368 has been merged into this issue. Issue 368 has been merged into this issue. Nov 23, 2009 issue 368 (PLink not working with Git GUI 1.6.5.1) changed by sschuberth - Please consult the release notes, the issue track and the mailing list before filing bugs. For support requests, please use the mailing list, not the issue tracker. Not offering PLink anymore if no PuTTY session is found was a design decision, quoting the release notes: "[...] we only offer the (Tortoise)Plink option in the installer if the presence of Plink was detected and at least one Putty session was found." For the reasons please see esp. issues 319 and 367. Closing, as a work-around is given in comments 1 and 2. Status: Duplicate Please consult the release notes, the issue track and the mailing list before filing bugs. For support requests, please use the mailing list, not the issue tracker. Not offering PLink anymore if no PuTTY session is found was a design decision, quoting the release notes: "[...] we only offer the (Tortoise)Plink option in the installer if the presence of Plink was detected and at least one Putty session was found." For the reasons please see esp. issues 319 and 367. Closing, as a work-around is given in comments 1 and 2. Status: Duplicate

issue 370 (descriptions for autocrlf setting in installer totally mysti...) commented on by sam@robots.org.uk - Whatever the proposed wording, I would really prefer core.autocrlf to be mentioned for each option. Otherwise how is one supposed to change the setting after installation? Even if one manages to work out that the core.autocrlf setting is the right thing to change, one has no idea which of the three options correspond to the current setting, and if one is familiar with the settings as worded in the installer, one has no idea how to link their descriptions with the actual core.autocrlf setting. I understand the wish to make the installation process as easy as possible, but I think not mentioning the setting just makes things harder in the long run. Git is an extremely technical tool, and in my experience, obscuring the core.autocrlf setting in this way makes it harder to use. There is no way around knowing about the existence of this setting, and the ramifications for each of the options; my users had to deal with conflicts caused by the third option for some time before I had a chance to research the issue, work out that I had to set core.autocrlf=true, set it on their machines, then do another checkout of all the files that were affected, making sure to preserve their local modifications during the process. As for the use of 'input'... according to the current installer text, it can result in problems when the user wants to process text files with msys/cygwin tools.

Whatever the proposed wording, I would really prefer core.autocrlf to be mentioned for each option. Otherwise how is one supposed to change the setting after installation? Even if one manages to work out that the core.autocrlf setting is the right thing to change, one has no idea which of the three options correspond to the current setting, and if one is familiar with the settings as worded in the installer, one has no idea how to link their descriptions with the actual core.autocrlf setting. I understand the wish to make the installation process as easy as possible, but I think not mentioning the setting just makes things harder in the long run. Git is an extremely technical tool, and in my experience, obscuring the core.autocrlf setting in this way makes it harder to use. There is no way around knowing about the existence of this setting, and the ramifications for each of the options; my users had to deal with conflicts caused by the third option for some time before I had a chance to research the issue, work out that I had to set core.autocrlf=true, set it on their machines, then do another checkout of all the files that were affected, making sure to preserve their local modifications during the process. As for the use of 'input'... according to the current installer text, it can result in problems when the user wants to process text files with msys/cygwin tools.

Yesterday

Last 7 days

Last 30 days