Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)
This is much faster (below 0.1s):
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file;
if [ -d "$dir" ]; then
__git_ls_files_helper "$root" "$1" | \
sed -r 's@/.*@@' | uniq | sort | uniq
fi
}
time __git_index_files
real0m0.075s
user0m0.083s
sys0m0.010s
Most of the improvement is due to the simpler, non-grouping, regex.
Since I expect most of the common prefixes to arrive consecutively,
running uniq before sort also improves things a bit. I'm not removing
leading double quotes anymore (this isn't being done by the current
version, anyway) but this doesn't seem to hurt.
Despite the dependence on sed this is ten times faster than the
original, maybe an option to enable fast index completion or something
like that might be desirable.
Best regards
--
Carlos
Index files autocompletion too slow in big repositories (w / suggestion for improvement)
Hi all,
I'm currently using git annex to manage my entire file collection
(including tons of music and books) and I noticed how slow
autocompletion has become for files in the index (say for git add).
The main offender is a while-read-case-echo bash loop in
__git_index_files that can be readily substituted with a much faster
sed invocation, although I guess you didn't want the sed dependency in
the first place. Anyway, here is my benchmark:
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file;
if [ -d "$dir" ]; then
__git_ls_files_helper "$root" "$1" | while read -r file; do
case "$file" in
?*/*)
echo "${file%%/*}"
;;
*)
echo "$file"
;;
esac;
done | sort | uniq;
fi
}
time __git_index_files > /dev/null
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file;
if [ -d "$dir" ]; then
__git_ls_files_helper "$root" "$1" | \
sed -r 's@^"?([^/]+)/.*$@\1@' | sort | uniq
fi
}
time __git_index_files > /dev/null
real0m0.830s
user0m0.597s
sys0m0.310s
real0m0.345s
user0m0.357s
sys0m0.000s
Notice I'm also excluding the beginning double quote that appears in
escaped path names.
Best regards
--
Carlos
Allow worktree in same path with different gitdir
Hi all, I usually keep my dotfiles, scripts, etc. in a git repo at ~, both as a backup solution and as a way to sync config between my different computers and remote servers in which I have to work. Some of these computers require a small number of local configurations that I like to keep in a repo too (mainly for backup purposes). These modifications to the base repo may be made branches of the base configuration but then keeping the common configurations in sync between all branches becomes cumbersome and error prone, with a lot of rebasing, cherry picking, stashing and whatnot. What I prefer is to create an orphan branch for local files, create a worktree for this branch, then move this worktree gitdir to something like ~/.gitlocal, next to the main ~/.git, update .git/worktrees to avoid pruning and define a handy alias like lgit='GIT_DIR=~/.gitlocal git'. This way I'm able to keep some files below ~ in a specific branch and some others in a shared master branch, all at the same time and in the same directory. What I find a bit cumbersome about this workflow is the inability to directly create the worktree at . specifying a gitdir like .gitlocal. Is there any fundamental reason this is not allowed for the worktree subcommand? If not, please consider this a feature request. Notice the same is valid for cloning the ~ repo, instead of just creating a worktree from it. The clone subcommand will also reject a . path and also doesn't provide a way to specify a different gitdir (even --separate-git-dir requires a "fake" .git). Cheers -- Carlos -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Graph log and orphan branches
> - return "*"; > + return commit->parents ? "*" : "^" ; I like this idea. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug] Graph log and orphan branches
Hi all, the graph output of log show orphan branches in a way that suggests they have a parent. See for example: http://stackoverflow.com/questions/22541261/git-log-of-all-branchs-in-only-the-current-tree I think this is a bug in the UI. Cheers -- Carlos -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Graph log and orphan branches
> http://stackoverflow.com/questions/22541261/git-log-of-all-branchs-in-only-the-current-tree > > I think this is a bug in the UI. Please notice this happens only for the --oneline output. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Add submodule specifying depth and branch at the same time won't work
For example, I can do: git clone --depth 1 --branch devel g...@gitlab.com:memeplex/bash.git But if I try: git submodule add --depth 1 -b devel g...@gitlab.com:memeplex/bash.git I get: fatal: Cannot update paths and switch to branch 'devel' at the same time. Did you intend to checkout 'origin/devel' which can not be resolved as commit? Unable to checkout submodule 'src/aur/bash' I think the devel branch is left outside the update because depth is just 1, but then the same could be said for the clone, which just works. The request should be interpreted as depth 1 inside devel branch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
