line ending normalization/ autocrlf

[sopol...@gmail.com]

Why is the default for tfs clone autocrlf=false? 

Installing Git tool for Windows advises that the global be set to true. Most people install it this way. 

Even in the contributing to this project section it states that it should be set it to true.

But setting it to true when cloning from tfs, messes the pushes later i.e they get pushed with LF instead of CRLF, because the files get stored with LF in the git repo.

Even leaving it to false has caused some problems (some conflict resolutions merges ended with LFs in tfs).

Shouldn't the behavior be in sync with the behavior that git has and what users would expect, i.e normalizing the line endings before pushing to tfs (tfs being used mainly by windows users) and using the default setting that the user has in his global .gitconfig?

[Matt Burke]

> Why is the default for tfs clone autocrlf=false?

It is easier to quickly import everything if we treat it all as bytes,
rather than encoded characters with line endings. Pushing back to TFS
gets the same benefits. If all the files in the git repository are
bytewise identical to the ones in your working directory and the ones
in TFS (minus WIP), then git-tfs isn't going to do something
unexpected to the rest of your team when you push back. IIRC, line
endings can be a pain to deal with. For example, I recall breaking sln
files by giving them LF line endings, and breaking Gemfile.lock by
giving it CRLF line endings.

> Installing Git tool for Windows advises that the global be set to true. Most
> people install it this way.
> Even in the contributing to this project section it states that it should be
> set it to true.

Yes. If your project is entirely in git, autocrlf=true is the right
answer. I personally work across Linux, Mac, and Windows environments.
autocrlf=true generally makes that easier. I get fewer cases of a
"dirty" work tree that outputs nothing from `git diff -w`.

> But setting it to true when cloning from tfs, messes the pushes later i.e
> they get pushed with LF instead of CRLF, because the files get stored with
> LF in the git repo.
> Even leaving it to false has caused some problems (some conflict resolutions
> merges ended with LFs in tfs).
>
> Shouldn't the behavior be in sync with the behavior that git has and what
> users would expect, i.e normalizing the line endings before pushing to tfs
> (tfs being used mainly by windows users) and using the default setting that
> the user has in his global .gitconfig?

autocrlf=false makes git-tfs + git behave like TFS does. Because
git-tfs is essentially an alternative TFS client, I think this is a
reasonable default.

That said, if there's a better way to deal with it, that would be cool.


--
Matt

[sopol...@gmail.com]

Thanks for the detailed answer, but even with autocrlf=false I ended witch mixed line endings in TFS, guess it was my fault (the exact situation is either I applied some commit patches that git generated or when resolving some conflicts with beyond compare).

But If I want to share a tfs cloned repository with other OSes later, I guess it will still be a mess?

I asked the question in the first place because I managed to patch the code to behave in the way I described.

The only real change is in CopyBlob, to use the git filters (which are used on checkout anyway) when pushing to tfs.

I'm not sure if anyone will be interested in this change, but here's my commit, https://github.com/sopolenius/git-tfs/commit/89c360b341bf76ec5bccac6f96ba1139cd645828

Maybe my change is stupid but still, I would appreciate the feedback.

[cold...@equalexperts.com]

Personally I'm finding this line-ending behaviour somewhat hard to comprehend. I have a GitHub repo that is used for development but needs to be pushed continually to TFS for escrow purposes. At the end the TFS repo will become the golden source for future maintenance.

My expectation (rightly or wrongly) was that I would be able to verify the TFS copy at any time by doing a bitwise compare of the entire source folder structure between any pair of equivalent Git / TFS revisions (I'm pushing to TFS using rcheckin --quick). However I'm finding that no matter what setting of autocrlf I use (either in git config or on the command line) I always end up with files in TFS that have LF line-endings instead of CRLF (which is how my Git working copy presents them). Perhaps I'm doing something wrong? I'm far from being either a Git or TFS expert, so please humour me :-).

My understanding from this thread is that what I want is not possible (i.e. the Git and TFS working folders to have files with CRLF line-endings where appropriate) because my original Git repo was created with autocrlf=true and so internally all files are stored as LF, which is what is then pushed to TFS. Correct?

Many thanks,

Chris

[Matt Burke]

On Wednesday, May 7, 2014, <cold...@equalexperts.com> wrote:

Personally I'm finding this line-ending behaviour somewhat hard to comprehend.

Sorry about that. Line ending problems are pretty hard to figure out when they happen, even without git-tfs in the loop.

My expectation (rightly or wrongly) was that I would be able to verify the TFS copy at any time by doing a bitwise compare of the entire source folder structure between any pair of equivalent Git / TFS revisions (I'm pushing to TFS using rcheckin --quick)

This should be possible, though with a subtle difference from what you're trying to do: you should be able to do a bitwise comparison of raw content stored in git with the checked out copy from tfs. You should also be able to do a diff that ignores white space. Most diff tools have a way to do this.  By chance, have you tried using `git tfs verify` (https://github.com/git-tfs/git-tfs/blob/master/doc/commands/verify.md)? 

 

I'm far from being either a Git or TFS expert, so please humour me :-).

No worries, we're here to help. ;)

 

--

Matt

[cold...@equalexperts.com]

Hey, no need to apologise, it's not like I've paid for anything :-). I'll take any support I can get.

Whilst I am aware that I could do a comparison, say with KDIFF3, that ignores line-ending differences, that would fail The Notepad Test. By that I mean if I clone the original GitHub repo (which has autocrlf=true) and try and open, say, a .config file in Notepad it will appear properly as it will have CRLF style line endings. However if I map a workspace in TFS, do a get latest version, and try to open the same file in Notepad it will not display correctly due to having LF style line endings. Why does this matter? Well, when we build and deploy from TFS to the Windows app servers (which only have Notepad*) the .config files will not be easily editable. This is just one example where non-CRLF line endings causes problems.

Of course there are other workarounds, such as converting line endings in the build pipeline or committing all the text files again at the very end back through TFS with the correct line endings. I just wanted to know if I was missing a trick whereby the files would be pushed to TFS via git-tfs and the line-endings would be corrected in transmission so that they would end up in the TFS workspace correctly, i.e. with CRLF endings.

[* Sad but all too often true in The Enterprise]

Many thanks once again for your time,

Chris

[sopol...@gmail.com]

Well, that's the behavior that I want. I share my repositories between Mac and Windows/Cygwin. I edit stuff under Macos from time to time,  I've set autocrlf=true under windows, but still I want everything to be pushed to TFS with CRLF and to have the files with CRLF under windows.

The way I understand it all works:

windows, autocrlf=true

txt file (CRLF) <-> GIT (LF)  -> push-> TFS(LF) 

windows autocrlf=false

txt file (CRLF) -> GIT(CRLF) -> push TFS(CRLF)

linux/macos autocrlf=false

txt file(LF) -> GIT(LF) -> TFS(LF) crap

So, I changed the git-tfs source in my fork to get:

windows/autocrlf=true

txt file CRLF <-> GIT (LF)  -> push-> TFS(CRLF) 

so far it's working haven't notices LFs in TFS, all diffs show ok