Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > I never use "fixup -C" (or -c), but I do use squash/fixup a lot. I > find that I would prefer it if Git used the most recent Author date > from the set of commits being combined, rather than preserving the > picked commit's Author date. Sometimes it takes quite a while for me > to get a piece of work sorted out, and I would rather have the Author > date in the end-result commit reflect the work's completion time than > its initiation time. Yeah, I can sympathize but with both positions, as I can see why most people would want "minor fixups and typofixes" to retain the original authorship date, and when concluding a "combining the whole steps together to reach this final single patch" development, they would want to record the completion date. The "take the one's authorship and apply only the effects and not metadata from the fixups" is a good match for the former. To support the latter, we can just ignore the timestamp of any commits that were involved in the end result, and record the time "rebase -i" was concluded instead, but the tool is not set up for doing so. > The current behaviour means that when scanning through commits with > tools like gitk (which shows just the Author date in its list of > commits) I'll often see what I feel are inaccurate or confusing dates > there,... Yup, exactly. Two opposing worldviews, which is not even per-user, but depends on why the "fixup/squash" was used, exists, but the tool was designed to support the "small fixup for work that was mostly done already" use case, so the other usecase is left for people to say "Yes, I know how to force my desired author date on commits, thanks." ;-) > Anyway, this is a minor itch for me that I've never felt the need to > scratch. I just thought I'd mention it since the topic is being > discussed. Yup, it is a very good observation. Giving it a good UI to support both worldviews would be a good exercise, as we all need both behaviour from time to time. Thanks.
