undefined | Better HN

0 pointsptx3mo ago0 comments

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

0 comments

WorldMaker3mo ago

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

ptxOP3mo ago

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

WorldMaker3mo ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 pointsptx3mo ago0 comments

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.

0 comments

WorldMaker3mo ago

ptxOP3mo ago

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.

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

WorldMaker3mo ago

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.

1 more reply

j / k navigate · click thread line to collapse