Re: [Libusb-devel] >=autoconf-2.63 no grokmultiline AC_CONFIG_FILES?

[Pete B. <pb...@gm...>]

On 2010.12.05 21:25, Michael Plante wrote:
> Pete Batard wrote:
>>>>>> and keeps a mix of branches that have
>>>>>> conflicting settings
>>>>
>>>> NOT by my choice.  You made that choice for me.
>>>
>>> Yes, because, after I found a way to enforce LF on .sh, I thought if we
>>> want to be on the safe side, we should enforce CRLF on MS project files
>>> (because I don't see why they should EVER be converted to LF, even for
>>> storage), to avoid potential future issues. Sounds like the safe
>>> approach to me, even if it's not safe for your existing branches.
>
> Except that it doesn't seem to work with all settings of autocrlf/safecrlf,
> a requirement you've previously stipulated.

Doesn't it? I'm expecting it to work always, since my understanding is 
that -crlf tells git to bypass any autocrlf/safecrlf settings.

I fully expect it to work regradless of what autocrlf/safecrlf one has, 
which is a big advantage.

> But there are at least two ways
> to enforce CRLF's, one which stores CRLF's in the repo, and one which
> doesn't.  You chose the former.

Yup, because I don't see why git should ever need to store files that 
don't need to be de-CRLF'd as de-CRLF'd. If it's only to prevent mixing 
at the expend of getting users with autocrlf/safecrlf settings that 
won't get CRLF on clone, then the choice is pretty obvious.

> Additionally, by storing them as LF-only in the repo, no
> huge-unmanageable-diff exists across any pair of revisions in the repo.

Poor argument. Huge diff will not happen on official precisely because 
we know the .gitattrributes we want and we'll be committing CRLF'd files 
in the first place. As to unmanageable diff on an experimental repo 
that's under my full control, I do hope I still have the freedom to 
commit whatever I want there, as long as the patches I submit to 
official are satisfactory.

> In
> other words, it doesn't break the ability to look through history. (...)

That's not what I experience in my branch (I'm much more annoyed by the 
underscoring move to msvc/ that actually broke history [1]). And again, 
there won't be any huge diff in official if we commit CRLF initially, as 
is the plan.

 > So I don't think you've seen anything; you
> stated the msvc files' settings were a preventative measure.  Arguably it's
> 100/0, not 50/50; my bad.  Again, I have no beef with what you've done with
> the .sh/.ac/.am stuff (though Peter does), which is presumably what you've
> "seen".

I have no problem with 100/0 in your favour for MSVC files, since, 
again, I don't see how anybody else should logically be affected. 100% 
of a single user having an issue is fine with me, which is what I 
logically expect with the MSVC issue.

>>> And if people for any reason copy their repo
>>> to a Linux machine (so as not to have to fetch it again), compilation
>
> Heh, I find it easier to move it between Linux and Windows BY fetching.

Well, sometimes I want to ensure that something I plan to commit to core 
isn't going to break Linux. Now if I commit to my repo and it turns out 
that it does break Linux, I have a very public change that I need to 
fix. If I copy files or directories (simpler when there's more than one 
file) I can catch it early and avoid public humiliation ;)

Does this scenario make sense to you? It does occur on regular basis for me.

> one might want to exercise caution copying the repo,

Agreed. But if you exercise caution on everything, you're not being very 
productive.

> Actually, given your config shows that you're tracking libusb-mplante.git,
> it could be argued that you ALSO have "branches that have different
> settings".  Do you see what I'm getting at?  You're claiming it's my fault
> for having branches that have different settings.

If you branch off libusb-pbatard and don't follow what I do, up to 
.gitattributes and CRLF'd files in my repo, then it's your problem. It 
might not be your fault if the issue was introduced by git to CRLF'ing 
files in your repo as it should have when you tried to apply the patch, 
but if you don't follow my .gitattributes, when I'm supposed to be the 
authority for Windows commits, and your problem is linked to 
.gitattributes, the responsibility for it is yours.

> No, you're telling it not to touch them.  So you could insert MIXED line
> endings in there right now and git wouldn't touch them.

I already debated that point elsewhere. I don't see it as a problem if 
the alternative is to shift issues on our git users as a result, so that 
a very limited set of developers avoid them.

>>> Of course, if you planned to follow my branch yet skirted around that
>>> commit, you are expected to have issues with line endings.
>
> Like I said, once you pushed that commit (following zero discussion), I
> tried for a few hours to reproduce the change on my side, after which I
> complained to you privately.  Only when we decided we couldn't agree was I
> forced to "skirt" that commit.

OK, I'll take the blame for not pushing it too hard on my side, and I'll 
tell you why: the MS proj are simple text files. I fail to see how you 
couldn't have cloned my repo from scratch and then reapplied your 
changes on top of it, expect the MS projs, and then copy/pasted into the 
MS projs (and presumably only the MSVC6 ones, since that's what you are 
using). Heck, if you have a public branch that you want to see fixed, 
I'll cone it and do that for you, as I don't expect it to take that long 
to fix.

> And CRLF is precisely what MSVC would see, due to autocrlf.

Except is someone new to git doesn't have autocrlf set as it should. 
Let's say we're finally working on hotplug, and don't have a snapshot 
yet. I'm pretty sure Windows users might be interested in retreiving the 
repo. Well, if they use TGit, it's game over on having CRLF in the 
project files. Granted, they'll probably be fine with LF only, but this 
is not how we would like their project files to be.

>>> Why should we ever
>>> want these files to be stored as LF in git, when only MS people are
>>> supposed to ever modify them? -crlf solves that problem.
>
> Because, afaict, doing otherwise breaks with safecrlf.

Not when you understand that if you have both .gitattributes and 
converted files in your repo, it doesn't. It only broke on your system 
because, as you admitted, you weren't able to apply all the required 
-crlf changes, which I'm pretty sure I can fix if I can get access to 
the branch you want to see fixed.

>>> And please someone name a platform where shell scripts that are LF only
>>> will not run
>
> DOS?  :)  Seriously, though, I noticed you didn't mark the .cmd file as
> hands-off...

Was talking about .sh, though you're right, technically cmd are shell 
scripts. But the only files that have been causing issues were .sh. As 
to the cmd DDK files, not sure yet what to do with them yet. I'm 
expecting them to work as LF (along with the "_source" files), but I'll 
test that before resubmitting the .gitattribute.

>>> Another possibility is that git is not smart enough to detect that if a
>>> .gitattributes is part of a commit, it should create it first and apply
>>> its settings (and I guess I should have broken my commit there, as I did
>>> break it up for official), so even as the patch operation should have
>>> converted the files in your repo, it didn't, and you would have had to
>>> unix2dos them right after.
>
> That makes no sense because unix2dos operates on the working copy, which is
> ALREADY crlf.  The problem is that git would not put them into the repo with
> CRLF.

I think if you have -crlf, and the files are LF'd in the repo, git will 
be smart enough to spot the differences. There's probably no need for 
unix2dos but you do need to recommit the files.

Regards,

/Pete

[1] 
http://git.libusb.org/?p=libusb-pbatard.git;a=history;f=_libusb_2008.sln;h=c1b44c7a7b0ce5c880a732995e0b3df621132408;hb=7093b1f58526700043a85f818eb4f38ac3cc87a0;js=1