Open sluongng opened 2 years ago
signal 11 is a segfault, which probably means a libgit2 issue. i'll have to check what libgit2 is getting statically linked as part of the crate. do you have a repo that reproduces the issue? (including the index state at the time that you run git-absorb)
No sorry it was in an internal repository cannot be shared
I tried to diff the git config between a small repo of mine where git-absorb was working
--- /tmp/1.txt 2022-06-07 09:08:55.932322950 +0200
+++ /tmp/2.txt 2022-06-07 09:12:07.788995354 +0200
@@ -2,43 +2,29 @@
alias.co=checkout
alias.st=status
branch.master.merge=refs/heads/master
color.ui=true
-commit.template=/Users/sngoc/.gitmessage
commit.verbose=true
core.bare=false
core.editor=nvim
core.filemode=true
-core.fsmonitor=.git/hooks/fsmonitor-watchman-v2
-core.fsmonitorhookversion=2
core.ignorecase=true
core.logallrefupdates=true
core.pager=less -X -F
core.precomposeunicode=true
core.repositoryformatversion=0
-core.sparsecheckout=false
-core.sparsecheckoutcone=false
credential.credentialstore=keychain
credential.gitlabauthmodes=browser
credential.guiprompt=false
credential.helper=/usr/local/share/gcm-core/git-credential-manager-core
diff.wserrorhighlight=all
extensions.worktreeconfig=true
-feature.experimental=1
-feature.manyfiles=1
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.smudge=git-lfs smudge -- %f
-gc.autopacklimit=40
index.sparse=false
init.defaultbranch=master
-lfs.allowincompletepush=1
lfs.fetchrecentalways=true
-lfs.repositoryformatversion=0
-log.excludedecoration=refs/prefetch/
-maintenance.auto=false
-maintenance.strategy=incremental
merge.stat=false
oh-my-zsh.hide-dirty=1
oh-my-zsh.hide-status=1
exit 1
The ones with -
prefix are the configs exclusive to the internal repo.
Do you have any troubleshooting commands that I can run?
well, to be blunt, there's nothing i can do without a repo that repros the segfault, period. i can't give you a command that just demonstrates the problem, because it's a segfault. you could get a core dump out of the segfault, but then you'd have to gdb into it yourself, which would be a miserable experience for most people (i just finished gdbing something for a glib2 issue and i wouldn't wish it on my enemies - no offense to glib2). i would rather we find the segfault reproducer and file a bug for the libgit2 people to gdb into. the git config is almost certainly not relevant to the issue (libgit2 tends to lag behind actual git in its config support, so new features have no impact on libgit2), although i'd test the internal repo with the git config from the working repo just to be sure.
if the repo is internal and you can't dump the whole thing on the internet, you're going to have to find a way to trim the reproducer down to something artificial that you can share with me. keep in mind that git-absorb only looks at the commits in the stack (ie the commits that are exclusive to your branch) plus the index state. you don't need to give me the entire repo. i would focus on the content of those things and try to find the smallest of each that reproduces the issue:
I tried using git-absorb today and just got an error message
No clue how to troubleshoot this 🤔