Open jrwrigh opened 4 months ago
Rolling back to 0.6.13 and 0.6.12, I'm still seeing the exact same behavior as above. The rollback to 0.6.12 also includes rolling back to libgit2 1.7
gonna need the commits in the stack as well, or at least the hunk line numbers (ie what lines were added/removed in the affected file). the diff in the index alone is insufficient to diagnose the issue
You can replicate the offending situation from this commit.
To replicate:
git clone git@gitlab.com:phypid/honee.git
cd honee
git co jrwrigh/diff_flux_absorb_orig
git reset HEAD^
git add .
git absorb --base HEAD~9 --verbose
# There should be changes left in the index
# "Fix" that with another call to git absorb
git absorb --base HEAD~9 --verbose
# Index should now be cleared
git rebase --autosquash HEAD~31
# And now you run into a conflict when attempting to autosquash
hm. well it looks like line 284 being removed is causing an off by one somewhere (ie if i discard that one hunk from the index then the rest seems to absorb correctly). this will be very unpleasant to diagnose. no promises
Yeah, I kinda looked like an off-by-one error, but I'm not sure what exactly absorb is doing on the backend.
If it makes any difference, this is the 3rd time this kind of off-by-one issue has happened today on this branch. And I think all of them had issues with adding fixup changes to that commit specifically (feat: Add indirect div F_diff projection
).
Another thing I just noticed; if I stage all the changes except for everything below that line 284 removal (so don't stage the first diff I posted above), then the proceeding git rebase --autosquash
fails. Not sure if that failure would have any relation to the off-by-one error.
Edit: To reproduce from the above repo
# Get to remote state of `jrwrigh/diff_flux_absorb_orig` branch
git reset HEAD^
# stage correct hunks. Not sure if there's a reproducable commandline way to do this
git absorb --base HEAD~9 --verbose
git stash # stash the remaining hunks
git rebase HEAD~16 --autosquash
Which results in:
Auto-merging src/diff_flux_projection.c
CONFLICT (content): Merge conflict in src/diff_flux_projection.c
error: could not apply 04a5ba1... fixup! feat: Add divergence of F_diff projection
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Recorded preimage for 'src/diff_flux_projection.c'
Could not apply 04a5ba1... fixup! feat: Add divergence of F_diff projection
For what it's worth, I've run into these exact issues (weird off-by-one problem causing the entire process to fail) several times now.
I'm seeing some very strange (and wrong) behavior with git absorb.
Given changes with the following diff (among changes in other files):
If I run
git absorb
on these changes:and examine the end result of the added fixup commits, I instead get a diff of:
For these changes, the removed line is completely wrong, but the added back line is correct. Another point of note is that the git index was not emptied, but
git absorb
did not report that fact like it normally would.Running
git absorb
again does correct the problems in this circumstance, but I ran into an very similar issue before where repeatedly runninggit absorb
did not fix things, but added further erroneous fixup commits.Also, even after running
git absorb
multiple times, the fixup commits do not rebase in without conflicts.This is with git absorb version
0.6.15
according to the arch package installation (the version flag doesn't work, see https://github.com/tummychow/git-absorb/issues/115)