4 ms·

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 wan

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).

steveklabnik 1y ago
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.
- 1718627440 1y ago
  Are you talking about Git or JJ?
  - steveklabnik 1y ago
    I'm talking about jj.
    - 1718627440 1y ago
      Did it sound like an explicit decision from jj or just being inherited from Git?
      - steveklabnik 1y ago
        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. EDIT: oh I see martin has said 'we just followed git' here: https://news.ycombinator.com/item?id=45599741 https://news.ycombinator.com/item?id=45599741
1718627440 1y ago
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.
- martinvonz 1y ago
  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.
  - 1718627440 1y ago
    Thanks, the first was what I asked, but the latter was also nice to know.
1718627440 1y ago
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.

steveklabnik 1y ago

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.

1718627440 1y ago
Are you talking about Git or JJ?
- steveklabnik 1y ago
  I'm talking about jj.
  - 1718627440 1y ago
    Did it sound like an explicit decision from jj or just being inherited from Git?
    - steveklabnik 1y ago
      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. EDIT: oh I see martin has said 'we just followed git' here: https://news.ycombinator.com/item?id=45599741 https://news.ycombinator.com/item?id=45599741

1718627440 1y ago

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.

martinvonz 1y ago
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.
- 1718627440 1y ago
  Thanks, the first was what I asked, but the latter was also nice to know.

1718627440 1y ago

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.