-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git absorb fails with latest version sometimes #116
Comments
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 ( |
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 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:
|
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. |
Because each hunk needs to be displaced based on the previously applied hunk, sorting hunks will change the order in which they are applied, therefore undoing all our previous calculations. This fixes tummychow#116, but breaks the --one-fixup-per-commit feature in cases where there is an odd hunk in between some hunks that could've been merged together.
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 #115)The text was updated successfully, but these errors were encountered: