On 24/10/2023 11:18, Oswald Buddenhagen wrote:
On Tue, Oct 24, 2023 at 10:26:29AM +0100, Phillip Wood wrote:
On 20/03/2022 08:05, Johannes Sixt wrote:
Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:
during interactive rebasing, i sometimes find it necessary to move a
hunk from one commit to a later one in the branch. now, if that hunk
cannot be re-ordered with the later commit due to conflicting with it,
it becomes necessary to squash the later commit onto a temporary commit
created from the extracted hunk, not the other way around (or using a
stash). unfortunately, this causes the author date of the later commit
to be reset, which can rather seriously falsify the date if the branch
is long-lived.
You want `fixup -C` in the todo-list. See the hints near the end of the
todo-list.
Unfortunately "fixup -C" only copies the commit message not the
authorship
(that's usually a good thing
why? what would that be useful for?
> it seems rather counter-intuitive.
In the same way that you do not want to change the author date when
using a fixup to move a small hunk from one commit to another most users
do not want to update the author information when they make a small
change to a commit message using "fixup -C"
it's also inconsistent with commit -c/-C's behavior, which seems like a
red flag to me.
That could mean the option is mis-named instead rather than the behavior
being wrong.
but not it means it wont work for what Oswald wants to do).
Maybe we should add another flag for fixup/squash commands to take the
authorship from that commit.
that's a possibility. but given the above, it might be better to simply
change the behavior of -c/-C to keep the UI lean and consistent with
commit's behavior.
"fixup -c/-C" were conceived as a way to reword a commit message at the
same time as optionally fixing up the commit's content. I think changing
the behavior to automatically update the authorship would surprise
people and as I said above most of the time one does not want that behavior.
Best Wishes
Phillip
