investigation results
Also, close dup bug.
This commit is contained in:
parent
438e5b56aa
commit
38ba8cca1b
3 changed files with 34 additions and 0 deletions
|
@ -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]]
|
||||
|
|
|
@ -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]].
|
||||
"""]]
|
|
@ -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]]
|
||||
|
|
Loading…
Reference in a new issue