Home » Eclipse Projects » Oomph » autocrlf on GitCloneTask
|
Re: autocrlf on GitCloneTask [message #1701317 is a reply to message #1700991] |
Sat, 11 July 2015 01:00 |
Ed Merks Messages: 33258 Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
On 08/07/2015 4:23 PM, Michael Haeusler wrote:
> whenever I use the GitCloneTask in my setups (running on Windows) I
> see in the log output "Setting autocrlf = true"
Yes, this is hard coded in the git clone task implementation.
> is there any way to change that ?
No.
> our sources rely on keeping the lineendings exactly as they are in the
> repository.
In other words Unix-style. How is it that they "rely" on this?
> I have autoCRLF set to FALSE in the global gitconfig and also in my
> user config.
>
> is it a bug that these values are ignored ?
No.
>
> it would also be nice to have an option on the GitCloneTask to enforce
> the needed setting, as it might not be correct in the global gitconfig.
I suppose, though "correct" is rather subjective. Unfortunately there
are tools on Windows that will produce Windows line delimiters and if
you're not careful, those will be committed to the repository without
conversion. Then a user checking it out on Unix will see Windows
delimiters, and all will be a huge mess. This seems very dangerous so it
seems to us better to always do the conversion, especially on Windows.
Of course that's a subjective statement as well, and we don't really
want to dictate to everyone what we think is right. But I am curious
how your source relies on this.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: autocrlf on GitCloneTask [message #1701362 is a reply to message #1701317] |
Sun, 12 July 2015 20:44 |
Michael Haeusler Messages: 10 Registered: July 2009 |
Junior Member |
|
|
Ed Merks wrote on Fri, 10 July 2015 21:00Michael,
In other words Unix-style. How is it that they "rely" on this?
.. no in the repository we have Windows-style line breaks for all java files.
well the java source files are obviously not a problem, since Eclipse has no problems using any kind of line ending.
... but we have many data files that are needed for unit tests and integration tests (for example MIME structures which have to use CRLF line breaks).
the autoCRLF, can also break non-text files, and it becomes really messy if you use egit in combination with command-line git, or some other git tool that correctly uses the .gitattribute settings defined in a repository.
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372)
Since all our developers use Eclipse I don't see any benefit of the autoCRLF feature at all.
We had the same problems also with SVN, so we decided many years ago, that we would not allow any "conversion magic" to be performed by version control tools.
I looked at the source of the GitCloneTask and saw that autoCRLF is always enabled on Windows and always disabled on any other operating system.
So when someone uses Eclipse on Linux but has it configured to use CRLF as lineendings (as we have defined in our globally shared eclipse settings) then they will commit CRLF to GIT, whereas the Windows users will not ... that is just creating the same mess that you had described above.
I would expect to have autoCRLF enabled always or never, but not depending on the OS.
As it is implemented now, it is a showstopper for us, since there is no workaround ... unfortunately I noticed this problem after I had prepared the setup files for most of our projects
[Updated on: Sun, 12 July 2015 20:55] Report message to a moderator
|
|
|
Re: autocrlf on GitCloneTask [message #1701363 is a reply to message #1701362] |
Sun, 12 July 2015 23:04 |
Ed Merks Messages: 33258 Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
On 12/07/2015 10:44 PM, Michael Haeusler wrote:
> well the java source files are obviously not a problem, since Eclipse
> has no problems using any kind of line ending.
>
> .. but we have many data files that are needed for unit tests and
> integration tests (for example MIME structures).
I'd be kind of surprised if there is a tool that works on Windows that
can't deal with Windows line breaks...
>
> the autoCRLF, can also break non-text files, and it becomes really
> messy if you use egit in combination with command-line git, or some
> other git tool that correctly uses the .gitattribute settings defined
> in a repository.
> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372)
That's quite the saga. I believe the setting we do is stored in the
repo's config, so should be respected by command line tools...
>
> Since all our developers use Eclipse I don't see any benefit of the
> autoCRLF feature at all.
There is the danger that you'll commit Windows line endings...
> We had the same problems also with SVN, so we decided many years ago,
> that we would not allow any "conversion magic" to be performed by
> version control tools.
It's always a bit of a nightmare, but some tools just produce Windows
line endings on Windows and then you end up with a different version of
the nightmare.
>
> I looked at the source of the GitCloneTask and saw that autoCRLF is
> always enabled on Windows and always disabled on any other operating
> system.
Yes.
> So when someone uses Eclipse on Linux but has it configured to use
> CRLF as lineendings (as we have defined in our globally shared eclipse
> settings) then they will commit CRLF to GIT, whereas the Windows users
> will not ... that is just creating the same mess that you had
> described above.
So you commit Windows line endings and people on Linux see that. That
sounds bad to me too...
> I would expect to have autoCRLF enabled always or never, but not
> depending on the OS.
I suppose that's true, but the expectation is that the actual repository
uses Linux conventions so conversion on Linux is a no-op.
>
> As it is implemented now, it is a showstopper for us, since there is
> no workaround ... unfortunately I noticed this problem after I had
> prepared the setup files for most of our projects :(
We could certainly look at making it more flexible, though I'm very
surprised you're committing Windows line endings to your repository;
I've never seen anyone do that intentionally.
As a workaround, I suppose you could have a resource modify task that
modifies the ${foo.git.clone.location/.git/config} to change the value
of that attribute.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: autocrlf on GitCloneTask [message #1701623 is a reply to message #1701611] |
Tue, 14 July 2015 13:42 |
Ed Merks Messages: 33258 Registered: July 2009 |
Senior Member |
|
|
Michael,
Comments below.
On 14/07/2015 2:39 PM, Michael Haeusler wrote:
> Quote:
>> We could certainly look at making it more flexible, though I'm very
>> surprised you're committing Windows line endings to your repository;
>> I've never seen anyone do that intentionally.
>
>
> as mentioned before, the main reason for this is that we need to have
> our test files unchanged (regardless of the operating system)
I'll have to take your word for it that this is a need and not just a
want. I suppose you could mark them as binary but that would have other
not nice side effects do doubt.
> For the source files, there is no real need to commit the windows line
> endings, but it is more consistent in our opinion to avoid conversion
> completely.
To me it seems very odd given that the whole design around this in git
itself is intended to keep the repository's line endings in a standard
form (which is Linux) and to surface this in the OS form on checkout.
With what you're proposing, there is nothing to prevent a mixture of
forms being committed.
>
> I also thought about using the resource modify task, however that does
> not work because the git clone task is already causing a conversion
> while doing the checkout of the working copy.
Good point. Sorry.
>
> changing the flag afterwards only affects future operations.
>
> as a proof of concept I have patched the GitCloneTask to set the Flag
> to false, which works just fine. however replacing the eclipse plugin
> is not really convenient for deployment.
> Is there any way to use custom SetupTasks that would be available on
> our own eclipse update site ?
Please open an enhancement request. Probably we should focus on a
design that allows any of the configuration properties to be set...
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Sat Dec 07 21:15:22 GMT 2024
Powered by FUDForum. Page generated in 0.03733 seconds
|