Line ending translation extension

Matt Mackall mpm at selenic.com
Sat Sep 12 00:38:45 CDT 2009


On Sat, 2009-09-12 at 00:27 +0200, Martin Geisler wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
> 
> > 2009/9/11 Martin Geisler <mg at lazybytes.net>:
> >> You're right -- we should also convert files upon checkout to match
> >> the settings in .hgeol. So that means they will get a file in LF
> >> format. Somewhat unusually, it will be reported as modified when they
> >> do 'hg status', even though they just made a fresh clone.
> >>
> >> It is modified because it's format in the repository (CRLF) doesn't
> >> match the format it will get using the current filters (LF). They
> >> should make a commit to bring things back in sync.
> >
> > Hmm, I can't imagine that people doing a clean checkout would expect
> > to find modified files, much less have to commit changes.
> 
> That is why the one who edits .hgeol should do the commit. It is a
> *mistake* to edit it without ensuring that the files match its
> declarations -- I'm explaining what would (may) happen in that
> situation.
> 
> > And what happens if they *don't* commit, but hack and then commit. If
> > 2 people do that, you'll have a merge to do, which will be mangled by
> > EOL conflicts (I suspect - not tried this to be sure).
> >
> > Sounds like there are a number of edge cases that need thinking
> > through here :-)
> 
> Definitely! :-) Patrick had some thought about this here:
> 
>   http://markmail.org/message/3rvccjqtd62odjaq
> 
> It would be nice if you could make a clone from
> 
>   http://bitbucket.org/mg/hg-eol/
> 
> and run 'make tests' -- please add more tests to document the corner
> cases and send a patch... :-)
> 
> >> This suggests that we should watch for commits to .hgeol and convert
> >> files (or warn/abort) at that point. That way a change in .hgeol and
> >> subsequent commit will have everything in sync.
> >
> > Not sure that'd work as people expect either. If I change .hgeol, then
> > commit and *other* files get committed, I think I'd be surprised (even
> > if I understood why it happened after reading the docs...)
> 
> I think it will all go a lot easier if we can expect a little bit of
> active thinking by the users -- they cannot just go around changing
> repository meta data like mad and hope for the best :-)
> 
> I imagine it would work something like this: after changing .hgeol you
> call a rebuildeol command and then the effects will show up as modified
> files, which you can then commit along with .hgeol. If we're really
> smart, we will call this rebuildeol command automatically when we see
> that .hgeol has been changed.

We should probably just extend the filter API to allow it to say "I
might need to peek at this file to decide if it's clean". Adding an
extra command sucks. 

In particular, if .hgeol is dirty, all the files it mentions may now be
dirty. Which will probably be your entire project, yay.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list