Hi Duy, On Fri, 9 Dec 2016, Duy Nguyen wrote:
> On Thu, Dec 8, 2016 at 10:35 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > Hopefully these patches will lead to something that we can integrate, > > and that eventually will make Git's startup sequence much less > > surprising. > > What did it surprise you with? I mentioned a couple of WTFs elsewhere: - that it changes the working directory (personally, I am not surprised, just because I was exposed to the Git source code for 10+ years, however, I know developers who do not share that experience and find that feature... interesting) - that there are multiple code paths to do essentially the same thing, but in an incompatible manner: setup_git_directory() and setup_git_env() (and possibly more) - that some environment variables are set, and need to be unset (or even possibly reset to no-longer-known values) to allow subprocesses to access different repositories - that git_path() can be used before setup_git_directory() without failure, but wreaks havoc with subsequent git_config() calls. - that the setup_git_directory() cascade is completely oblivious of whatever config has already been read (possibly requiring clearing) - that setup_git_directory() *returns* the prefix, even stores it in startup_info, but a subsequent call to setup_git_directory() returns NULL - that as a consequence, builtins that require the prefix to work if there is any, but do not necessarily require a repository to begin with, think `git diff`, *must not* be marked with RUN_SETUP_GENTLY - that check_repository_format() sets have_repository=1 - that setup_git_directory() is a oneliner, calling setup_git_directory_gently(NULL), when it would be more logical to simply make setup_git_directory() accept the "nongit_ok" parameter - that setup_git_directory_gently() is not at all gentle when the parameter is NULL - that resolve_gitdir() does not, in fact, resolve any git directory, but only tests a specified path whether it refers to a .git/ directory or to a .git file - that resolve_gitdir() actually tests for a .git *file* - that resolve_gitdir() is not used in setup_git_directory_gently_1() - that resolve_gitdir() tries the order directory,file and setup_git_directory_gently_1() tries the opposite order - that the handling of the ceiling directories is hardcoded into the setup_git_directory_gently_1() function - that a ceiling directory of /home/hello/world does not prevent Git from looking at /home/hello/world/.git/ - that canonicalize_ceiling_entry()' relationship to ceiling directories is rather coincidental when the name suggests that it is very specific - that canonicalize_ceiling_entry() does not, in fact, canonicalize non-absolute entries Need I go on? I could, you know... > I can see that I disrespect the ceiling directory setting, perhaps > that's that. No, I actually see a lot of good reasons for the ceiling directories. Ciao, Dscho
