Community
Participate
Working Groups
Amending a change should only update the committer info, not the author info.
Some more information: - Happens when amending a commit from the Git Staging view - Still present in 2.0
I failed to reproduce this problem on Mac using current master version (2.2.0-SNAPSHOT). I tried amending in Staging View and using Commit Dialog started from Repositories View and Team menu. None touched the author of the amended commit. Can you provide steps to reproduce ?
Now I got it: amend is updating the author date which is wrong. This happens both when amending from commit dialog or from staging view.
JGit change required for this: https://git.eclipse.org/r/8077 EGit change then only needs to *not* set author in CommitOperation in case of amend. Maybe we also need to detect if the user changed the author, which we would interpret as meaning "reset author". But I'm not sure about this. What do you think, Matthias?
> Maybe we also need to detect if the user changed the author, which we would > interpret as meaning "reset author". But I'm not sure about this. What do > you think, Matthias? native git has a couple of options controlling this [1]: --reset-author resets the author to the committer and renews the author timestamp --author=<author> allows to explicitly override the author --date=<date> allows to explicitly override the author date At the moment EGit only supports overriding the author but not the date, this would require enhancement of the UI. --reset-author would then probably become a new button, --author could provide value help using authors already known from the repository's history and --date would require displaying the author date and a way to edit this (a time picker control would be handy). [1] http://www.kernel.org/pub/software/scm/git/docs/git-commit.html
I've mostly used the ability to change author name when the email address is wrong. In those cases I'd expect the datetime part to remain unchanged. The author/committer fields should probably be read-only and perhaps less prominent until you press a button that either expands the dialog or open a new dialog.
Let's try an example mockup, to have a more concrete discussion: Author: [Au Thor <mail@example.org> ] ☐ Reset date It would only be like that on amend. Changing the author text field would change the author, but not the date. Ticking the "Reset date" checkbox besides the text field would cause the author date to become the same as the committer date on commit. Do we really want to support the user to supply an arbitrary datetime? I don't know if that's really needed (I've never done it myself using C Git, except for migrations where I've used GIT_AUTHOR_DATE).
(In reply to comment #7) > Do we really want to support the user to supply an arbitrary datetime? No. It's a behavior that should not be encouraged. It's easy enough to fake for the very very rare cases a user actually needs it. (copy text, reset --soft, commit). > I don't know if that's really needed (I've never done it myself using C Git, > except for migrations where I've used GIT_AUTHOR_DATE).
Ok, pushed a change that keeps the original date and combines it with the author the user entered (which is the original one if the user didn't change it): https://git.eclipse.org/r/8192
merged https://git.eclipse.org/r/8192 as http://git.eclipse.org/c/jgit/jgit.git/commit/?id=08d81bf1673f4aeb816ce6f9278ffa028d4b5ac0 This fixes the problem reported here.
Thanks for merging. So, can we resolve this bug?
yes, we can, I just wasn't sure if you want to also support the checkbox you proposed in comment 7
Ah, ok. No, Robin's argument that it can also be done using a soft reset in case anyone wants to do this convinced me that it's not worth it.
