@drewdevault Not trying to start a flame war or anything, but the mercurial rebase seems so much easier to me, but that may be because of all my previous experience with centralized version systems.
@drewdevault git rebase is so underrated. For packaging I sometimes notice a small thing to fix -> create commit, git rebase and squash it with the corresponding one.
- replies
- 0
- announces
- 0
- likes
- 0
@drewdevault None of the above. Know how to use it, do so when appropriate.
@khm prescient as always
@drewdevault
Generally how I split a commit some commits ahead with git:
```
git rebase -i origin/main
_rename "pick" to "edit" at the target commit_
git reset --soft HEAD^
git reset
git add -p
_choose what you want to split_
git commit
_type commit msg 1_
git add .
git commit
_re-type commit msg 2_
git rebase --continue
```
=> wizardy... but that is really what you have to do with git
Generally how I split a commit some commits ahead with jj:
```
jj split -r <commit>
_choose what you want to split_
_re-type commit msg 1 (already filled)_
_type commit msg 2_
```
Generally how I split a commit some commits ahead with git:
```
git rebase -i origin/main
_rename "pick" to "edit" at the target commit_
git reset --soft HEAD^
git reset
git add -p
_choose what you want to split_
git commit
_type commit msg 1_
git add .
git commit
_re-type commit msg 2_
git rebase --continue
```
=> wizardy... but that is really what you have to do with git
Generally how I split a commit some commits ahead with jj:
```
jj split -r <commit>
_choose what you want to split_
_re-type commit msg 1 (already filled)_
_type commit msg 2_
```
@drewdevault I love using `git commit --fixup=` together with `git rebase --autosquash` since I learned about it.
I just wish GitHub/GitLab had support for autosquash when (rebase-)merging PRs.
@stacyharper
why two resets? (though the jj thing just gave me an idea to make a git-split script for the former)
why two resets? (though the jj thing just gave me an idea to make a git-split script for the former)
@navi `git reset --soft HEAD^` reset the commit head, not the working dir. Meaning you got changes still in the index, but the commit is gone. The second `git reset` to unstage the index. Maybe there is a more direct way ¯\_(ツ)_/¯
@stacyharper testing here, just `git reset HEAD^` seems to suffice