Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
From: Matthew Johnson mejoh...@gmail.com Good guess, I had not been thinking about the different EOLs, but all the files that show up as modified only under Fedora are .ogg files: no EOLs at all. Beware: You *think* of .ogg files as having no EOLs, but I'm sure it contains plenty of bytes with the value 10 (decimal), which *looks* like a newline to any program that is attempting to interpret and correct EOLs... Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
Others have pointed out the EOL issue, which I should have jumped on having seen it in CVS. So the third partition is not a good idea, assuming this EOL issue is the underlying problem. Just to answer your question then- While having a third partition is not fundamentally different from having Linux mount your windows partition in a dual-boot situation, I thought it might make it easier to avoid Windows from doing whatever-it-does behind the scenes. I have a Win7 build VM and it drives me nuts changing things without being asked - so maybe just my anti-win32 bias there. Interesting that you don't like the Github gui. Thats an opinion to file away, some of my developers like using a GUI, and they are going to have to start using Git this year. On 01/30/2013 05:34 PM, Matthew Johnson wrote: Please explain why I would need a third partition to do this. I am not aware of any restrictions in Git concerning what machine/partition the workspace and repository must live on, except that the remote is expected to really be remote, i.e., not on the local machine, accessible only over the net, whether via git:// scheme or some other. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
sorry I switched email in order to use a different client for this list -this was from John Fisher On 01/31/2013 09:26 AM, google spamtrap wrote: Others have pointed out the EOL issue, ... start using Git this year. On 01/30/2013 05:34 PM, Matthew Johnson wrote: Please explain why I would need a third partition to do this. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
Hi, Philip- Thanks for the response. Which 'settings' are you talking about? I am only aware of those referred to by git config --list, and I don't see anything that would explain it -- especially not in Cygwin/Windows, where only user.name and user.email are set. Yet it is from Cygwin I have done all my submits and pushes (until I resolve the discrepancy, I am not going to risk executing it commands from Fedora). BTW: your phrase work tree files in the two OS's makes it sound like you are assuming I have two different workspaces under the two OSs. What I really have is one worskpace directory viewed either under Windows/Cygwin or with the same partition mounted on a filesystem under Fedora. So the files are exactly the same, though Cygwin does funny things with representing permissions, which might turn out to be relevant here. Does Git consider a file 'modified' if only the permissions are changed? Finally, the Git Book admits that plumbing commands are not meant for the average user or even really for the command line, so more specific guidance (if plumbing is really the way to go) would certainly be needed: which plumbing commands? Is there one which will tell me why it considers a given file modified? On Thursday, January 31, 2013 12:11:02 AM UTC-8, Philip Oakley wrote: Given what you say about your .ogg file, it is probable that git's heuristic thinks they are [in some cases] binary (perhaps they are unicode files which will contain Null bytes) and won't therefore convert the line endings. The Git for Windows and Linux version of Git have slightly different default settings, so do check what they are. The line [EOL] and file [EOF] ending converstion discussions are spread over two or three man pages, and do take a bit of time to appreciate all the different normalisation issues. You can also try expanding the repo's blobs (using plumbing commands), and comparing those to the work tree files in the two OS's to which bytes are being changed, and in which direction. Philip - Original Message - *From:* Matthew Johnson javascript: *To:* git-...@googlegroups.com javascript: *Sent:* Thursday, January 31, 2013 1:22 AM *Subject:* [git-users] Re: Why Same Files show up with different Statuses in Git? Good guess, I had not been thinking about the different EOLs, but all the files that show up as modified only under Fedora are .ogg files: no EOLs at all. Even weirder, the textual files, whether HTML or JavaScript, do not have this problem. So it is hard to see how EOL inconcistency could explain why sound files are showing up as modified. On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote: I think this question on stackoverflow might help... - http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Basically the problems stems to you using the same physical repo with two different types of Git client, one built to use Windows EOL and the other using Linux EOL. When you mix the two, I.e. work with a file in Linux when it was created whilst on Windows I think you'll run into problems. I think if you set up the Windows client correctly (or specifically use the .gitattributes file for the repository) I *think* you'll be ok. HTH On Wednesday, 30 January 2013 02:40:47 UTC, Matthew Johnson wrote: I hate to cross post, but I can no longer see my message to the same effect at the Git mailing list, where I got no reply, so here we go: First, some background. I have one hard disk separated into two partitions: one for the version of Windows 7 that shipped on this rather new Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I installed and keep up-to-date). Of course, it is rather easy to access the Windows partition from the F17 partition, which I have been doing with no noticeable problems: the File Explorer equivalent, Dolphin (the KDE equivalent) will automount the Windows partition as a filesystem under /media, I only have to enter the password for 'su'. I don't think it makes a difference, but for completeness I provide the options with which I find it mounted: /dev/sda2 on /media/Windows7_OS type fuseblk (rw,nosuid,nodev,relatime, user_id=0,group_id=0,default_permissions,allow_other,blksize=4096). Anyway, the problem is this: the very same files, e.g. /media/Windows7_OS/cygwin/home/Matthew Johnson/MrEd/mr.ed/lesson1/images/home-icon.jpg show up as 'modified' when I type git status (in the mr.ed/ dir) using the F17 git client, but do not show up at all when I type git status under the Cygwin client. This problem is not on all files, only a few, predominantly in two directories. Under Windows (cygwin) git status shows nothing to commit, only untracked files, which is what I expect; only under F17 do I get several modified files -- and these have old dates (e.g. Nov 27). Yes, that is another
Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
For doc on .gitattributes, look here: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html I think the following may help too. It shows most all, if not all, of the config variable in git and what they're used for. http://www.kernel.org/pub/software/scm/git/docs/git-config.html and http://git-scm.com/book/en/Customizing-Git-Git-Configuration and on this page: quote core.autocrlf If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work. Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code: $ git config --global core.autocrlf true If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input: $ git config --global core.autocrlf input This setup should leave you with CRLF endings in Windows checkouts but LF endings on Mac and Linux systems and in the repository. If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false: $ git config --global core.autocrlf false /quote On Thu, Jan 31, 2013 at 1:53 PM, Matthew Johnson mejoh...@gmail.com wrote: Hi, Philip- Thanks for the response. Which 'settings' are you talking about? I am only aware of those referred to by git config --list, and I don't see anything that would explain it -- especially not in Cygwin/Windows, where only user.name and user.email are set. Yet it is from Cygwin I have done all my submits and pushes (until I resolve the discrepancy, I am not going to risk executing it commands from Fedora). BTW: your phrase work tree files in the two OS's makes it sound like you are assuming I have two different workspaces under the two OSs. What I really have is one worskpace directory viewed either under Windows/Cygwin or with the same partition mounted on a filesystem under Fedora. So the files are exactly the same, though Cygwin does funny things with representing permissions, which might turn out to be relevant here. Does Git consider a file 'modified' if only the permissions are changed? Finally, the Git Book admits that plumbing commands are not meant for the average user or even really for the command line, so more specific guidance (if plumbing is really the way to go) would certainly be needed: which plumbing commands? Is there one which will tell me why it considers a given file modified? On Thursday, January 31, 2013 12:11:02 AM UTC-8, Philip Oakley wrote: Given what you say about your .ogg file, it is probable that git's heuristic thinks they are [in some cases] binary (perhaps they are unicode files which will contain Null bytes) and won't therefore convert the line endings. The Git for Windows and Linux version of Git have slightly different default settings, so do check what they are. The line [EOL] and file [EOF] ending converstion discussions are spread over two or three man pages, and do take a bit of time to appreciate all the different normalisation issues. You can also try expanding the repo's blobs (using plumbing commands), and comparing those to the work tree files in the two OS's to which bytes are being changed, and in which direction. Philip - Original Message - From: Matthew Johnson To: git-...@googlegroups.com Sent: Thursday, January 31, 2013 1:22 AM Subject: [git-users] Re: Why Same Files show up with different Statuses in Git? Good guess, I had not been thinking about the different EOLs, but all the files that show up as modified only under Fedora are .ogg files: no EOLs at all. Even weirder, the textual files, whether HTML or JavaScript, do not have this problem. So it is hard to see how EOL inconcistency could explain why sound files are showing up as modified. On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote: I think this question on stackoverflow might help... - http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Basically the problems stems to you using the same physical repo with two different types of Git client, one built to use Windows EOL
Re: [git-users] Re: Why Same Files show up with different Statuses in Git?
OK. I was confused. I thought (misunderstood) that you were running two separated git instances (one Windows, one Linux), each with it's own work tree. I see that is not correct. What (I now think) you have is a single work tree e.g. /media/Windows7_OS/cygwin/home/MatthewJohnson/MrEd/mr.ed/lesson1/images/home-icon.jpg but that you still have two separated git instances (one CYGWIN on Windows, one Fedora Linux) that access that same set of work files and it's repo's stored objects. I would suspect that the two instances take slightly different stances (by default) on what they are doing with EOL conversion, and how the detect which files are 'text' and subject to eol normalisation. I don't use Cygwin (I'll guess it thinks the FS is windows and needs conversion, but again it's trying to be Linux so might not), so I'll drop out at this point Philip - Original Message - From: Matthew Johnson To: git-users@googlegroups.com Cc: Matthew Johnson ; Philip Oakley Sent: Thursday, January 31, 2013 7:53 PM Subject: Re: [git-users] Re: Why Same Files show up with different Statuses in Git? Hi, Philip- Thanks for the response. Which 'settings' are you talking about? I am only aware of those referred to by git config --list, and I don't see anything that would explain it -- especially not in Cygwin/Windows, where only user.name and user.email are set. Yet it is from Cygwin I have done all my submits and pushes (until I resolve the discrepancy, I am not going to risk executing it commands from Fedora). BTW: your phrase work tree files in the two OS's makes it sound like you are assuming I have two different workspaces under the two OSs. What I really have is one worskpace directory viewed either under Windows/Cygwin or with the same partition mounted on a filesystem under Fedora. So the files are exactly the same, though Cygwin does funny things with representing permissions, which might turn out to be relevant here. Does Git consider a file 'modified' if only the permissions are changed? Finally, the Git Book admits that plumbing commands are not meant for the average user or even really for the command line, so more specific guidance (if plumbing is really the way to go) would certainly be needed: which plumbing commands? Is there one which will tell me why it considers a given file modified? On Thursday, January 31, 2013 12:11:02 AM UTC-8, Philip Oakley wrote: Given what you say about your .ogg file, it is probable that git's heuristic thinks they are [in some cases] binary (perhaps they are unicode files which will contain Null bytes) and won't therefore convert the line endings. The Git for Windows and Linux version of Git have slightly different default settings, so do check what they are. The line [EOL] and file [EOF] ending converstion discussions are spread over two or three man pages, and do take a bit of time to appreciate all the different normalisation issues. You can also try expanding the repo's blobs (using plumbing commands), and comparing those to the work tree files in the two OS's to which bytes are being changed, and in which direction. Philip - Original Message - From: Matthew Johnson To: git-...@googlegroups.com Sent: Thursday, January 31, 2013 1:22 AM Subject: [git-users] Re: Why Same Files show up with different Statuses in Git? Good guess, I had not been thinking about the different EOLs, but all the files that show up as modified only under Fedora are .ogg files: no EOLs at all. Even weirder, the textual files, whether HTML or JavaScript, do not have this problem. So it is hard to see how EOL inconcistency could explain why sound files are showing up as modified. On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote: I think this question on stackoverflow might help... - http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Basically the problems stems to you using the same physical repo with two different types of Git client, one built to use Windows EOL and the other using Linux EOL. When you mix the two, I.e. work with a file in Linux when it was created whilst on Windows I think you'll run into problems. I think if you set up the Windows client correctly (or specifically use the .gitattributes file for the repository) I think you'll be ok. HTH On Wednesday, 30 January 2013 02:40:47 UTC, Matthew Johnson wrote: I hate to cross post, but I can no longer see my message to the same effect at the Git mailing list, where I got no reply, so here we go: First, some background. I have one hard disk separated into two partitions: one for the version of Windows 7 that shipped on this rather new Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I installed and keep up-to-date). Of course, it is rather
