Re: git-shortlog hangs on bare repo without --bare option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 27, 2008, 23:09 UTC
- Message-ID
- <7vfxoqm4vs.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <7vod3em67d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> And I think this is related to the complexity that snuck in when worktree > feature was added to the setup sequence. > > Untested, but I think this would help.
While it might help, I see there are more serious issue here.
If you start "git-shortlog" (or anything that has USE_PAGER but not RUN_SETUP in git.c) inside your project/.git directory (or a bare one, for that matter), the call sequence would become like this:
git.c::main()
-> handle_internal_command()
-> run_command()
-> commit_pager_choice()
-> setup_pager() (this is in pager.c)
-> git_config(git_default_config, NULL)
-> git_path("config")
-> get_git_dir()
-> setup_git_env()
This sets git_dir to ".git"!!!!And that was part of the reason why "git-shortlog" started from a bare repository did not even notice that the default "HEAD" that is given internally by the program is not a valid ref (because it tries to read from .git/HEAD without the patch I sent earlier).
This may be repeating what Jeff said earlier in another thread, but I think we should rethink the start-up sequence carefully. Ideally (I am thinking aloud)...
* Have a single function "git_setup()" that notices --bare and --git-dir from the command line and GIT_DIR environment, and does the discovery of git_dir (if not told with the command line or environment explicitly); if we do not find it, do *NOT* barf. Just record the facts it finds somewhere (e.g. the location of git_dir, absense of git_dir, if the repository is explicitly bare, etc.).
* As the next step, still in this single function, if we have git_dir, find out where the work_tree is, paying attention to --work-tree from the command line and GIT_WORK_TREE environment if exists. If we do not have work tree, do *NOT* barf. Again, just record the facts it finds. If we do not have --work-tree from the command line and if we are not told that it is --bare from the command line, then we may need to open the config to see where core.worktree points at.
* Before returning from that single setup function, i think it is Ok to make it mimick the current git_setup_directory_gently(), cd up to the normal work-tree top if needed, and make it return prefix.
* After all of the above is done, then we can start futzing with other things such as pager. At that point we know we can read from the correct configuratoin.
* Each individual command may decide to refuse to work in the absense of git_dir and/or work_tree, by calling require_work_tree(), etc.
Hmm?