The attached script should prevent tabs in *.asd, *.lisp, or *.script files from being committed to a git repository. Existing tabs will not be affected, unless they appear in (the context of) another modification.
Here's an example stopped commit. "" Error: This git repository disallows the #\Tab character in lisp files. Only spaces should be used for indenting lisp code. In emacs, 'M-x untabify' and (setq indent-tabs-mode nil) may help.
First offending file and lines: test.asd + this is a tab ""
To install, simply copy this script to .git/hooks/pre-commit and set the executable bit.
It might also be good to put a copy somewhere permanent so others can install it to their local repositories.
Later, Daniel
On Wed, 2009-12-23 at 23:38 -0500, dherring@tentpost.com wrote:
The attached script should prevent tabs in *.asd, *.lisp, or *.script files from being committed to a git repository. Existing tabs will not be affected, unless they appear in (the context of) another modification. Here's an example stopped commit. "" Error: This git repository disallows the #\Tab character in lisp files. Only spaces should be used for indenting lisp code. In emacs, 'M-x untabify' and (setq indent-tabs-mode nil) may help.
First offending file and lines: test.asd
- this is a tab
""
I've attached a slightly modified version that also checks for spaces at the end of a line and only on added/modified lines, not in the context of the patch
To install, simply copy this script to .git/hooks/pre-commit and set the executable bit.
It might also be good to put a copy somewhere permanent so others can install it to their local repositories.
good idea
On 1/11/10 Jan 11 -9:43 PM, Stelian Ionescu wrote:
On Wed, 2009-12-23 at 23:38 -0500, dherring@tentpost.com wrote:
The attached script should prevent tabs in *.asd, *.lisp, or *.script files from being committed to a git repository. Existing tabs will not be affected, unless they appear in (the context of) another modification. Here's an example stopped commit. "" Error: This git repository disallows the #\Tab character in lisp files. Only spaces should be used for indenting lisp code. In emacs, 'M-x untabify' and (setq indent-tabs-mode nil) may help.
First offending file and lines: test.asd
- this is a tab
""
I've attached a slightly modified version that also checks for spaces at the end of a line and only on added/modified lines, not in the context of the patch
To install, simply copy this script to .git/hooks/pre-commit and set the executable bit.
It might also be good to put a copy somewhere permanent so others can install it to their local repositories.
good idea
Is there some reason that this cannot be pushed into the repository itself (i.e., used like a blur/clean thing)? See the bottom of this page: http://progit.org/book/ch7-2.html
I.e., we just automagically detabify when staging.
It seems inappropriate to expect everyone to fuss with his/her own repository to get this behavior. Shouldn't we do it once on the shared repo and we all get it for free?
Robert Goldman wrote:
Is there some reason that this cannot be pushed into the repository itself (i.e., used like a blur/clean thing)? See the bottom of this page: http://progit.org/book/ch7-2.html
I.e., we just automagically detabify when staging.
It seems inappropriate to expect everyone to fuss with his/her own repository to get this behavior. Shouldn't we do it once on the shared repo and we all get it for free?
That's a good idea, but probably not workable. First, I don't think the script will run on stock mswin. Even if it did, I'm not sure there's a syntax to run a filter located within the repository (think initial checkout).
In other words, the attributes filter provides a natural hook for this type of thing; but I'm not sure its any easier for the end user to set up. At least the commit hook is optional.
Later, Daniel
On 1/14/10 Jan 14 -11:29 AM, dherring@tentpost.com wrote:
Robert Goldman wrote:
Is there some reason that this cannot be pushed into the repository itself (i.e., used like a blur/clean thing)? See the bottom of this page: http://progit.org/book/ch7-2.html
I.e., we just automagically detabify when staging.
It seems inappropriate to expect everyone to fuss with his/her own repository to get this behavior. Shouldn't we do it once on the shared repo and we all get it for free?
That's a good idea, but probably not workable. First, I don't think the script will run on stock mswin. Even if it did, I'm not sure there's a syntax to run a filter located within the repository (think initial checkout).
Can you amplify on this? Isn't the smear/clean thing, which I cited from that Pro Git book, running a filter located within the repository?
It works on initial checkout, because you have the repo before you do any checkout....
In other words, the attributes filter provides a natural hook for this type of thing; but I'm not sure its any easier for the end user to set up. At least the commit hook is optional.
Um. But having the commit hook be optional is a bug, not a feature, right?
r
On Thu, 14 Jan 2010, Robert Goldman wrote:
On 1/14/10 Jan 14 -11:29 AM, dherring@tentpost.com wrote:
Robert Goldman wrote:
Is there some reason that this cannot be pushed into the repository itself (i.e., used like a blur/clean thing)? See the bottom of this page: http://progit.org/book/ch7-2.html
I.e., we just automagically detabify when staging.
It seems inappropriate to expect everyone to fuss with his/her own repository to get this behavior. Shouldn't we do it once on the shared repo and we all get it for free?
That's a good idea, but probably not workable. First, I don't think the script will run on stock mswin. Even if it did, I'm not sure there's a syntax to run a filter located within the repository (think initial checkout).
Can you amplify on this? Isn't the smear/clean thing, which I cited from that Pro Git book, running a filter located within the repository?
The book's example is $ git config --global filter.indent.clean indent $ git config --global filter.indent.smudge cat
On my machine, these would run /usr/bin/indent and /usr/bin/cat. Later on, the book says "You can name this file expand_date and put it in your path." -- not your repository. Since these filters are used during the population of the working directory, I doubt you can use relative paths that point to scripts inside it.
Another issue is that clean and smudge modify the files; the commit hook simply rejects them. I prefer human-in-the-loop behavior when editing files.
It works on initial checkout, because you have the repo before you do any checkout....
In other words, the attributes filter provides a natural hook for this type of thing; but I'm not sure its any easier for the end user to set up. At least the commit hook is optional.
Um. But having the commit hook be optional is a bug, not a feature, right?
Its a bug, except it has the beneficial side-effect of not causing problems if it isn't set up properly.
Later, Daniel
-
Daniel Herring -
dherring＠tentpost.com
-
Robert Goldman -
Stelian Ionescu