W dniu 09.12.2012 10:18, Junio C Hamano pisze: > Łukasz Stelmach <stlman@xxxxxxxxx> writes: > >> Enable gitk read and write repository specific configuration >> file: ".git/k" if the file exists. To make gitk use the local >> file simply create one, e.g. with the touch(1) command. >> >> This is very useful if one uses different views for different >> repositories. Now there is no need to store all of them in >> ~/.gitk and make the views list needlessly long. > > I do not use gitk heavily myself, but I have a mixed feeling about > this patch. > > Forking the configuration from the one true ~/.gitk is easy; it is > just the matter of copying it to repository specific location. Once > forked, however, it is very hard to merge these configuration files > sprinkled across repositories back, or more importantly, change the > settings globally. For the record, I assumed someone using git is capable of doing some simple tricks with find, sed and the like. Merging configuration from the global file (~/.gitk) is quite easy as the file is sourced just before the local file. If any option is not set in the local file the global value is effective. To handle the case you describe below... > Imagine you just got a new monitor that is a lot > finer grained than the one you have been usingq, and your choice of > font size has been specified in terms of pixels; you would want to > show all gitk windows in larger font now, regardless of the > repository, but you now have to go to 47 different configuration > files and update them. you need to (assume one keeps git repositoris below $HOME) 1. Enter a random repository 2. mv .git/gitk .git/gitk-local (see below) 3. Run gitk, configure fonts to your taste, save config (it will be saved globally) 4. mv .git/gitk-local .git/gitk 4 Do a trick $ find ../ -name gitk -type f -path '*/.git/gitk' -print0 | \ xargs -0 sed -i -e '/^set [a-z]\+font /d' Now the font settings from ~/.gitk will be applied (and saved locally when gitk exits) in every repository find(1) found. > So I suspect that this may introduce more trouble than it is worth > for users and should not be sold with a "This is very useful" label. > At best, it is "This may be useful"; I work with more than two dozen different repositories and saving the list of branches I want to see upon startup is quite important for me. > otherwise the feature may end > up harming our users. I'd phrase it without judging if it is good > or bad for the users, perhaps like this: > > This allows one to specify different views for different > repositories. At present the code won't harm anyone not willing to get harmed. To make gitk save the configuration locally user needs to create the configuration file manually, outside of gitk, for example with touch(1) (yes it may be empty). > In any case, the filename .git/k may be _cute_, but I do not think > we would want to see: > > $ ls .git > branches config HEAD index k objects > COMMIT_EDITMSG description hooks info logs refs I agree this was just to draw your attention ;-) > It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd > call it $GIT_DIR/gitkconfig or something, if I were supportive for > this feature (which I am not enthusiastic, yet). I think simply $GIT_DIR/gitk as in ~/.gitk is going to be fine. -- Było mi bardzo miło. Czwarta pospolita klęska, [...] >Łukasz< Już nie katolicka lecz złodziejska. (c)PP -- 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