$_fish_git_prompt_showupstream can be set to a list of values to determine how changes between HEAD and upstream are shown: $_fish_git_prompt_showuntrackedfiles or the git option bash.showUntrackedFiles can be set to 1, true or yes to show if the repository has untracked files (that aren’t ignored). $_fish_git_prompt_showdirtystate or the git option bash.showDirtyState can be set to 1, true or yes to show if the repository is “dirty”, i.e. It also changes the characters the prompt uses to less plain ones ( ✚ instead of * for the dirty state for example), and if you are only interested in that, set $_fish_git_prompt_use_informative_chars instead.īecause counting untracked files requires a lot of time, the number of untracked files is only shown if enabled via $_fish_git_prompt_showuntrackedfiles or the git option bash.showUntrackedFiles. In large repositories, this can take a lot of time, so you may wish to disable it in these repositories with git config -local bash.showInformativeStatus false. $_fish_git_prompt_show_informative_status or the git option bash.showInformativeStatus can be set to 1, true or yes to enable the “informative” display, which will show a large amount of information - the number of dirty files, unpushed/unpulled commits, and more. git options can be set with the git config command, while fish variables can be set as usual with the set command.īoolean options (those which enable or disable something) understand “1”, “yes” or “true” to mean true and every other value to mean false. git options can be set on a per-repository or global basis. git options, where available, take precedence over the fish variable with the same function. There are numerous customization options, which can be controlled with git options or fish variables. The fish_git_prompt function displays information about the current git repository, if any. So I removed and re-cloned the VM PC repo to see if a fresh clone makes a different.Function fish_prompt printf '%s' $PWD ( fish_git_prompt ) ' $ ' end Description ¶ Here are the results of: git count-objects -v: VM PC count: 281 The Build PC one is a more recent clone - but I would hope that the count debug would be the same. On the two different machines - they are testing against the same exact repo (cloned in the same way from the same remote). so its not an issue with the 2nd/3rd SSD or how they are mounted. I tried this on the OS SSD on the Build PC and still get the slower result. I am not sure where to start debugging this issue so I thought I would start in this forum :) update Whereas on the VM its all on one SSD within the virutal box disc image (its about 500GB) The main difference is that the Build PC has 3 physical 1 NVmem and 2xSSDs: If I just do git status on the top level I get ~2s on the Build PC and ~0.5s on the VM PC.īoth are running the same git version 2.17.1 - infact the two Ubuntu's where setup using the same installation scripts - so they are really very similar. I have a very large repo structure, but when I run time git submodule foreach -recursive git status I get wildly different times: the other is an Ubuntu PC (call it Build PC)īoth are running on the same hardware (different physical machine - but same hw build).I am not sure if this is an ubuntu issue or a git issue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |