Quick question: end of lines

Hi all,

I began recently to use git, and there is one thing I still do not know how to do.

Is it possible to checkout sources out of the GIT repository with Windows style end of lines? In a manner much like the one Subversion is using?

To be more precise, I need to be able to checkout files on Unix and Windows, and it is important that the end of lines are set accordingly.

Thanks for any hints or pointers,

Regards,

Manu

Hi,

On Tue, 28 Feb 2006, Emmanuel Guerin wrote:

No.

As far as git is concerned, every versioned file is equal. IMHO this decision is good, since

- different handling is more complicated (you have to keep track of the 
file type), and
- it is not really worth doing.

Windows can handle Unix line endings quite properly (with the notable exception of notepad.exe), and even Apple has learnt that it might be a stupid idea to insist on being different when it's just not worth it.

The only reason I would accept: you have to work with MS-DOS tools. But even in this case, I'd rather write a wrapper which converts to DOS line endings, executes the tool, and converts back.

Hth, Dscho

On 3/1/06, Emmanuel Guerin <emmanuel@guerin.fr.eu.org> wrote:

Why is this important?

(I am thinking: any reasonably good text editor will know how to deal with unix newlines, but you may have different reasons).

martin

2006/3/1, Martin Langhoff <martin.langhoff@gmail.com>:

Actually, you have found the problem. My particular setup is that Visual Studio is used on Windows. The editor will handle unix end of lines all right, but tends to insert windows ones when modifications are made. This leads to files with inconsistent end of lines, and nightmares with merges. We use Subversion for the moment, and we have to make sure that all text files are declared properly in svn to avoid conflicts.

What I begin to realize is that the only possibility probably lies in using a tool that converts the modified files "on the fly" before commits. I just want to make sure that no other solution was found by others facing a similar problem.

Anyway, thanks for the answers,

Emmanuel

On 3/1/06, Emmanuel Guerin <emmanuel@guerin.fr.eu.org> wrote:

Perhaps a pre-commit hook? Read the documentation (and search the list archives). I'm pretty sure you can do newline cleanup before commit or at least newline checks before commits.

There's always the option of filing a bug in MS's bugzilla ;-)

cheers,

martin

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

You can use .git/hooks/pre-commit hook in the repository the editor that munges line-termination, to fix things up.

The hook is called with GIT_INDEX_FILE set to the appropriate index file, so you could "git-diff-index --cached --name-only HEAD" to obtain the list of files being committed, sanitize the working tree files and update-index them again before returning true from the hook.

This is a silly example to standardize on uppercase.

        git-diff-index --cached --name-only HEAD |
        xargs sh -c '
                while case "$#" in 0) break ;; esac
                do
                        perl -p -i -e "\$_ = uc(\$_)" "$1"
                        git-update-index "$1"
                        shift
                done
        ' dummy
        exit 0