[ooo-build] [go-oo.org Dev] CRLF line endings

[Jens-Heiner Rechtien]

Hi,

I've looked a bit around, and yes there are ways to implement the
equivalent of a pre-commit "hook" at least in git and mercurial. I would
be somewhat surprised if that wouldn't be also possible with bzr, but I
haven't checked.

git:
  The hook subdirectory in the .git store contains shell scripts which
are run before or after certain git operations. I guess the one called
"pre-commit" would be the one we need ... The examples are implemented
in perl.
The scripts are cloned together with the repository, so there can be
some amount of "central" policing of commits.

mercurial:
  Windows users can enable the Win32Textextension in .hgrc
(http://www.selenic.com/mercurial/wiki/index.cgi/Win32TextExtension)
which seems to try to guess if a file is a text file and converts it to
Unix if the file contains CRLF just before committing it.

Of course in both cases one can easily temper with the checks (or just
forget to enable the extension) but we do hopefully agree that
prevention of repeated mistakes is the goal and not strict enforcement.
Both solutions look good enough for me in this respect. So I retract the
"a customization once introduced can never be retracted" argument I made
before. But I still think that a heuristic that finds only 90% of the
error cases is worse than not trying at all, because it creates a wrong
feeling of safety.

Heiner

Jens-Heiner Rechtien wrote:
> Hi Bjoern,
> 
> Bjoern Michaelsen wrote:
>> Jens-Heiner Rechtien wrote:
>>> Martin Hollmichel wrote:
>>>> any reason why ?
>>> Not on principle, just because of the overriding per log message
>>> mechanism. The same guys who can't be bothered to do a diff before
>>> committing will almost certainly use the overriding mechanism without a
>>> second thought.
>>> The problem is that the overriding mechanism would be needed to often,
>>> mostly because of the check for tabs.  Without that one a python
>>> implementation of that script might be acceptable though I would do
>>> things differently.
>> My hope was that becoming "the guy that always gets the tabs wrong"
>> might be enough of an embarrassment to keep that from happening. Maybe I
>> am a bit naive.
> 
> Well, I guess barring them for 2 days from committing after they have
> been found out will be far more effective :-)
> 
>>> The script would also at least need to discern between commits done for
>>> rebasing and others. You'll almost always have an exceptional file in
>>> every rebase and people will be annoyed if their scripted rebase fails
>>> due to such checks.
>> True.
>>
>>> The other thing is I have to check first if bzr, git or mercurial have a
>>> similar mechanism. Once these things are in place people get so used to
>>> it they can't live without it any longer. Might sound stupid but it is a
>>> fact of live ... I learned that the hard way.
>> bzr, git and mercurial cannot do that in the way svn does by definition.
>> With those you commit locally and thus commits are out of the control of
>> RelEng. However:
> 
> Well at least for the Python implemented DSCMs I can easily imagine that
> hooks and scripts could be "inherited" via the cloning command. Or we
> require a custom plugin that does these kinds of checks. As I said I
> have to check out what's possible, I wouldn't rule out the possibility
> of implementing these things categorically. There will always be a way
> around that of course if someone dares to do so.
> 
>> - Formatting can easily be checked when a cws is nominated
>>   (and wont be integrated unless cleaned up)
> 
> Same situation as now. Where's the difference?
> 
> It's not that "easily" done by the way, there are a huge number of files
> in a typical nomination/integration round and there are already a number
> of things to be inspected. Anyway I will in future refuse to integrate
> CWSs where I notice such things and I'll ask my fellow REs to do so
> likewise.
> 
>> - Commits to tags/trunk/whatever shouldnt be possible with DSCM as the
>>   repos holding those should be owned by RelEng and be readonly for the
>>   rest of the world(*). Anyone unhappy with the way RelEng handles their
>>   repos will be easily able to clone and pull from those, so this is not
>>   at all "less open".
> 
> Comitting on tag is a SVN specialty, granted. But I've got no problem to
> imagine any number of things people do wrong with a DSCM as well: I've
> deleted my WC ... oh my, my changes are gone as well ... got no backup
> ... can you implement something which prevents me from doing a "rm -rf"?
> ... OK I'm being sarcastic here. But all DSCM I've tested have some very
> subtle ways to go wrong. With mercurial it's the easiness with which
> there are unwanted "heads" created or the clumsiness of named branches.
> With git it's everything which is related to the index (I'm sure I've
> committed everything. Wait ... I forgot to stage that file, oh oh).
> 
>>> But: Do you really want RE impose such stupid things on you? I rather
>>> don't want to police things. If really a majority of the developers want
>>> that RE polices your commits ... well, I've got a number of ideas there
>>> ... :-)
>> Things that are easily checked (like certain formatting issues) should
>> be. Tabs and linebreaks should be reliably checkable.
> 
> They aren't reliable without an elaborate heuristics. Certain makefiles
> require tabs. Third party stuff shouldn't be changed unnecessarily.
> Patches to third party stuff might contain legitimate tabs. Generated
> files might contain legitimate tabs - on the other hand committing these
> files is a mistake in itself, one I would check for :-)
> 
>> What otherpolicies do you have in mind? ;-)
> 
> No restructuring on release branches. Yup that's a policy and one I care
> much more about than tabs. Will be implemented first if I start policing
> the commits. Of course, YMMV :-)
> 
> Heiner
> 


-- 
Jens-Heiner Rechtien
rechtien at sun.com
_______________________________________________
Dev mailing list
Dev at lists.go-oo.org
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org