4 ms·
> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead? > The project started as an experiment with the idea of represen
by 1718627440 1y ago
> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead?
> The project started as an experiment with the idea of representing the working
copy by a regular commit. I (@martinvonz) considered how this feature would
impact the Git CLI if it were added to Git. My conclusion was that it would
effectively result in deprecating most existing Git commands and flags in favor
of new commands and flags, especially considering I wanted to also support
revsets. This seemed unlikely to be accepted by the Git project.
This doesn't support what you said?
> I don't think it would have been doable.
This only states that JJ has a different user model, with a different structure of commands and flags, not that it magically does things that are impossible in Git.
Btw., you could just link to the commit diff instead. And are you quoting yourself?
-----------
Oops, now I see the issue, you misunderstood me.
> but they just never bothered.
"They" referred to the authors of blog posts. I didn't want to claim, that it would be a good fit to merge the JJ user model with the Git user model. My claim was that the approaches people learn with the JJ user model aren't exactly difficult in the Git model either. People just reconsider their approaches when they touch a new tool with the experience they gained since starting to use Git. They just never considered that approaches with a tool they have been using for years.
- martinvonz 1y agoAh, I see what you're saying now. Thanks for explaining. I agree with you in principle. My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.
- 1718627440 1y agoImpressive 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.
- martinvonz 1y agoWe 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 agoI 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 agoAre you talking about Git or JJ?
- steveklabnik 1y agoI'm talking about jj.
- 1718627440 1y agoDid it sound like an explicit decision from jj or just being inherited from Git?
- steveklabnik 1y agoThe 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