Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switch to Jujutsu Already: A Tutorial

stavros.io

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#151

Post by oxceedo »

martinvonz wrote: post #143
oxceedo wrote: post #130

Earlier quoted context omitted.

Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git. Which every articles I read on JJ failed to do correctly. My point is not to avoid using other tools to do your job. My point is that if you don't understand something, using a layer on top of it won't help you at all understand things in the long run. I…

FWIW, Drew DeVault wrote such an article but he later took it down (in protest of the Google CLA, I think). You can probably still find it somewhere. > Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git. I'm not the person you asked but I can try to explain (I started the jj project, fwiw). Some things `jj…

Hi Martin,

We had somewhat the same exchange on reddit a few weeks ago under a similar article if you remember :)

Once again, I really appreciate the time you are taking to explain those things!

Everytime you chip in, it's always spot on and crystal clear. This is the kind of informations those people should put in their articles.

Have a good day and keep up the good work!

Re: Switch to Jujutsu Already: A Tutorial

#152

Post by martinvonz »

1718627440 wrote: post #150
martinvonz wrote: post #149

Earlier quoted context omitted.

Ah, 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.

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…

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

Re: Switch to Jujutsu Already: A Tutorial

#153

Post by steveklabnik »

martinvonz wrote: post #152
1718627440 wrote: post #150

Earlier quoted context omitted.

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…

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 enou…

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.

Re: Switch to Jujutsu Already: A Tutorial

#154

Post by 1718627440 »

martinvonz wrote: post #152
1718627440 wrote: post #150

Earlier quoted context omitted.

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…

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 enou…

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.

Re: Switch to Jujutsu Already: A Tutorial

#155

Post by 1718627440 »

martinvonz wrote: post #152
1718627440 wrote: post #150

Earlier quoted context omitted.

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…

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 enou…

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.

Re: Switch to Jujutsu Already: A Tutorial

#156

Post by 1718627440 »

steveklabnik wrote: post #153
martinvonz wrote: post #152

Earlier quoted context omitted.

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 enou…

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.

Are you talking about Git or JJ?

Re: Switch to Jujutsu Already: A Tutorial

#157

Post by steveklabnik »

1718627440 wrote: post #156
steveklabnik wrote: post #153

Earlier quoted context omitted.

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.

Are you talking about Git or JJ?

I'm talking about jj.

Re: Switch to Jujutsu Already: A Tutorial

#159

Post by martinvonz »

1718627440 wrote: post #155
martinvonz wrote: post #152

Earlier quoted context omitted.

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 enou…

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.

Re: Switch to Jujutsu Already: A Tutorial

#160

Post by 1718627440 »

martinvonz wrote: post #159
1718627440 wrote: post #155

Earlier quoted context omitted.

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…

Thanks, the first was what I asked, but the latter was also nice to know.
Post reply on HN