zlacker

That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started.

One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too.

At the very least, you can do your hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)

Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.

>>WorldM+(OP)
I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.

But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".

>>ptx+ow
My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.

Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)

>>WorldM+TH
Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main":

  $ git checkout feature-1
  $ git reset main
  $ git commit -a -C feature-1@{1}

This squashes all the changes and keeps the date and and message of the final commit on the branch.

Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.

It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".

>>ptx+XR
Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution.

Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.

>>WorldM+OY
git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.