Add instructions on what to do when there are still staged changes after running git absorb

[danielcompton]

I ran git absorb and it created a number of fixup commits, but still left many staged changes. The documentation doesn't say what to do here, or what this means. I'm assuming that it means that absorb couldn't find any existing commits to fixup?

It could be good to explain what this means in the documentation, and give suggested remediation steps. If you have any staged changes then you can't proceed to the next step of git rebase -i --autosquash.

Apologies if I'm misunderstanding something!

[tummychow]

I'm assuming that it means that absorb couldn't find any existing commits to fixup?

yep, this understanding is correct. absorb will leave things in the index if it couldn't find a place to absorb them into.

i believe nickolay actually added some logging for this in #17 , which i just cut into a new release (https://github.com/tummychow/git-absorb/releases/tag/0.5.0) - give that a try and let me know what you think?

[nunofgs]

It would be awesome to have some sort of interactive mode. Maybe a flag -i to force git-absorb to ask you which commit to place the changes.

Edit: maybe even an interactive mode such as git's patch staging mode (git add -p). It could show you each chunk and it would ask me which commit I'd like to absorb into. I could then decide to "split chunks", "do nothing" or choose a commit from the list.

[tummychow]

It would be awesome to have some sort of interactive mode. Maybe a flag -i to force git-absorb to ask you which commit to place the changes.

sorry but

1. implementing all those prompts would be a colossal amount of work

2. which is almost 100% redundant with the existing functionality of git rebase -i

if you want to arrange the commits manually, that's literally what interactive rebases are already for (e: which, by the way, is how git absorb itself actually works - if you only disagree with git absorb a little bit, you can do the rebase yourself and adjust the ordering that git absorb came up with, you don't need an entirely new user interface for that).

[blairconrad]

@nickolay's change helps, in my opinion. Current output, with one new file staged (I figured it was the quickest way to get something that commuted with everything):

Mar 02 20:33:13.548 WARN Will not fix up past the merge commit, commit: 504d600e7b24c2164e61ba49f956b22520f68a8d
Mar 02 20:33:13.565 WARN Could not find a commit to fix up, use --base to increase the search range.

(update: the second WARN only appears if HEAD isn't the merge commit. If HEAD is a merge, we exit earlier with CRIT "No commits available to fix up, exiting")

As a novice user, I saw this and immediately ran git status and saw that my file was still staged, and figured out why: the new file didn't interact with any of my recent changes. Similar experience when I made a change far from any other changes in recent commits.

Is the output good enough to indicate to most users what the next steps would be? Unclear. For me (in the frame of mind when I first encountered the output) it was. But users differ. If there's a desire to adjust the output, then off the top of my head:

1. saying that the tool will not fix up past merge commit 504d600 is inconsistent with the advice to use --base to increase the search range. As I understand it, nothing will coerce git-absorb to fixup past a merge commit, so if the calculated base is already a merge, no sense specifying --base (unless the user wanted to restrict the search space, but that's another scenario)
2. consider explicitly mentioning that some staged changes remain uncommitted. "could not find a commit..." hints at it, but it might not be clear to all. Perhaps a message to that effect, indicating that the user must examine the changes and (if desired) commit fixups (or squashes, if Option to create a squash! commit #97 ever is implemented) against appropriate commits themselves; the tool is best-effort and it's reasonable to expect that it won't be able to match every change to a prior commit

[tummychow]

i think a change to implement your first point (don't output the --base hint if the search has already reached a merge and can't go any further) is reasonable. i'm ambivalent on the rest. the intended ux is so inherently magical that i kind of don't think you can advise users on what to do if it doesn't exactly match their expectations. (eg cks and i were just discussing an example of this over here - in that specific case, it would have made sense to suggest -w, but there are many cases where that would not make sense, so now what? you... tell the user to read the docs?)

[blairconrad]

First, I read your comment on the blog. Thank you.

For point 2 in my previous comment, I may not have been clear. I meant to suggest no more than to output something that conveys "not all staged changes were converted into commits; you'll have to deal with the rest by hand", rather than just talking about the search boundaries:

Mar 08 00:15:00.568 WARN Will not fix up past the merge commit, commit: 504d600e7b24c2164e61ba49f956b22520f68a8d
Mar 08 00:15:00.641 WARN Could not find a commit to fix up, use --base to increase the search range.

Agree that giving comprehensive advice would be impossible, but

...
Mar 08 00:15:00.713 INFO Some staged changes remain; no target commit was found to fix up. You will have to manually create fixup commits."

(with more polished wording) might give people a bit of a hint. Maybe it's too much hand-holding and too little actual help.

[tummychow]

yeah that seems ~fine. it's probably not worth thinking too hard about the wording

[blairconrad]

I can take this. As usual, I'll probably do extraneous work to characterize current behaviour. It might be a little extra, but will be easily droppable.