Add button which calls `git absorb --and-rebase` (Squash single line change into most recent commit modifying that line `git vanish`)

[devinrhode2]

I believe default behavior here should be to wrap the git commit --squash option.

See: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---no-autosquash

Here's a more specific, detailed example:

person went to store
forgot ther bk lok // ** NOTE THIS LINE
someone stole the bike

I commit this:

git add -A && git commit -m "Initial commit asdf"

Later on, the story(i.e. code) has MANY more changes. Chapter 1, chapter 2, chapter 3. As these chapters are written, some content in previous chapters is refactored. I come back next week, and am preparing first draft for submission to my reviewer.

I correct typos on line 3:

-forgot ther bk lok
+forgot their bike lock

GitLens's new feature would allow me to right click this line, or use some other ui, to say "squash this line change into originating commit"

Mind you that the git blame on this line was originally Initial commit asdf

There could be a fancy little button in this ui:

[devinrhode2]

What I've learned recently, is that once you have a commit you will autosquash like so:

fixup! Initial commit asdf

It may be best practice to squash these commits asap, by running some form of GIT_SEQUENCE_EDITOR=: git rebase -c sequence.editor=: --autosquash -i <some sha...>

Typically I end up with many squash! Foo commits, and then rebase all at once, but doing too many things inside of one git rebase .../git-rebase-todo is a little risky. If you end up with some weird conflicts.. and want to abort the rebase... if you have a bunch of stuff you are doing in this rebase.... i.e. you spent more than 20 seconds editing git-rebase-todo file, you cannot abort the rebase without losing some amount of work.

Open questions:

• How to determine what sha to use in git rebase -i <sha>

• Need to prevent trying to squash into master

[devinrhode2]

Hey @d13 - this is quite heavy stuff. Lmk if you have questions.

I think the UI terminology should be "squash" but we actually always want to commit as fixup! Foo.

It's pretty easy to re-word past commits, which is a good final step I do before opening a PR.

Button icon

I have two ideas for the icon for this button. Of course, what we want to communicate, is that we are going to mutate a previous commit.

There could be a vertical line with 3 dots (representing commits) and the dot in the middle has an asterisk/bang thing next to it, maybe with a line pointing at it.

@GitKracken could also take the GH PR icon:

And turn the second line/arrow upside down

[devinrhode2]

Any squash probably shouldn't be over a range, because it becomes less clear what commit to squash into. If changes are over a range, then you need to create two commits to squash, and the rebase we need to complete becomes more complicated.

Button should probably only appear once you enable a setting, and is marked as "beta". (Mostly important to mark as beta because it throws the user into a rebase, and should they accidentally click it and have no idea how to resolve rebase conflicts... well that would really upset and confuse people)

[devinrhode2]

Worded differently: If you look at the git blame of each removed line in a git diff, you should only see one commit message, otherwise, it's indeterminate which commit git vanish should squash into.

[devinrhode2]

To "stage selected lines" it will probably be very helpful to view git output in vscode.

[devinrhode2]

It may be best to implement this outside of git lens, to make it easier for other editors/IDEs to adopt

[devinrhode2]

Making it easier for other editors/IDEs to adopt is not obviously a good idea.

From someone internal to gitlens, as a business, you want exclusive features.

As a general community member that cares about git history, I want more features across the entire ecosystem that helps other devs discover and care about git history more.

I think commit history is generally too uncared for. GitLens is the leading git blame plugin for vscode. Helping lift the whole industry will not threaten gitlens at all. GitLens is on top, if it can cause a tide that lifts all boats, it will be lifted that much more, the relative position of GitLens vs others I don't think will change.

[devinrhode2]

vscode runs a couple very interesting commands to partially stage a change ("Stage Selected Ranges"):

2022-11-20 23:21:30.483 [info] > git hash-object --stdin -w --path app/data/events.server.ts [8ms]
2022-11-20 23:21:30.493 [info] > git show -s --format=%H%n%aN%n%aE%n%at%n%ct%n%P%n%D%n%B -z HEAD [9ms]
2022-11-20 23:21:30.500 [info] > git ls-tree -l HEAD -- app/data/events.server.ts [6ms]
2022-11-20 23:21:30.507 [info] > git update-index  --cacheinfo 100644 9aedba4236d611ecb626e7241de744ccb73cbe2f
 app/data/events.server.ts [6ms]

[devinrhode2]

The one thing you can't automate: User's indication of what IS a typo. I guess vscode's "Stage selected ranges" must be complicated enough, that it's easier to focus on the rest of the flow.

0. Changes are staged
1. Run git vanish (command palette or terminal)
2. Look at staged changes, check git blame for the "removed" code (may not be easy to implement)
3. If the git blame for the removed lines points to more than one commit, fail.
4. Save the commit message for the removed lines in a variable targetCommitMessage
5. Save commit it as targetCommitHash
6. Commit staged changes as fixup! ${targetCommitMessage}
7. Determine if we can safely rebase right now:
8. A. Does origin/main contain targetCommitHash?
9. A. Yes: Stop here, rebasing commits on origin/main is universally agreed upon Bad Thing™️.
10. A. No: Does origin/$(current branch) contain targetCommitHash?
11. B. Yes: Stop here. Do not rebase. In future, consult configuration variable whether user is ok with force pushing PRs
12. B. No: It's safe to rebase
13. git stash --include-untracked
14. GIT_SEQUENCE_EDITOR=: git -c sequence.editor=: rebase -i ${targetCommitHash}^ --autosquash
15. git stash pop

[devinrhode2]

posted a $45 bounty on bountysource