Impressive project. I couldn't try it yet, because it requires a newer Rust source than exists in my distro, I'm not going to run random shell code as root and I haven't felt like it is worth to figure out how to bootstrap Rust.
I'm not sure if I would like it, because I care about reproducibility of commits so I want commit hashes to stay the same after a rebase. Does it support --committer-date-is-author-date ?
I'm also somewhat wary of additional layers on top of something.
We don't have --committer-date-is-author-date. I don't think we've had a single request for it until now.
That flag seems a bit weird, though. Wouldn't you want to keep whatever the committer date already was? Why would you want to reset it to the author date? Of course, after you have passed the flag once, any subsequent uses will have the same effect as keeping the committer date, so maybe that's why it's good enough. Maybe it works the way it does for historical reasons (I happened to see that it used to be passed to `git am` back when `git rebase` was based on that).
I do keep the committer date when I intentionally modify some single special commit, but when I just keep changing stuff I don't do it. In my opinion this date is only useful if the committer and author are also different, for example when you pull some random change suggested in some forum you can put author and date from the forum in and yourself and the time of commit in the committer.
> Wouldn't you want to keep whatever the committer date already was?
Note, that when you create a new commit, the beginning committer and author date are always equal. So the original one is always the author date.
I find this flag useful, because it means that I can keep rebaseing and still reproduce the same commit hashes. This is really useful for asserting that nothing changed when the commit hash is equal or that really something changed when it is different. Otherwise the commit hash changes for all commits you touched in the rebase and you constantly need to verify if there was a change or not.
I haven't used JJ, so does it work the same in JJ than in Git? Did you introduced it intentionally or does the committer fields only exists, because this is how it is in Git and you had no reason to change it.
Do you mean if jj has separate author and committer timestamps? Yes, we simply followed Git there. I didn't really question it. There has been some discussion about simplifying it to just one timestamp, however. You can probably find that discussion somewhere in our issue tracker if you're curious.
Or do you mean if jj updates the committer timestamp while leaving the author timestamp unchanged? Yes, that's also the same as what Git does.
I was curious so I searched the repo, the only mentions of this flag boil down to people being confused about there being two dates, and being okay with the current behavior.
The jj git backend happens to update only one of the two timestamps. There's not a lot of talk about the author date on the jj issue tracker.
I did not dig into the history of the code, so I can't say if it was an explicit design decision or just how it was implemented. Since there hasn't been a lot of demand to change anything here, I didn't see any active discussion about the choice.
I'm not sure if I would like it, because I care about reproducibility of commits so I want commit hashes to stay the same after a rebase. Does it support --committer-date-is-author-date ?
I'm also somewhat wary of additional layers on top of something.