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

I'm daily driving Jujutsu, and maybe you should too

drewdevault.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: I'm daily driving Jujutsu, and maybe you should too

#31

Post by wbkang »

OskarS wrote: post #16
do_not_redeem wrote: post #13

The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), bu…

The ”staging” concept in git is something that I know really bugs a lot of people, especially beginners with git. Like ”I just want to commit, why is there this extra step?”, but I totally agree with you. Maybe it’s Stockholm Syndrome, but I really like that there’s an extra “look through your changes” procedure before committing, exactly for reasons like this.

It sounds like Stockholm to me ;) I don't think you _need_ the index to make partial commit work. I've used Mercurial first so I know "hg commit -i" exists.

Even if the staging concept is clear to someone, git cli terminology _is_ objectively very confusing and there are many articles written about it already (e.g., do I "add" to index? Is the index also referred as cached/Staged? Mixing different verbs and nouns everywhere). Are they all the same?)

I just wrote this to say it is not a necessary part of making a tool as powerful as git - Mercurial shows an example of a similar tool with a less confusing CLI.

Of course, git won so I just live with it. I enjoy teaching git new devs because once you explain the confusing terminology up front, they understand it faster.

Re: I'm daily driving Jujutsu, and maybe you should too

#32

Post by MrJohz »

do_not_redeem wrote: post #13

The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), bu…

I second the comment made by the sibling poster that you should generally see the head commit in jj as your staging area, but treated like a real commit instead of the pseudo-commit that it is in git.

That said, I've ran into the same issues in Git with these sorts of perma-dev changes, and in every situation, I was happiest when I just moved that change into a config file or .env file that I could then gitignore. Even when I was careful, there were still accidents where I committed something I didn't mean to, or ended up losing my local configuration and needed to redo things. Whereas with an ignored config file, you can be certain that the changes in there will never get committed. Well, unless you switch to a version from before the config file was added to gitignore, but this is why adding this configuration as soon as possible is so useful!

Re: I'm daily driving Jujutsu, and maybe you should too

#34

Post by kardianos »

deltaburnt wrote: post #28

The biggest feature gap I noticed was the lack of hooks. Using Gerrit requires a commit hook to insert the change ID. jj's docs mention this specific use case, but their workaround (using a custom commit msg editor command that wraps vim) feels hacky. Didn't bother looking further into it, not sure if this is a technical or ideological choice. Otherwise it reminded me about all the best parts of mercurial and git bra…

I also use gerrit, and one repo uses large files. Looking at the roadmap ( https://martinvonz.github.io/jj/latest/roadmap/ ) they are aware of both these things, but aren't done.

That being said, it looks like jj pragmatically addresses many of the issues with git.

Re: I'm daily driving Jujutsu, and maybe you should too

#35

Post by MrJohz »

rererereferred wrote: post #29
do_not_redeem wrote: post #13

The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), bu…

I do that as well. Right now I keep a pre-commit script that prevents me from committing those by mistake but I would really like for git to have some kind of .gitignore for patterns in a line. Maybe a weekend project to tackle one day.

Out of interest, why not move those lines into a separate configuration file and put the whole thing in gitignore? With environment variables this is usually pretty trivial.

Re: I'm daily driving Jujutsu, and maybe you should too

#36

Post by porridgeraisin »

I use the "stackless" stacked PR git workflow mentioned in the article. I also add a bit of niceness to it so I don't have to remember the commit IDs:

So git has a notes feature, this is a simple note attached to a commit. It's intended for adding extra context to commit messages without changing the commit hash. Then there is a gitconfig for having these notes _follow_ the commit through rewrites such as rebases, squashes, amends, etc,.

All this together means that you write the branch name that you want in the note, use the git notes commands to two-way map this to the commit. Wrap this all in a git alias and it's golden.

Re: I'm daily driving Jujutsu, and maybe you should too

#37

Post by martinvonz »

arkh wrote: post #9
null_investor wrote: post #6

I don't like it, I was expecting something new that replaces Git with a new idea about versioning. I can already work extremely fast in Git by using bash aliases and my workflow. This might be useful for those starting out.

> replaces Git with a new idea about versioning With the advent of LSP I feel like we're almost to a point where you could version structures and not code. Like being able to follow how some class / method got cut in multiple pieces during a refactoring round. Or maybe we need something more than plaintext to store code and the meta data around it before we can get to this point. I'm sure it has been already done mul…

You might find Unison interesting: https://www.unison-lang.org/docs/the-big-idea/

Re: I'm daily driving Jujutsu, and maybe you should too

#38

Post by pragma_x »

OskarS wrote: post #16
do_not_redeem wrote: post #13

The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), bu…

The ”staging” concept in git is something that I know really bugs a lot of people, especially beginners with git. Like ”I just want to commit, why is there this extra step?”, but I totally agree with you. Maybe it’s Stockholm Syndrome, but I really like that there’s an extra “look through your changes” procedure before committing, exactly for reasons like this.

> an extra “look through your changes” procedure

A lot of the time, when I do my best to blow past that step, I forget to add new files to the commit. I wind up with all this needless CI activity on push, publish a whole PR for others to see, and generally waste everyone's time. Git's workflow really is based on this whole corpus of shared VCS experience, and it shows.

The downside to all that is that Git is _everyone's_ workflow, and nobody's at the same time. It's a compromise, and the tool does expose everyone to all the small little steps that are a part of that bigger experience. That said, if there was a more succinct workflow that was smart enough to flag simple mistakes for me, I would welcome it.

Re: I'm daily driving Jujutsu, and maybe you should too

#40

Post by rererereferred »

MrJohz wrote: post #35
rererereferred wrote: post #29

Earlier quoted context omitted.

I do that as well. Right now I keep a pre-commit script that prevents me from committing those by mistake but I would really like for git to have some kind of .gitignore for patterns in a line. Maybe a weekend project to tackle one day.

Out of interest, why not move those lines into a separate configuration file and put the whole thing in gitignore? With environment variables this is usually pretty trivial.

Oh, I don't mean just enabling debug options but more like print debugging stuff.
Post reply on HN