more "how do you use this git feature" questions: do you ever use `git reset --soft`? What do you use it for?

(note: --soft is not the default)

@b0rk I don't think I've ever used that. Seems unlikely I ever will, either: the cognitive effort of remembering / looking up what it does, and then reasoning about what that would do in any given situation and whether or not it's what I want, seems to massively outweigh the ease of just finding another way to solve the problem.

(in this case git symbolic-ref HEAD refs/SOMETHING, I think)

@b0rk if I want to squash a dev branch down into a single commit, I often 'git reset --soft' to the branch start point, followed by 'git commit' without -a, then write a fresh commit message for the single commit containing the same changes as the whole previous branch.

Using reset --soft instead of commit -a means it still works if the branch added files (otherwise I'd have to 'git add' them by hand in between reset and commit).

Of course another approach would be to 'rebase -i' and squash everything down into a single commit that way, but that seems more heavyweight to me: more faff editing the rebase todo list file, and also, the commit ends up with some confusing random timestamp from one of the dev commits instead of being re-stamped with _now_.

@simontatham thanks, this is a great example

@b0rk I use --soft because I never remember what the default does and I know that I don't want to lose data, and --soft sounds like the opposite of --hard, which does lose data

@drmorr so real

@b0rk While rejigging the content of individual commits in a branch I have used it to avoid having to use interactive add to make per-hunk decisions after the reset. I think the cases in which I would have done so have almost all been replaced with `git commit --fixup` though once I found out that that existed. There's probably still some annoying branch rework situations where using `git reset --soft` after staging something is the most straightforward way to go about it, at least for my level of git knowledge.

@b0rk to redo a commit, most of the time, if I added something I shouldn't have: git reset --soft HEAD^, then git reset HEAD (or with -p), git add -p, then commit again. This way the other thing I didn't want committed stays in the working copy. It's mostly out of habit, I'm sure it's not the most efficient way to do it.

@Aissen @b0rk you can go a bit faster using default option --mixed
git reset HEAD^
or even
git reset -p HEAD^

you will find all your modifications in working area. --soft does the same but drop modifications in staging area

@ennael @b0rk Thanks, I'll try to remember it next time! For some reason I always learned with "soft" vs "hard", despite "mixed" being the default since forever.
One use case where soft wins: if you still have changes in the worktree, and don't want them mixed with those that you just committed — then `git reset -p HEAD` (or per-file) is mandatory.