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