Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> This RFC is about better naming of subroutines in gitweb. The patch was >> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56) >> using embedded gitweb-rename.sh script. [...] >> * git_read_ prefix for subroutines directly accessing git >> repository files > > - (I am not complaining or objecting yet -- this is just an > observation. ) The distinction between git_get_foo and > git_read_foo is an implementation detail. The latter could > signal that the implementation bypasses the published > interface but depends on the implementation detail of the > low-level git, so it might be a good idea, but on the other > hand the only instance is git_read_info_refs which reads from > .git/info/refs -- and its format is part of the published > interface -- so I am not so sure this distinction is worth > it. And certainly we would not want to rely too heavily on > the current implementation of the low-level git, so we > obviously do not want to add more git_read_foo's needlessly, > which makes me feel even less sure if we would want > git_read_foo... Currently after rename we have the following git_read_* functions * git_read_info_refs, which reads .git/info/refs directly and relies on it's format * git_read_hash which translates ref to hash by reading ref file (e.g. .git/refs/heads/master) which means that it doesn't support symrefs yet; but first, it should be easy to implement without invoking any git command, and second, there are usually no symrefs beside HEAD, and I'm not sure that git would work with non-HEAD symref. * git_read_refs (or rather git_readdir_refs) which reads .git/refs directory * git_read_projects (or rather git_readdir_projects) which checks for projects checking if HEAD file exists * git_read_description which reads .git/description; but in the future description might be stored in repository config What is also important is the fast that git_read_* functions are fast, with exception of git_read_info_refs... [...] > If we are to have many more fixes and clean-ups on gitweb, > readable and consistent names would be very helpful. > > The problem is when. If we are going to apply this, we need to > pick a point of time when not many patches on gitweb are in > flight; otherwise I'd end up asking people to resend using new > names. With two scripts attached to the first post in this thread it would be simple to apply pre-rename patch, by converting gitweb to pre-rename using gitweb-unrename.sh script, then applying patch, then restoring new names using gitweb-rename.sh script, and finally comitting changes (or amending commit). But I agree that it would be best to do "subroutine renaming" during lull in gitweb development. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - : 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