jj-vcs
FR: Better handling of author dates (as opposed to committer dates)
This is an attempt to summarize a Discord discussion started by @chriskrycho.
Is your feature request related to a problem? Please describe.
Currently, jj sets the author date of a commit on jj new and does not change it when the commit is rewritten. This matches the letter git's behavior, but can be surprising.
For example, one might do jj new main today, then come three weeks later and start working on something. The author date for that commit will be three weeks before any work was done on it.
Describe alternatives you've considered
Workaround: @yuja pointed out the workaround: a user can run jj describe --reset-author --no-edit at any time to update the author date manually.
We have two proposed changes to this behavior:
-
@yuja suggested to record the author date when the commit first becomes non-"discardable". AFAIK, this means either non-empty, or with children, or with more than one parent.
This would match the spirit of the current behavior: the author date would better represent when the work on a change was started.
IMO, we could alternatively simply record the moment when the commit became non-empty, which might be a bit simpler and seems to make little difference.
-
@arxanas explained that
git-branchlessupdates the author date on every edit to the commit except rebasing of the commit.This seems very sensible to me: the author date would represent when the work on a commit was finished.
-
(Rejected?) In git, people tend to commit when a change first works (e.g. compiles). We could aim for a design that tries to make the author date represent that, but it seems difficult since this is very ambiguous from jj's perspective.
Describe the solution you'd like
We have to decide whether we prefer behavior 1, or 2, or an option to switch between them. Having an option is currently my preference.
Isn't 1 and 2 like literally the git author date and committer date? Except "committer date" does not change on rebases which is actually sensible
Storing both "start of the work" and "end of the work" seems beneficial to me
I believe Github changes the committer date when a PR gets merged. I'm guessing that's what the committer date is for: when was the change merged to the trunk?
It does it because it doesn't fast-forward :( And git changes it on rebases
Isn't 1 and 2 like literally the git author date and committer date? Except "committer date" does not change on rebases which is actually sensible
The first case seems like an author date, but I wouldn't call the second case a committer date. The committer date is updated on rebases (and the author date isn't), and it's a different thing than the "end of work" date.
Not sure about 2. If I come back one week later to fix a tiny typo, it would update the author date which isn't what I'd want.
Maybe git's commit notion could actually be useful here. commit could set the author date without creating a new commit (unlike new). So, if you end end your day with commit (instead of new), and a week later correct a tiny typo before moving on to new work with new, it wouldn't change the author date of the previous work.
#3008 suggested the option of setting the timestamp when the description becomes non-empty.
I think I'm leaning towards @yuja's suggestion of making either non-empty description or non-empty content fix the author date. His suggestion might also fix the author date whenever a commit becomes a merge commit; I'd prefer not doing that, but it doesn't really matter much.
I think that @yuja's suggestion of fixing the author date when a commit becomes non-discardable makes the most sense. This seems to be the most conservative option, since it doesn't throw away information about the author timestamp in any cases where it might be desirable to keep it.
Since discardable commits (i.e those with no description, one parent, and no changes) are already automatically discarded in some cases, it makes sense to me that the author timestamp could be lost in this case as well, while I might not expect it to be lost in other cases.
It might be nice to add a --reset-author flag to jj commit as well though (and maybe even a config option to set it by default) to make it possible to replicate Git's behavior easily.
Is there an intent to store two dates? Would it make sense to work like file dates (creation date, modified date)?
I think the date when it becomes non-empty could be useful as a quasi-creation date, but the date last modified makes sense for when the commit ID changes.
What is not taken into account here is specifying a date for folks like me that want to preserve history of stuff that isn't stored in a VCS (like a bunch of zip files). I think that would require an option like --commit-time.
