For 17 I would instead almost always recommend making a new commit on HEAD and then using rebase with the fixup verb to reorder and join the commits. This is for the simple reasons that it:
creates a reflog entry
lines up with the rebase workflow
has some safeguards for timeline-incompatible changes (i.e. file existed at the time but had entirely different contents)
Similarly, I would avoid the restore command, instead using checkout and reset where appropriate.
Really, a reflog entry appears for each state at begin and end of each rebase, so they at least can be recovered.
has some safeguards for timeline-incompatible changes (i.e. file existed at the time but had entirely different contents)
That's why, an opposite, a file could be easily edited with the edited commit but not later.
Similarly, I would avoid the restore command, instead using checkout and reset where appropriate.
restore is a new command which just unifies multiple use cases for former checkout, branch and reset under a convenient common name. It hasn't added new functionality. To use restore or older variants is still just a matter of taste.
Just as a side note, if you need to reorder and then fixup, you can instead just squash and then rewrite the commit message appropriately. Squash itself puts you in a commit "screen" anyways, so you can easily use the commit message you want.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For 17 I would instead almost always recommend making a new commit on HEAD and then using rebase with the fixup verb to reorder and join the commits. This is for the simple reasons that it:
Similarly, I would avoid the restore command, instead using checkout and reset where appropriate.
Really, a reflog entry appears for each state at begin and end of each rebase, so they at least can be recovered.
That's why, an opposite, a file could be easily edited with the edited commit but not later.
restoreis a new command which just unifies multiple use cases for formercheckout,branchandresetunder a convenient common name. It hasn't added new functionality. To userestoreor older variants is still just a matter of taste.Well I think it is a bit of work having to reorder the commits so as to use the fixup action verb.
Then regarding the restore command, it was built for the restoring purpose in mind unlike the checkout command which is like a know it all command
Just as a side note, if you need to reorder and then fixup, you can instead just squash and then rewrite the commit message appropriately. Squash itself puts you in a commit "screen" anyways, so you can easily use the commit message you want.