investigation results

Also, close dup bug.
This commit is contained in:
Joey Hess 2021-11-02 15:06:20 -04:00
parent 438e5b56aa
commit 38ba8cca1b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 34 additions and 0 deletions

View file

@ -26,3 +26,5 @@ Doing a `git checkout .` at this point took about a minute. In comparison doing
### Please provide any additional information below.
The relevance of this problem is that I tried to go from a lock-adjusted branch to its basis with about 50000 unlocked files with `git checkout`. It was taking longer than expected and there were many warnings about a cosmetic problem and advised me to run `git update-index -q --refresh <path>`. Eventually I deleted the entire working tree, did `git reset --hard` to recreate the unlocked file stubs, locked every file and unlocked them again.
> [[dup|done]] --[[Joey]]

View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2021-11-02T17:58:27Z"
content="""
This is due to [[todo/git_smudge_clean_interface_suboptiomal]].
"""]]

View file

@ -122,3 +122,28 @@ The best fix would be to improve git's smudge/clean interface:
>
> If this was possible, it should speed up git checkout etc which use the
> smudge filter. --[[Joey]]
> > Tried that, it looks like when the long-running filter process
> > sends only capability=smudge, and not clean, git add does not
> > fall back to running filter.annex.clean. So unfortunately,
> > it's not that easy.
> >
> > To proceed down this path, git-annex would need to use
> > the long-running filter process for clean too. So `git add`
> > would end up piping the whole content of large files over to git-annex,
> > which would have to read and discard that data. This would
> > probably make git-annex twice as slow for large files, although
> > it would speed up git add of many small files. git-annex add
> > could be used to work around any speed impact.
> >
> > Or git could be extended
> > with a capability in the protocol that lets the clean filter read the
> > file content from disk, rather than having it piped into it. The
> > long-running filter process protocol does have a design that would let
> > it be extended that way.
> >
> > Or, I suppose git could be changed to run the clean filter when
> > the long-running process does not support capability=clean. Maybe
> > that would be more appealing to the git devs. Although since
> > it currently does not run it, git-annex would need to somehow
> > detect the old version of git and still work. --[[Joey]]