NhatKhai

I found this may be the link to hint of solving this issue: https://www.spinics.net/lists/git/msg424302.html On my end I would insert code to ignore error 141 code all over the place...

`git status` also return 141! ``` [t_lfs_svncommit] 18:59:02.576587 git.c:455 trace: built-in: git status --porcelain [t_lfs_svncommit] 18:59:02.582547 run-command.c:666 trace: run_command: 'git-lfs filter-process' [t_lfs_svncommit] 18:59:02.709292 trace git-lfs: exec: git 'version' [t_lfs_svncommit] 18:59:02.804899...

But here is the kicker that I don't know how to work around. `git rebase` return 1 for this: ``` [t_lfs_svncommit] 18:59:00.863351 git.c:455 trace: built-in: git rebase -s recursive -X...

I think this could be fix within git-lfs. I design a simple filter before, and I think I remember I had to fix this issue 141. However, would you mind...

That right it could be git-lfs, git, cygwin bash, jenkins java agent. I run via jenkins 100 time it fail 100 times, I run via cmd console 100 time it...

If the sshd services run under a valid domain/a normal local account difference than the default "Local Account" - the cmdkey will work just fine.

The parser do a sort, with cause everything move around. In 4.7.x they aren't save back in the file that way - which actual better compare to blindly sort everything....

I'm sort of solving this issue in my script using my own iterator parser: [nhatkhai/kicad_scripts](https://github.com/nhatkhai/kicad_scripts/blob/master/bom_plugins/bom2sch.py)

Could be possible that we have multiple one so we can either search for the object one by one on the list, or parallels when fetch? My company having a...

Feedback or merge this please p