git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Dmitry Potapov <dpotapov@gmail.com>
To: Nigel Magnay <nigel.magnay@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: crlf with git-svn driving me nuts...
Date: Thu, 17 Apr 2008 13:43:42 +0400	[thread overview]
Message-ID: <20080417094342.GM3133@dpotapov.dyndns.org> (raw)
In-Reply-To: <320075ff0804170007k5171eb72n68882679f62fa238@mail.gmail.com>

On Thu, Apr 17, 2008 at 08:07:27AM +0100, Nigel Magnay wrote:
> 
> This has nothing to do with changing core.autocrlf after checkout -
> it's a problem with *any* repo with CRLF files, being checked out on a
> core.autocrlf=true machine, which basically is any windows machine.
> 
> The current 'isDirty' check seems to be something like
> 
> isDirty = ( wc.file.mtime > someValue ) && ( repository.file !=
> filter(wc.file) )

Basically, yes.

> 
> I'm saying it ought to be something like
> 
> isDirty = ( wc.file.mtime > someValue ) && (sha1(repository.file) !=
> sha1(wc.file) ) && ( repository.file != filter(wc.file) )

I don't think it is reasonable. Files inside of the repository and
in the work are not meant to be the same. What if I have $Id$ expansion
or something else. What could make sense is to add an additional check:
 && convert_to_work_tree(repository.file) != wc.file
but it should be optional, so it will not penalize those who do need
or do not want this extra check.

> >  >
> >  > But fixing that minor bug still leads to badness for the user. Doing
> >  > (on a core.autocrlf=true machine) a checkout of any revision
> >  > containing a file that is (currently) CRLF in the repository, and your
> >  > WC is *immediately* dirty. However technically correct that is, it
> >  > doesn't fit most people's user model of an SCM, because they haven't
> >  > made any modification.
> >
> >  IMHO, the only sane way is never store CRLF in the Git repository.
> >  You can have whatever ending you like in your work tree, but inside
> >  of Git, LF is the actually marker of the end-of-line.
> >
> 
> Great. I'll go and argue with the team using svn, who don't even
> *notice* this issue, and try to get them to adjust the metadata on
> every single file in the repository.

Maybe, you can teach git-svn to be smarter... I mean storing text files
in Git repo with CRLF is stupid, so, perhaps, git-svn can do a better
job converting CRLF<->LF when it exports and imports from/to SVN.

> 
> Then, for a bonus, I'll try the same with every OSS project that I'm
> tracking with git-svn. :-(
> 
> I get that things are horribly broken if you get CRLF in your
> repository. But it's unreasonable to expect the ability to bend the
> rest of the world to what's convenient for me! Some of our windows
> coders probably even *like* svn:eol-style=CRLF !

You can use Git and have CRLF in your work tree. You just need to
have autocrlf=true for that. _Inside_ of Git, only LF is the end
of line. How you store in SVN, it is a separate issue with git-svn.
I guess, git-svn needs improvement in this area...

Dmitry

  reply	other threads:[~2008-04-17  9:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 19:10 crlf with git-svn driving me nuts Nigel Magnay
2008-04-16 20:01 ` Dmitry Potapov
2008-04-16 20:20   ` Avery Pennarun
2008-04-16 20:39     ` Dmitry Potapov
2008-04-16 21:56       ` Nigel Magnay
     [not found]       ` <320075ff0804161447u25dfbb2bmcd36ea507224d835@mail.gmail.com>
     [not found]         ` <20080416223739.GJ3133@dpotapov.dyndns.org>
2008-04-16 23:07           ` Nigel Magnay
2008-04-17  0:46             ` Dmitry Potapov
2008-04-17  1:44               ` Avery Pennarun
2008-04-17  7:07               ` Nigel Magnay
2008-04-17  9:43                 ` Dmitry Potapov [this message]
2008-04-17 10:09                   ` Nigel Magnay
2008-04-17 18:53                     ` Dmitry Potapov
2008-04-17 22:03                       ` Nigel Magnay
2008-04-17 22:42                         ` Dmitry Potapov
2008-04-17  5:43             ` Steffen Prohaska
2008-04-16 20:56   ` Martin Langhoff
2008-04-16 21:02     ` Avery Pennarun
2008-04-16 21:17     ` Dmitry Potapov
2008-04-16 20:03 ` Avery Pennarun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080417094342.GM3133@dpotapov.dyndns.org \
    --to=dpotapov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nigel.magnay@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).