Menu
▾
▴
libusb-devel
|
From: Michael P. <mic...@gm...> - 2010-12-06 03:20:38
|
Pete Batard wrote: >> The first thing he did when I asked him to use -crlf on >> configure.ac was to go with eol=lf instead. http://marc.info/?l=git&m=121699459305954&w=2 Dmitry Potapov wrote: >> Eyvind Bernhardsen wrote: >> > There's also no way of saying "this file should >> > have LF line endings, even with autocrlf=true". >> >> Actually, there is >> >> *.sh crlf=input >> >> i.e. I want my shell files to have LF even I normally use CRLF for >> all other files (on Windows). Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-06 03:20:39
|
Michael Plante wrote: >> Well, it's clearly recent. I upgraded from msysgit 1.6.5.1-preview20091022 to >> 1.7.3.1-preview20101002, and now I *can* reproduce it on Windows. Looking >> around on the git mailing list indicates that a lot of crlf activity has >> occurred in the past year. I'll try a couple other versions and see if >> I can narrow it down further. That said, the behavior in 1.6.5.1, while >> at least consistent (unlike 1.7.2/1.7.3), was consistently bad. http://git.kernel.org/?p=git/git.git;a=commit;h=fd6cce9e89ab5ac1125a3b5f5611 048ad22379e7 Ok, bisected git. Last result: $ /root/bin/git bisect good fd6cce9e89ab5ac1125a3b5f5611048ad22379e7 is the first bad commit commit fd6cce9e89ab5ac1125a3b5f5611048ad22379e7 Author: Eyvind Bernhardsen <eyv...@gm...> Date: Wed May 19 22:43:10 2010 +0200 Add per-repository eol normalization Change the semantics of the "crlf" attribute so that it enables end-of-line normalization when it is set, regardless of "core.autocrlf". Add a new setting for "crlf": "auto", which enables end-of-line conversion but does not override the automatic text file detection. Add a new attribute "eol" with possible values "crlf" and "lf". When set, this attribute enables normalization and forces git to use CRLF or LF line endings in the working directory, respectively. The line ending style to be used for normalized text files in the working directory is set using "core.autocrlf". When it is set to "true", CRLFs are used in the working directory; when set to "input" or "false", LFs are used. Signed-off-by: Eyvind Bernhardsen <eyv...@gm...> Signed-off-by: Junio C Hamano <gi...@po...> :040000 040000 766df7b9f863b434965689e8669df9b643573bf1 bb1de46013e1e67c2ebcbf42a7942604f216545a M Documentation :100644 100644 d478eff1f323f25a474cf019e0de2254c5ff0360 e1a2e14fd91d3ec8489d8194bf588af90a01b04f M cache.h :100644 100644 6963fbea43e6420f5f8dafc5b94fb5c27de6ffd2 b60a1ff64bdc5e5d957b0725c59c4a02ff15fdeb M config.c :100644 100644 a54c5fc4a24d64ae3639d27d6abdf545d1ffacc4 1144e0b4f5539172eb4043edc8013fb8e69f135d M convert.c :100644 100644 739ec2704031f0dd9d4a380e07f001c09742a7be 3c8abae848b6eb8c4b832373f31f5a46994a27ad M environment.c :040000 040000 0e4632805ad61c52f3c3b6efa4ce1a23883a5e57 a8504b72905ee52c2f9f1947f6ff6d8bbcba47ea M t $ /root/bin/git bisect log # bad: [8c67c392e1620fc3b749aa9e0b8da13bd84226f8] Git 1.7.2.2 # good: [d599e0484f8ebac8cc50e9557a4c3d246826843d] Git 1.7.1 git bisect start 'v1.7.2.2' 'v1.7.1' # good: [567102819ac56ccf7eb638ea8b5c975c03e88558] Add test for correct coloring of git log --decoration git bisect good 567102819ac56ccf7eb638ea8b5c975c03e88558 # bad: [978327f97dd3bd20f1648a2fcac601191976b18c] Merge branch 'jk/url-decode' git bisect bad 978327f97dd3bd20f1648a2fcac601191976b18c # bad: [6df2ffaeef3f593214e88d9c148a7f3504f13e5e] Merge branch 'js/maint-receive-pack-symref-alias' git bisect bad 6df2ffaeef3f593214e88d9c148a7f3504f13e5e # good: [919e06b2288270f47c55759e8810b87f74609caf] Merge branch 'bc/portable' git bisect good 919e06b2288270f47c55759e8810b87f74609caf # good: [762655010d6f051f632a77b8c5b95b9f5cad02c9] Merge branch 'js/async-thread' git bisect good 762655010d6f051f632a77b8c5b95b9f5cad02c9 # good: [1623191be4ec91b3d2fb5ef85b1e77b7adef24af] Merge branch 'sm/branch-broken-ref' git bisect good 1623191be4ec91b3d2fb5ef85b1e77b7adef24af # bad: [d5cff17edaf438bbf45a2130e9cadc0c938291d6] Merge branch 'eb/core-eol' git bisect bad d5cff17edaf438bbf45a2130e9cadc0c938291d6 # bad: [fd6cce9e89ab5ac1125a3b5f5611048ad22379e7] Add per-repository eol normalization git bisect bad fd6cce9e89ab5ac1125a3b5f5611048ad22379e7 # good: [56499eb9b84453742222676d98e11be3c390c34d] Add tests for per-repository eol normalization git bisect good 56499eb9b84453742222676d98e11be3c390c34d Of course, I don't know much about git internals, so who knows if this helps... Michael |
|
From: Alan S. <st...@ro...> - 2010-12-06 15:09:59
|
On Sun, 5 Dec 2010, Michael Plante wrote: > Dammit!! Maybe safecrlf isn't the problem; maybe git is actually broken > here? Am I correct in assuming the entire working copy should be discarded > when you switch branches? Probably not. Git is clever about minimizing the amount of work it needs to do. It wouldn't be at all surprising to find that it leaves files unchanged when switching branches if no commits on those branches have modified the file. It might do this even when the CRLF settings are different for the two branches, and this might be a bug in git. However I am very far from being an expert on git. If this still matters to you guys, why don't you post a message or two on the git development mailing list? Alan Stern |
|
From: Michael P. <mic...@gm...> - 2010-12-07 01:23:25
|
Alan Stern wrote: >> It might do this even when the CRLF settings are different for the two >> branches, Well, that's the only rational way to explain it, anyway. >> and this might be a bug in git. However I am very far from >> being an expert on git. If this still matters to you guys, why don't >> you post a message or two on the git development mailing list? That occurred to me. Two problems: 1) I've bitten off more than I can chew with this discussion thread already 2) I'd have to find time to come up with a minimal example. I doubt they'd go cloning libusb-pbatard.git and sifting through there. Thanks, Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-07 23:58:58
|
Michael Plante wrote: >> Check this, though, again on Linux with autocrlf/safecrlf unspecified: >> >> $ git clone http://git.libusb.org/libusb-pbatard.git . >> $ git checkout -b prest pbr288 # pbr288 is the common ancestor >> $ git checkout -b pbst origin/supertest [1] (see below) >> $ hexdump -C libusb.dsw |less >> [...shows LF-only...] >> $ git checkout master >> $ git checkout pbst >> $ hexdump -C libusb.dsw |less >> [...shows CRLF...] If I insert: $ rm libusb.dsw $ git checkout libusb.dsw at [1], then the working copy is properly updated, and it shows CRLF-only on the following step. Moreover, "git status" still shows no changes. I'm not sure if this is a git bug, but it is sure as hell annoying. That said, I think that means eol=crlf works, provided wherever you switched from didn't have the setting set differently, or else at least didn't have the file in question present in the exact same directory. Note that I did NOT need to remove .git/index or issue a reset command in order to get this to work. Michael |
|
From: Peter S. <pe...@st...> - 2010-12-06 09:00:27
|
Michael Plante wrote:
> >> It sounds to me like the default config of msysgit should work
> >> fine for you.
>
> Meaning specifically which settings of autocrlf and safecrlf?
Meaning not setting them at all. I think that would mean these defaults:
core.eol=native
core.safecrlf=false
core.autocrlf=false
..in which case all files that are considered by git to be text will
be converted to have CRLF in the work tree on checkout on Windows,
and back to LF before commit.
If this does the trick it's of course the best since it needs no
configuration from the user, but I don't believe it will work:
(quoting gitattributes)
"While git normally leaves file contents alone, it can be configured
to normalize line endings to LF in the repository and, optionally, to
convert them to CRLF when files are checked out."
..this says that no files will be classified as text by default
"normally leaves .. alone" so nothing is ever converted by default.
Windows users who want CRLF in their working trees will need to set
safecrlf=true+autocrlf=true. I assumed both Pete and Michael would
like CRLF (if for no other reason than that tools might write out
files with CRLF, and those should certainly not go into repo) which
is why I recommended those settings way back when.
> Recall that I mentioned Peter, from the very beginning, suggested
> setting those explicitly to true. So if you're suggesting I unset
> them, I'd like to hear more details.
I still think that safecrlf=true makes sense, because if there is
conversion going on then safecrlf can catch if the conversion could
cause trouble.
Moving to autocrlf:
core.autocrlf
Setting this variable to "true" is almost the same as setting the
text attribute to "auto" on all files except that text files are
not guaranteed to be normalized: files that contain CRLF in the
repository will not be touched. Use this setting if you want to
have CRLF line endings in your working directory even though the
repository does not have normalized line endings.
There are several bits of important information here:
Files with CRLF in the repository will be a special case if any
conversion is going on, so we must not have CRLF in the repo, in
order to take advantage of the conversion that git can do for us.
autocrlf=true makes git convert line endings for all files, except
those that have CRLF in the repository, but we should not have any
of those. No CR either in the repo or in any patches.
Maybe a .gitattribute like this would solve the problem:
autogen.sh text eol=lf
configure.ac text eol=lf
safecrlf=true+autocrlf=true means that all files in the repository
get turned into CRLF when checked out, and will safely be converted
back before commit, which is convenient for using Notepad and which
just makes sense on Windows, since CRLF is the native line ending.
And with those text and eol attributes we let git know about our
files which are text but have special needs.
It really sucks bigtime that MSYS autoconf can not handle CRLF. :(
As mentioned before, a workaround for that would be to have separate
AC_CONFIG_FILES lines for each file, rather than an entry in
.gitattributes, but I guess if we can not get away without a
.gitattributes completely then might as well use it and have a nicer
configure.ac. Noone commented on what they prefer there?
Following up on other points in the thread:
Changing crlf settings in git never makes it change what is checked
out. This causes significant confusion if testing settings back and
forth. I have also seen this in my testing. If someone wants to test
my suggested .gitattributes above, please make sure to do a lot of
checkouts in order to actually exercise the code in git that does
conversion. A small tip if the work tree was clean and suddenly all
files have changes is to just checkout all those files, per
instructions in the git status output.
Cygwin is *NOT* Windows. So using a Windows tool such as TortoiseGit
or msysGit to check out something that will be used Cygwin is not
correct, should not be expected to work, and must not be optimized
for. Make sure to use a Cygwin tool for Cygwin testing. I guess LF
may be the native line ending in Cygwin, which would explain why
Xiaofan never has problems with line endings.
The commit identified by Michael introduces the eol attribute, and I
prefer taking advantage of that rather than setting -text on the
files - and as I tried to explain this is also the reason I don't
like using -crlf; a) crlf is only kept for backwards compatibility
and actually means -text, and b) -text is a workaround since these
files *are* in fact text files.
CRLF in the repo is unacceptable since git has the ability to handle
conversion for us as neccessary and it is very helpful to have a rule
without exceptions for this, among other things because it helps
working back an forth between different repositories, as Michael
pointed out.
And finally, I think this thread is very much an important and
integral part of the Windows integration rather than something that
would be drawing away from the integration. We are learning how we
make our codebase cross platform not only at run time but also at
development time. This is good and neccessary. Thanks to everyone
who is testing and providing input on this!
//Peter
|
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 09:29:16
|
On Mon, Dec 6, 2010 at 5:00 PM, Peter Stuge <pe...@st...> wrote: > Cygwin is *NOT* Windows. So using a Windows tool such as TortoiseGit > or msysGit to check out something that will be used Cygwin is not > correct, should not be expected to work, and must not be optimized > for. Make sure to use a Cygwin tool for Cygwin testing. I guess LF > may be the native line ending in Cygwin, which would explain why > Xiaofan never has problems with line endings. > I just use whatever default Cygwin git is using and I have no issues with all the git trees I use. But I tried to use MSysGit for once and it gave me all kinds of problems so that I did not use it. Take note I sometimes copy git repos between Linux/Windows. On the other hand, so you expect Pete to use MSysGit for MinGW/MSVC/WDK testing and use Cygwin Git for Cygwin testing. I am not so sure if he would like to do that. To me, it is better not to let the tool be too smart and convert things automatically. Rather do not touch the line endings. If something breaks, blame those who use stupid editors to stupid tools. -- Xiaofan |
|
From: Segher B. <se...@ke...> - 2010-12-06 13:05:54
|
> On the other hand, so you expect Pete to use MSysGit for > MinGW/MSVC/WDK testing and use Cygwin Git for Cygwin > testing. I am not so sure if he would like to do that. There isn't really any alternative; you cannot mix cygwin with "native" mswindows stuff, without issues like these. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-06 13:27:23
|
On 2010.12.06 13:05, Segher Boessenkool wrote: > There isn't really any alternative; you cannot mix cygwin with > "native" mswindows stuff, without issues like these. Yes you can if you commit files that should be CRLF/LF as CRLF/LF in the repo in the first place and use binary mode (-crlf) always, which is my proposal for official. There's aren't any files that I am aware of that would need to be CRLF in cygwin and LF in native, or LF in cygwin and CRLF in native (unless you consider that Notepad should be used to edit files that are meant to be LF'd in the first place, like UNIX shell scripts. If despite the fact that MS project files are text files, we agree that these should better be CRLF'd, I don't see how we could fail to agree that despite the fact that UNIX .sh or autotools .am/.ac are text files, they should be LF always - especially as we've demonstrated 3 different issues with non LF'd ones) If you think that this is not achievable, then you have to agree that you don't believe that git not respect binary settings that ENSURE that you can actually mix cygwin with native Windows, and therefore, that git is flawed. Otherwise, there IS very much an alternative. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 13:33:06
|
On Mon, Dec 6, 2010 at 9:27 PM, Pete Batard <pb...@gm...> wrote: > On 2010.12.06 13:05, Segher Boessenkool wrote: >> There isn't really any alternative; you cannot mix cygwin with >> "native" mswindows stuff, without issues like these. > > Yes you can if you commit files that should be CRLF/LF as CRLF/LF in the > repo in the first place and use binary mode (-crlf) always, which is my > proposal for official. > > There's aren't any files that I am aware of that would need to be CRLF > in cygwin and LF in native, or LF in cygwin and CRLF in native (unless > you consider that Notepad should be used to edit files that are meant to > be LF'd in the first place, like UNIX shell scripts. If despite the fact > that MS project files are text files, we agree that these should better > be CRLF'd, I don't see how we could fail to agree that despite the fact > that UNIX .sh or autotools .am/.ac are text files, they should be LF > always - especially as we've demonstrated 3 different issues with non > LF'd ones) > Yes this is well put. No conversion. And use the right tool to edit the text files -- do not use Notepad to edit shell script or use Unix editor to edit CRLF text files. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 14:14:20
|
On Mon, Dec 6, 2010 at 9:33 PM, Xiaofan Chen <xia...@gm...> wrote: > On Mon, Dec 6, 2010 at 9:27 PM, Pete Batard <pb...@gm...> wrote: >> On 2010.12.06 13:05, Segher Boessenkool wrote: >>> There isn't really any alternative; you cannot mix cygwin with >>> "native" mswindows stuff, without issues like these. >> >> Yes you can if you commit files that should be CRLF/LF as CRLF/LF in the >> repo in the first place and use binary mode (-crlf) always, which is my >> proposal for official. >> >> There's aren't any files that I am aware of that would need to be CRLF >> in cygwin and LF in native, or LF in cygwin and CRLF in native (unless >> you consider that Notepad should be used to edit files that are meant to >> be LF'd in the first place, like UNIX shell scripts. If despite the fact >> that MS project files are text files, we agree that these should better >> be CRLF'd, I don't see how we could fail to agree that despite the fact >> that UNIX .sh or autotools .am/.ac are text files, they should be LF >> always - especially as we've demonstrated 3 different issues with non >> LF'd ones) >> > > Yes this is well put. No conversion. And use the right tool > to edit the text files -- do not use Notepad to edit shell > script or use Unix editor to edit CRLF text files. > That being said, I do not see any files need to be forced to be CRLF, even the text files (the two files with .txt extension from libusb-pbatard). The are not CRLF in my checkout so it is not good to use Notepad to view it. Is that a problem? Not a problem for me. With this, then the maintainers who do not use Windows can edit those text files as well. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 14:19:00
|
On Mon, Dec 6, 2010 at 10:14 PM, Xiaofan Chen <xia...@gm...> wrote: > On Mon, Dec 6, 2010 at 9:33 PM, Xiaofan Chen <xia...@gm...> wrote: >> On Mon, Dec 6, 2010 at 9:27 PM, Pete Batard <pb...@gm...> wrote: >>> On 2010.12.06 13:05, Segher Boessenkool wrote: >>>> There isn't really any alternative; you cannot mix cygwin with >>>> "native" mswindows stuff, without issues like these. >>> >>> Yes you can if you commit files that should be CRLF/LF as CRLF/LF in the >>> repo in the first place and use binary mode (-crlf) always, which is my >>> proposal for official. >>> >>> There's aren't any files that I am aware of that would need to be CRLF >>> in cygwin and LF in native, or LF in cygwin and CRLF in native (unless >>> you consider that Notepad should be used to edit files that are meant to >>> be LF'd in the first place, like UNIX shell scripts. If despite the fact >>> that MS project files are text files, we agree that these should better >>> be CRLF'd, I don't see how we could fail to agree that despite the fact >>> that UNIX .sh or autotools .am/.ac are text files, they should be LF >>> always - especially as we've demonstrated 3 different issues with non >>> LF'd ones) >>> >> >> Yes this is well put. No conversion. And use the right tool >> to edit the text files -- do not use Notepad to edit shell >> script or use Unix editor to edit CRLF text files. >> > > That being said, I do not see any files need to be forced > to be CRLF, With perhaps the exceptions of the MSVC project files. But if we tread them as binary files, then there are no problems. > even the text files (the two files with .txt > extension from libusb-pbatard). The are not CRLF > in my checkout so it is not good to use Notepad > to view it. Is that a problem? Not a problem for me. Since I use Notepad++ under Windows, > With this, then the maintainers who do not > use Windows can edit those text files > as well. > -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-12-06 14:19:44
|
On 2010.12.06 14:14, Xiaofan Chen wrote: > That being said, I do not see any files need to be forced > to be CRLF, even the text files (the two files with .txt > extension from libusb-pbatard). The are not CRLF > in my checkout so it is not good to use Notepad > to view it. Is that a problem? Not a problem for me. Neither is it for me. As I said, if people want to go with something else than -crlf on files that we would prefer to be CRLF'd always, I'm fine with it. We're only playing for safety on those, and assuming that we might get issues if someone ever gets an LF'd file that should have been CRLF'd. But what I have an objection to is not enforcing files that should always be LF as LF, when I have seen 3 *separate* issues on not doing that, and the other proposal is *rely* on users following what we tell them to, while we can just do that for them by using binary mode always. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-06 14:21:10
|
On 2010.12.06 14:19, Pete Batard wrote: > by using binary mode always. on those files. /Pete |
|
From: Peter S. <pe...@st...> - 2010-12-06 15:06:15
|
Pete Batard wrote: > But what I have an objection to is not enforcing files that should > always be LF as LF, You seem to not completely understand what I proposed earlier today. Please read my messages again. I believe what I suggest (text eol=lf) will give git users freedom to choose their line endings (using *crlf=true) but still ensure that special needs are met for autogen.sh and configure.ac. I just do not want any CR in the repo in files that are obviously text, and I have suggested a solution that should work for everyone. //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-06 16:38:49
|
Pete Batard wrote: > The premise here is that if a user ever gets a file that should not > have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS > proj), it's game over. But that's not really the case. > We don't know for sure that MS projs will ever be an > issue, but one of the point of this thread is to assume so. When they become an issue we add text eol=crlf to .gitattributes. > Scenario 1: .. > => UNIX developer has MS project files with LF endings > - 6 months down the line, UNIX developer who has been successful with > his project decides to port it to Windows MSVC. Since he already has git > on UNIX, and installing git on Windows doesn't seem a necessity, he just > decides to pull (he's developing so he might as well test the latest > version) and then copy the files over. Said developer is doing it wrong. > Obviously, since it's been 6 months, he has forgotten everything > about our one line advice not to copy repos. > => game over No, game on. All files have LF, just as if the developer had done a checkout on Windows using msysGit, without adding *crlf=true to his configuration. The developer either knows to set *crlf=true or not. If no, everything continues to work also on Windows, except Notepad. This is true as long as no files require text eol=crlf. When developer sees this maybe there will be an association to the information about how to get CRLF in the workcopy. It's also easy to make this a FAQ if neccessary. If yes (developer knows that *crlf=true gives CRLF) then developer will also know if CRLF on the Windows worktree is desired, and add settings accordingly. > Scenario 2: > - Windows developer, libusb, git version > - diligently reads our wiki page, and applies the *crlf=true to that he > gets CRLF'd files. If the configure.ac text eol=lf works, he is supposed > to get LF'd files there. So far so good. > - later down the line, while using another git repo, he decides to > change his *crlf *options* (why not - if we can advise a set of > *options*, others can advise theirs. The settings are per-repo, not system-wide. > (as I understand from Michael, local git repo settings can get overridden) It's the other way around, local repo settings override --global. > - 6 months later, Windows app was successful, so now he wants to port it > to UNIX. For now he decides to pull from libusb official on Windows to > see the changes. Now let's say we added a new Makefile.am in the > meantime (new samples, etc). Not so likely, but ok, let's say. > Right now, because he modified them globally with that other > project, What did he modify? A file with text eol=lf in .gitattributes? And he saved it with CRLF? Unless he has added core.whitespace=cr-at-eol manually, the CR will appear in patches. If patches were sent to the mailing list as they should, people will have noticed and pointed it out. > he has *crlf options that may result in the new Makefile.am to ve > CRLF'd (not sure about the old ones, so I'll assume they're still LF'd) Yep, this can happen if he keeps his own tree without sharing patches with anyone else. CR will be accepted silently with core.whitespace=cr-at-eol, and accepted but visible in git diff without cr-at-eol. > - copies to a UNIX a system (might not have internet connectivity to > the UNIX system, so he's using an USB key), He should remember to clone rather than copy; doing it wrong. > and obviously has forgotten our little rule about not doing so > (it's been 6 months!) It's not a rule that I made up, it is a function of how git works. As you may have noticed I simply assume that anyone using git to work with the source will take a little while to learn about git before/while doing so. > => game over No, also game on. The repo on the UNIX system has the same commit, with a CR in it, and at some point either that patch will be sent to the list, and the problem discovered in review - if the developer doesn't discover it himself by then - and then fixed. Or, if the developer's repo on UNIX is never published or posted then he may continue using the file with CR. If it ever becomes a problem it is trivial to fix with an interactive rebase. > If you want to dismiss those scenarios as far fetched, fine, but we > happen to know that we can address them both with -crlf, Except that the files are text and should have LF line endings, so telling git -text doesn't make sense, when text eof=lf is more accurate. > > not .. any CR in the repo > > or use -crlf/-text and, as a result, having to make sure that our > git users read and re-read our little rules, and have their freedom > restricted, unless they want to waste their time. You may see it as waste of time, but I do not, and I don't think anyone should. Learning to use tools is only a waste of time if there's no desire to use the tools, which is also fine. git am vs. git apply for a patch does not make a big difference for me. Of course the most convenient thing for me is to pick commits from a published repo, but a simple diff always works too. //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-06 18:22:40
|
Pete Batard wrote: > >> The premise here is that if a user ever gets a file that should not > >> have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS > >> proj), it's game over. > > > > But that's not really the case. > > That's our premise here. Whose premise? In any case the premise is not accurate. > > Said developer is doing it wrong. > > Ah "right" and "wrong". Who's to decide? You? For the purpose of libusb, sure. But I guess that you will find the same if you ask the developers of git. > >> Obviously, since it's been 6 months, he has forgotten everything > >> about our one line advice not to copy repos. > >> => game over > > > > No, game on. All files have LF, just as if the developer had done a > > checkout on Windows using msysGit, without adding *crlf=true to his > > configuration. > > No game over. If all files have LF, and the premise is that MSVC 201X > does not accept non CRLF'd files, we have game over. Please don't > ignore the premise when it becomes convenient for you to do so. Please don't ignore again what I'm now writing for the second if not third time; if that is something we encounter in the future, then we'll add -text in .gitattribute for the files. But as long as they are text files it is better to treat them as such. > >> (as I understand from Michael, local git repo settings can get overridden) > > > > It's the other way around, local repo settings override --global. > > OK, then maybe he set ____crlf as global originally and didn't set them > in his repo, then changed the global settings again later on. So now, we > have to guide them to make sure that they set their settings locally. > For non GUIs that's easy, but we'll also need to mention GUI versions of > Git. Actually no, we don't need to do that at all. Maybe you think it is important but I am opposed to having a tutorial for various git user interfaces on libusb.org. The information is readily available elsewhere and someone using git to get libusb has a responsibility to learn a bit of git on their own. I'm happy to add neccessary commands to show how to use git, but not to add instructions for GUIs. (If someone else does it of course I won't delete anything.) > > If patches were sent to the > > mailing list as they should, people will have noticed and pointed it > > out. > > This is a scenario for a developer using libusb, not someone interested > in sending us patches. What I'm concerned with here is avoiding that > developer from finding an error and having to fix it on their own, as > they will if they copy over their .ac/.am/.sh. If they have an issue with CRLF in source files while writing a USB device driver I think there is something more serious going wrong. > It took me quite a while to figure out that the .am error I kept having > when copying my files over to Linux for testing was due to CRLF... Would suggest asking for help on the mailing list or on IRC in case of trouble like that. Most people do. Someone usually replies quickly with useful hints. > > Yep, this can happen if he keeps his own tree without sharing patches > > with anyone else. > > Why should he? He's developping his application using *unmodified* files > that he got from git. There's nothing to submit back. If there are no modifications then the issue is moot. > > He should remember to clone rather than copy; doing it wrong. > > Yes, people are really so silly not to know how they are supposed to use > git, especially when git is the least of their concern, and they might > be using a completely different VCS on a daily basis, and all they want > to use is a library in their projects. Either they want to use git, or they don't. If they do, then they should learn what is neccessary to use the tool. If they don't, then maybe we can give them another option that fits better, such as snapshots. > Not everybody uses git, not everybody should use git, We will not have workarounds for the case when such people use git anyway. > people should not have to spend time they don't need to spend learning > the idiosynchrasies of git CRLF If they are using git and they care about CRLF then they should, actually. > > when text eof=lf is more accurate. > > Provided your ____crlf options are set as they should, No, the eol attribute takes precedence over other indicators. I tried to explain this in previous messages. I'm sorry if it wasn't clear. See git config --help for core.autocrlf. > knowing CRLF settings from git won't bring them anything in the long > run (apart from maybe thinking "wow, git sure does restrict what I'm > allowed to do with my settings and how I can move files around - If > I have to chose a VCS in the future, I'll make sure I steer well > away from one that restricts me so.") It is very much a matter of understanding the tool. You seem unwilling to understand git, but hopefully others who use it are not. Git is a significant help with the mess of platform-specific line endings. If this is not clear, then I think everyone is happier if the people in question do not use git at all. And perhaps we can provide them an alternative which suits them better. Like snapshots. Or something else. Any ideas? //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-06 19:15:47
|
On 2010.12.06 18:22, Peter Stuge wrote: > Whose premise? In any case the premise is not accurate. Mine and Michael, and to a lesser extent Orin, who indicates that CRLF proprietary files have no business being converted even if they are text files. We're well aware that the premise is not expected to be accurate for the time being, but want to avoid that, should it ever become reality, we don't run into the issue of having to convert files, and possibly create the same kind of issues Michael was faced with after I did convert mine. >>> Said developer is doing it wrong. >> >> Ah "right" and "wrong". Who's to decide? You? > > For the purpose of libusb, sure. But I guess that you will find the > same if you ask the developers of git. Which means you now need to ask if what you're planning to do is the right approach before you even attempt to use a simple VCS system. Personally, I find a VCS system that places hurdles on copying from one env to another as very much flawed, no matter what its developers want to pretend, especially when I know exactly how to address the issue to make it work. > Please don't ignore again what I'm now writing for the second if not > third time; if that is something we encounter in the future, then > we'll add -text in .gitattribute for the files. And please don't ignore that if we do, we potentially have to go through a conversion that breaks existing branches, and have to fix issues similar to Michael's that won't be limited to a single user. > But as long as they > are text files it is better to treat them as such. That's not what myself, Xiaofan and I think Orin and Michael are thinking. Yes they should be treated as text, but very much CRLF'd text, no LF text, if we want to make sure we avoid any potential bad surprise. > Actually no, we don't need to do that at all. Maybe you think it is > important but I am opposed to having a tutorial for various git user > interfaces on libusb.org. So much for being ready to help git users... > The information is readily available > elsewhere and someone using git to get libusb has a responsibility to > learn a bit of git on their own. Yes, and people have a responsibility not to make mistakes or write buggy code, yet they still do. If people have a responsibility to learn git, then I see it as a responsibility to prevent them from making mistakes with git when we know exactly how to do so. Responsibility is not just something you can brush away to other people to avoid facing yours. Now, you clearly don't see preventing git CRLF mishaps as your responsibility, but I do. > If they have an issue with CRLF in source files while writing a USB > device driver I think there is something more serious going wrong. I did, and as far as I am concerned, I did nothing that I didn't expect to work then. I just copied files over from one system to the next, expecting that since I had an "autocrlf" attribute set, git had been smart enough to detect that, as it was .sh/.am/.ac and, AFAIK, there does not exist a single platform out there where these files should ever be CRLF, all the files were LF. My mistake then was trusting git to handle CRLF with the autocrlf option. Of course, I should have known that git wasn't as smart as could be, when there also existed a safecrlf option... So the lesson here is, never trust git on doing what you expect it to do, but instead thoroughly read the git documentation. Lesson learned. >> It took me quite a while to figure out that the .am error I kept having >> when copying my files over to Linux for testing was due to CRLF... > > Would suggest asking for help on the mailing list or on IRC in case > of trouble like that. Most people do. Someone usually replies quickly > with useful hints. Except I knew how to work around it, and the workaround is a simple line edit. I could elaborate some more on why exactly I didn't ask on the mailing list (mostly because I had reasons to believe it was environmental), but that's not our concern here. > If there are no modifications then the issue is moot. Not for me if one of our users has to waste time just because they used git to retrieve our source, as they are entitled to do. > Either they want to use git, or they don't ...have a choice (eg test hotplug and no snapshot yet). >> people should not have to spend time they don't need to spend learning >> the idiosynchrasies of git CRLF > > If they are using git and they care about CRLF then they should, > actually. You really think people want to care about CRLF in git? There are people using git who don't want to care about CRLF, and that's my point. If I had the choice, I would not care about them either, which is what -crlf was all about as I don't expect anybody who has the opportunity not to care about them to want to care about them. Your proposal: "Care about CRLF or else..." My proposal: "Don't worry about CRLF - we'll take care of that for you" > Git is a significant help with the mess of platform-specific line > endings. I beg to differ. Autocrlf alone didn't help one bit with the mess of platform-specific line endings. On the contrary, it very much introduced issues, and you're supposed to *know* that you must use safecrlf with it. How's that a significant help? Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-06 23:50:40
|
Pete Batard wrote: >> On 2010.12.06 18:22, Peter Stuge wrote: >> > Whose premise? In any case the premise is not accurate. >> >> Mine and Michael, and to a lesser extent Orin, who indicates that CRLF >> proprietary files have no business being converted even if they are text >> files. I didn't quite follow what you were saying there. You wrote: "The premise here is that if a user ever gets a file that should not have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS proj), it's game over." i.e., "that should not have X it should have". So I have no statement regarding that, because the meaning of that sentence is unclear to me. But let me address what you followed it with: I have no INTRINSIC problem with CRLF staying the same or with it being converted back and forth, provided it always gets checked out CRLF, and provided I can get my branches consistent with yours. If CRLF staying in the repo prevents me from doing so, then I would oppose it. Right now, I am not certain it's the cause, but that was certainly the same time when my trouble began. >> > Actually no, we don't need to do that at all. Maybe you think it is >> > important but I am opposed to having a tutorial for various git user >> > interfaces on libusb.org. >> >> So much for being ready to help git users... Post a link. The question is where it's appropriate to host the content, not whether it's appropriate to help. Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-06 23:19:42
|
Xiaofan Chen wrote: >> do not use Notepad to edit shell >> script or use Unix editor to edit CRLF text files. Lest anyone be confused, no one ever suggested using notepad on shell scripts. Shell scripts and autoconf files were the very files I explicitly excluded. I get the funny feeling from this email and the last one I replied to that you have not read the thread. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-06 17:45:20
|
On 2010.12.06 16:38, Peter Stuge wrote: > Pete Batard wrote: >> The premise here is that if a user ever gets a file that should not >> have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS >> proj), it's game over. > > But that's not really the case. That's our premise here. As Michael and I have pointed out, we don't currently have reason to believe MS tools cannot handle CRLF, but I can very imagine a scenario where MS decides to ditch XML in their *proprietary format* files and switch to full binary mode. These files are not supposed to be edited manually, so if they want to do so they can. Or maybe they just start with adding binary sections in there. In which case, what will git do if he still attempts to treat them as text? >> We don't know for sure that MS projs will ever be an >> issue, but one of the point of this thread is to assume so. > > When they become an issue we add text eol=crlf to .gitattributes. If this works with any settings for ____crlf, and when copying files over, then why not do it right from the start? > Said developer is doing it wrong. Ah "right" and "wrong". Who's to decide? You? >> Obviously, since it's been 6 months, he has forgotten everything >> about our one line advice not to copy repos. >> => game over > > No, game on. All files have LF, just as if the developer had done a > checkout on Windows using msysGit, without adding *crlf=true to his > configuration. No game over. If all files have LF, and the premise is that MSVC 201X does not accept non CRLF'd files, we have game over. Please don't ignore the premise when it becomes convenient for you to do so. If you want to ignore the premise, then half this thread can be ignored, as there's nothing we need to do for MS project files. >> Scenario 2: >> - Windows developer, libusb, git version >> - diligently reads our wiki page, and applies the *crlf=true to that he >> gets CRLF'd files. If the configure.ac text eol=lf works, he is supposed >> to get LF'd files there. So far so good. >> - later down the line, while using another git repo, he decides to >> change his *crlf *options* (why not - if we can advise a set of >> *options*, others can advise theirs. > > The settings are per-repo, not system-wide. > > >> (as I understand from Michael, local git repo settings can get overridden) > > It's the other way around, local repo settings override --global. OK, then maybe he set ____crlf as global originally and didn't set them in his repo, then changed the global settings again later on. So now, we have to guide them to make sure that they set their settings locally. For non GUIs that's easy, but we'll also need to mention GUI versions of Git. So I guess our little: "Please make sure that you set your ____crlf settings to true if you're on Windows," needs to be amended "and make sure you set them locally" and broken down further on how to do that depending on whether you are using to use commandline, TGit, and possibly git extensions. These options are fairly explicit (don't know about git extensions), but still, we need to highlight them if we want to be safe. >> Right now, because he modified them globally with that other >> project, > > What did he modify? A file with text eol=lf in .gitattributes? No, ____crlf. > If patches were sent to the > mailing list as they should, people will have noticed and pointed it > out. This is a scenario for a developer using libusb, not someone interested in sending us patches. What I'm concerned with here is avoiding that developer from finding an error and having to fix it on their own, as they will if they copy over their .ac/.am/.sh. It took me quite a while to figure out that the .am error I kept having when copying my files over to Linux for testing was due to CRLF... > Yep, this can happen if he keeps his own tree without sharing patches > with anyone else. Why should he? He's developping his application using *unmodified* files that he got from git. There's nothing to submit back. > He should remember to clone rather than copy; doing it wrong. Yes, people are really so silly not to know how they are supposed to use git, especially when git is the least of their concern, and they might be using a completely different VCS on a daily basis, and all they want to use is a library in their projects. > I simply assume that anyone using git to work with the source will > take a little while to learn about git before/while doing so. And I postulate that this is by no means something we need to enforce, and that we can instead free up time for our users for more productive activities than learning about git, especially if git is not their prime VCS. Not everybody uses git, not everybody should use git, and therefore, people should not have to spend time they don't need to spend learning the idiosynchrasies of git CRLF when we CAN avoid them to. >> => game over > > No, also game on. (...) and at some point either that patch will be > sent to the list, Again, if people have to send a patch to the list, which is not part of my scenario at all, it is very much game over. You still made somebody waste their having to fix a problem that we could ensure would not happen. >> If you want to dismiss those scenarios as far fetched, fine, but we >> happen to know that we can address them both with -crlf, > > Except that the files are text and should have LF line endings, so > telling git -text doesn't make sense Unless you consider that what -text does is ensure that no conversion is ever perform on the file, and we know for certain that there isn't a single platform where we need something different from LF, as is our case. > when text eof=lf is more accurate. Provided your ____crlf options are set as they should, which is not something we can enforce, only advise. People are free to ignore advice - happens all the time, and we have the opportunity to make sure we enforce the rule we need so that even if they ignore our advice, it won't matter. > You may see it as waste of time, but I do not, and I don't think > anyone should. Learning to use tools is only a waste of time if > there's no desire to use the tools What you fail to understand is that we do have a solution that doesn't require our users to learn about specific aspects of the tools. Therefore, yes, forcing them to learn IS a waste of their time. It is unneeded, and, again, if they mostly use a different VCS system, knowing CRLF settings from git won't bring them anything in the long run (apart from maybe thinking "wow, git sure does restrict what I'm allowed to do with my settings and how I can move files around - If I have to chose a VCS in the future, I'll make sure I steer well away from one that restricts me so.") Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-06 11:36:19
|
Peter Stuge wrote: >> Changing crlf settings in git never makes it change what is checked >> out. This causes significant confusion if testing settings back and >> forth. I have also seen this in my testing. If someone wants to test >> my suggested .gitattributes above, please make sure to do a lot of >> checkouts in order to actually exercise the code in git that does >> conversion. I'm not sure if I understand which "crlf settings in git" you're referring to: those in .gitattributes or those in the git config? If the latter, ok. But if the former, this cannot be true: >> Changing crlf settings in git never makes it change what is checked >> out. As I mentioned, changing crlf settings in .gitattributes SOMETIMES changes what's checked out. But maybe that's a consequence of master having the files moved to a different directory, which tricks git into re-checking? As a wild guess, I'm wondering if the following would help, in your estimation: http://help.github.com/dealing-with-lineendings/ key line: $ git rm --cached -r . In another place, I saw something similar recommended: $ rm .git/index && git reset Do you think either of those would help our tests to go more predictably, or do those correct different issues from what we're seeing? >> The commit identified by Michael introduces the eol attribute, and I >> prefer taking advantage of that rather than setting -text on the >> files So would you say that that commit intentionally introduces the behavior I saw, or is the behavior I saw an unintended side effect? Thanks, Michael |
|
From: Peter S. <pe...@st...> - 2010-12-06 12:55:43
|
Michael Plante wrote: > >> Changing crlf settings in git never makes it change what is checked > >> out. .. > I'm not sure if I understand which "crlf settings in git" you're referring > to: those in .gitattributes or those in the git config? If the latter, ok. Both. > But if the former, this cannot be true: > > > >> Changing crlf settings in git never makes it change what is checked > >> out. > > As I mentioned, changing crlf settings in .gitattributes SOMETIMES > changes what's checked out. What *will be* checked out on the next git checkout command, yes. The state of the worktree until that git checkout, no. In particular changing the CRLF settings will influence what git expects in the worktree, but not the contents of the worktree, which is why lots of files can suddenly show up in git status, when playing with the crlf settings. > >> The commit identified by Michael introduces the eol attribute, and I > >> prefer taking advantage of that rather than setting -text on the > >> files > > So would you say that that commit intentionally introduces the > behavior I saw, or is the behavior I saw an unintended side effect? I'm not sure exactly what happened in your worktree. :\ If you zip it up I'll try to take a look when travelling this evening. //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-06 12:51:15
|
Pete Batard wrote: > > CRLF in the repo is unacceptable > > since git has the ability to handle > > conversion for us as neccessary > > Very confusingly, as this thread has shown. Then read it again. Or just follow suggested advice by someone who has spent more time learning about what git does and when. > Why would we ever want to help people who don't see getting > overly acquainted with git as a productive use of their time? This makes no sense. When we have learned what we need to understand the problem we can give simple advice about how to successfully work with the codebase. Currently that would be: if you are OK with LF in your worktree: don't set any options if you want CRLF: set safecrlf=true+autocrlf=true Done. > > and it is very helpful to have a rule > > without exceptions for this, > > How so? Consistency helps a lot for dealing with a codebase. > at the expense of git newcomers getting files with improper line > terminations. The tool we use is git, if people want to work efficiently with us then I think it is reasonable to expect that they learn a little git. We'll help, and not much needs to be learnt, but still. > the problem experienced by Michael will never happen on official. I can't say either way; I don't know exactly what the problem is. > It can only happen if there exists an LF <-> CRLF conversion in the > tree, which will NEVER happen if we go with -crlf and then add all > the files that we want CRLF'd, *NONE* of which exist in official > right now. Another benefit from consistent LF and nothing else in the repo is that no such conversion can happen. > PS: as to "you shouldn't copy files from an MS git tree to UNIX" or > "you should only use cygwin's git", yeah, that will greatly help > ANYBODY who wants to help with the Windows backend development and > ensure that they don't break things before submitting them back to > the list. Do you seriously consider it a problem to push and then pull, in order to do that testing? Really? > If you want to help with the Windows backend, YOU MUST: > - make sure you set the autocrlf/safecrlf settings EXACTLY AS WE > TELL YOU (regardless of what you might be using for other projects) No. You did not understand my most recent email correctly. See above, hopefully that makes it more clear. > - make sure you only use the git version that is as native as > possible to your each of your development environment In theory yes, in practise yes if using CRLF for the Windows worktree, but in practise no if we add the .gitattribute I suggested in the previous email. > - never copy files between environments Yes if using CRLF in one worktree. Since CRLF in worktree is a decision for the user to make, I think it's reasonable that they also take care to not mix files back and forth. Copying files is further not the good way of doing things, better use commit+push+pull. > how exactly are we not elitists here? We are not, but I really don't care about that when it comes to the git tree. I have said on numerous occasions that it is fine and well to have more requirements for those who work with the git code. //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-06 13:49:58
|
On 2010.12.06 12:51, Peter Stuge wrote: > Pete Batard wrote: >>> CRLF in the repo is unacceptable >>> since git has the ability to handle >>> conversion for us as neccessary >> >> Very confusingly, as this thread has shown. > > Then read it again. Or just follow suggested advice by someone who > has spent more time learning about what git does and when. And consistently dismisses libusb users that are expected to be new to git as people not worthy of our consideration. >> Why would we ever want to help people who don't see getting >> overly acquainted with git as a productive use of their time? > > This makes no sense. When we have learned what we need to understand > the problem we can give simple advice about how to successfully work > with the codebase. Yes, because people ALWAYS thoroughly read wikis and stuff of course. Seriously, if we went with all your proposals, we'd have the following list of requirements before someone can even start to do anything with libusb: - you must have libtool that is less than 6 months old (and would have had to be -3 months old or something if we had completed integration in early 2010) - you must not use multilib MinGW-w64 ever - you must use the exact following options if you clone from git - you are not supposed to clone from git ever if you're really serious anyway, but instead use snapshots etc... It's very easy to place demands on people, and blaming them for not respecting them, when you're the one making those demands. Freedom to use the software in any way you want? Not so much with libusb when it places demands that CAN be avoided. > Currently that would be: > > if you are OK with LF in your worktree: don't set any options > if you want CRLF: set safecrlf=true+autocrlf=true > > Done. And if you want to ensure that ANYBODY who clones your tree gets CRLF'd files, *no matter what*, you can't. I could even go as far as enforce. With -crlf, we can enforce that ANYBODY who clones the tree gets CRLF'd files if we say they should be CRLF'd. With your proposal, not so much, since they must first "ensure" that they have the right ___crlf. >>> and it is very helpful to have a rule >>> without exceptions for this, >> >> How so? > > Consistency helps a lot for dealing with a codebase. "\r" Enough said. >> at the expense of git newcomers getting files with improper line >> terminations. > > The tool we use is git, if people want to work efficiently with us > then I think it is reasonable to expect that they learn a little git. Not when we have an alternative of NOT having to force them to learn. If git was that smart, nobody should EVER have to care about CRLFs, and this is what I am advocating. Ensuring that nobody has to care about learning about CRLF options in git who doesn't have to. > Another benefit from consistent LF and nothing else in the repo is > that no such conversion can happen. Except when git checks in or checks out. The actual "no such conversion can happen" stance is when you have the files in the right mode in the repo. > Do you seriously consider it a problem to push and then pull, in > order to do that testing? Really? As I explained, if need to push a change on my public repo before I can pull it to test it on Linux, and then find that my change breaks Linux, you'll get another "oops!" commit. So there's only 2 choices there. Have a private repo (but even then, I need to merge oops so that they appear as a single commit on public) or copy my files from Windows to Linux when I want to test them. But of course, since you don't test Windows in the first place, it is perfectly acceptable to you to place yet another set of demands on Windows developers. Regards, /Pete |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X