tummychow / git-absorb

git commit --fixup, but automatic
https://crates.io/crates/git-absorb
BSD 3-Clause "New" or "Revised" License
3.38k stars 58 forks source link

Allow --force to continue past "HEAD is not a branch" check. #49

Closed zenspider closed 2 years ago

zenspider commented 2 years ago

Fixes #47.

I tried to use this while in an edit stage of an interactive rebase, hoping to detach the current commit and absorb some chunks above. This should allow that.

I assume I interpreted your feedback on #47 correctly. Happy to reword or restructure.

Please note: I'm coding blind. I don't have any rust tooling or (successful) history with it.

tummychow commented 2 years ago

so this is completely untested right? i'll give it a spin later this week

zenspider commented 2 years ago

Correct

On Oct 5, 2021, at 19:00, Stephen Jung @.***> wrote:

 so this is completely untested right? i'll give it a spin later this week

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

tummychow commented 2 years ago

this works, and it does what i expect it to do so i'm going to merge it, but it might not do what you wanted it to do. it indeed hides all the branches if HEAD is detached... including whatever branch HEAD might have been before it got detached. so if you have a linear commit structure like this:

* 4444 <- HEAD, master
|
* 3333
|
* 2222
|
* 1111

and let's say you git rebase --interactive 1111, you choose edit 3333 in the rebase, what will happen?

* 4444 <- master
|
* 3333 <- HEAD
|
* 2222
|
* 1111

now let's say you make some changes to the working tree with 3333 checked out, and you run git absorb --force. it'll hide all ancestors of the master branch, which includes 3333, so there will be no commits in the stack, and you'll get the "No commits available to fix up" error.

if you messed with the commit manually (eg you amended some other change to it), and then you ran git absorb, the commit tree would look like this:

* 4444 <- master
|
* 3333
|
| * 5555 <- HEAD
|/
* 2222
|
* 1111

all the ancestors of the master branch would be hidden, so the commit stack would consist of just 5555. you wouldn't be able to absorb earlier into, say, 2222 (unless you used the --base flag). my guess is, what you really want is for git absorb to pick the root of the rebase as the default base if there is one. that would be a bit harder to do; idk if libgit2 makes it easy to get that information.