pleroma.debian.social

git rebase

@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.

anyone who uses more than clone, checkout, commit, pull or push is part of the problem

@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_
```

@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)

@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