On Sat, Jul 2, 2011 at 11:23 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: >> On Sat, Jul 02, 2011 at 10:18:55PM +0300, Al Haraka wrote: >> >> > > which will make the repository-wide non-version-controlled gitattributes >> > > the same as the last committed version. The problem is that it won't be >> > > automatically updated as you commit and push changes to .gitattributes. >> > >> > I thought my plan was to try and avoid this by using the >> > core.attributesfile directive, forcing this stuff to operate system >> > (well, account, besides the point here) wide on all repos with >> > specifying a .gitattributes (or, since it base bare, as you pointed >> > out yourself, $GIT_REPO_DIR/info/attributes) every single time. Did I >> > misunderstand the mailing list thread that mentioned this a while >> > back? >> >> Ah, I see. That seems like a reasonable solution. Are you sure that the >> user running gitweb as a CGI is the same as the user you log in as? That >> is, are you sure that ~/.gitconfig is being parsed when it is called as >> a CGI, and it's not looking in ~www/.gitconfig or something? >> >> It would depend how your hosting is set up. > > Well, there is also system wide $(prefix)/etc/gitconfig file... Unfortunately, this is on Dreamhost. I do not have root access, and this is a kludge. I know what I am asking for is a very exclusive use case, but I would love to have this kind of feature until people tell me it cannot be done. Haha. >> > This is the reason I went through the trouble of compiling an updated >> > version in my account (as opposed to the installed version on the >> > Dreamhost box; they are stuck at version 1.7.1.1; I saw this mentioned >> > on a thread somewhere and wanted to get the "latest" (well latest >> > stable version) to avoid this kind of problem? Was that the right >> > thing to do? Will it even work in this case? I get the feeling from >> > your response I was expecting a lot with RTFM'ing more. >> >> It sounds like it should work to me, but I've not tested it (nor do I >> even run gitweb; I just have an interest in textconv). > > The question is if --textconv works with git-diff-tree, because that > is what gitweb uses. It does work on git-dif-tree when I just checked. So, I presume that this means Jeff is right, and it must be not pulling the config from the right location? Jeff, on that note, I fear you are right about the appropriate user executing the script: http://wiki.dreamhost.com/Suexec I get the feeling this is the case because in several instances I thought I was clever with my use of ~ or $HOME, or the tutorial writer had been himself. In those instances, using full paths and not user-specific environment vars fixed the issues. So, I guess I need to figure a way to pass the config vars appropriately? I already changed the core.attributesfile from ~/.gitattributes to /home/dreamhost_user/.gitattributes in anticipation, but I know that is only the first step. I need to go to head out for a bit. I will revisit the issue tomorrow morning when I have time to think about the right way to fix passing the environment variables for suexec. I am an idiot. > BTW. we could use --textconv in 'blob' and 'blame' views (it is > documented that git-cat-file supports --textconv, and it is checked in > git testsuite but not documented that git-blame supports --textconv). > But it would require changes to gitweb. > > > Hoping that this email will made it... It made it indeed. Much appreciated for both your efforts so far. > -- > Jakub Narebski > Poland > ShadeHawk on #git > -- Alexander J. Stein Cell: +974 70013750 Email: alharaka@xxxxxxxxx Skype: alexander.j.stein -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html