I was just looking at the sample pre-commit in the .git directory, and
it actually includes an example that’s partially relevant for us.
Cross platform projects tend to avoid non-ascii filenames; prevent
them from being added to the repository. We exploit the fact that the
printable range starts at the space character and ends with tilde.
if [ “$allownonascii” != “true” ] &&
# Note that the use of brackets around a tr range is ok here, (it’s
# even required, for portability to Solaris 10’s /usr/bin/tr), since
# the square bracket bytes happen to fall in the designated range.
test "$(git diff --cached --name-only --diff-filter=A -z $against |
LC_ALL=C tr -d ‘[ -~]\0’)"
then
echo "Error: Attempt to add a non-ascii file name."
echo
echo "This can cause problems if you want to work"
echo "with people on other platforms."
echo
echo “To be portable it is advisable to rename the file …”
So after spending time on this, I realize my shell scripting skills
suck. But what we basically need in a pre-commit hook is the following
function:
slugify - many frameworks have it; it just converts strings to
this-form-of-lower-case.
We then just need to run this function on the id and filename, and
make sure they’re consistent.
I’d venture to say that, so long as there’s no conflict with other
files, it might be OK for this script to just make the change and
report it before committing.
Bruce
Maybe git is different, but at least with SVN, making modifications in
pre-commit hooks is not a good idea, since the client state is then wrong.
See warning in red box here:
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks
(I’m not even sure how one would go about modifying the commit with an
SVN pre-commit hook, which just returns a non-zero error code to reject
the commit, though that page seems to imply that it’s possible somehow.)
OIC. So the idea of the pre-commit script is essentially a
gate-keeper: to either accept or reject the commit?
In terms of the model we’re considering for the github org, it’d be
valuable to flag problems early (in the pre-commit hook), but maybe
more important for the “Style Editor” team members to be ale to easily
fix potential problems.
So I guess we could have two scripts.
Bruce
When we set up the CSL section of the Zotero repo, we decided not to
reject invalid styles in the pre-commit hook and just flag them as
invalid on the site, the idea being that it was better to get them
committed and available to view, and then either the original authors or
others would fix the errors.
I think either way would be fine, and maybe there are enough styles at
this point that rejecting invalid ones makes more sense, but that’s the
calculation we made back then.
Bruce,
tr is a handy utility for case conversion:
echo One-Two-Three > tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnokqrstuvwxyz
Yeah, I figured that one out, but got stuck on how to simultaneously
convert non-word characters to dashes.On Jan 29, 2011 6:09 PM, “Frank Bennett” <@Frank_Bennett> wrote:
Bruce,
tr is a handy utility for case conversion:
echo One-Two-Three \
tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnokqrstuvwxyz
On Sun, Jan 30, 2011 at 5:08 AM, Dan Stillman <@Dan_Stillman> wrote:
On 1/29/11 2:56 PM, Bruce D’Arcus wrote:
In terms of the model we’re considering for the github org, it’d be
valuable to flag problems early (in the pre-commit hook), but maybe
more important for the “Style Editor” team members to be ale to easily
fix potential problems.
So I guess we could have two scripts.
When we set up the CSL section of the Zotero repo, we decided not to
reject invalid styles in the pre-commit hook and just flag them as
invalid on the site, the idea being that it was better to get them
committed and available to view, and then either the original authors or
others would fix the errors.
I think either way would be fine, and maybe there are enough styles at
this point that rejecting invalid ones makes more sense, but that’s the
calculation we made back then.
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better
price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better
price-free!
I never used that:
tr “[:upper:]” “[:lower:]”
but it works 
Can you define “non-word-characters”?
Something like?:
echo “test12334dkdkd” | sed ‘s/[^a-z]/-/g’
(change everything that it’s not in the range a-z by a dash?)
Or for “lazy” people:
echo One-Two-Three | tr “[A-Z]” “[a-z]”
But in other place we said that we would not change the file when it’s
being committed, no?
BTW, the scripts for the pre-commit hook in github: can only run Bash
and Unix commands? Or also something else? (thinking in Python). Which
modules? (thinking in some XML parser)
(is it in the server side, no? I cannot remember now… 
)
Or for “lazy” people:
echo One-Two-Three | tr “[A-Z]” “[a-z]”
But in other place we said that we would not change the file when it’s
being committed, no?
BTW, the scripts for the pre-commit hook in github: can only run Bash
and Unix commands? Or also something else? (thinking in Python). Which
modules? (thinking in some XML parser)
The latter; see:
http://blog.aizatto.com/2009/09/12/ruby-on-rails-git-pre-commit-hook/
(is it in the server side, no? I cannot remember now… 
)
The pre-commit hooks are local (client-side), but there also
server-side analogues (post-receive hooks and such).
Bruce