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), but jj doesn't have the index and pushes you to commit all changes by default. I know there are workarounds like `jj split` but it ended up being more work than git, where I can just not add those changes in the first place.
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.
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.
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!
‘jj split`isn't a workaround but their version of `git add -p`. The intent is to make the Index unspecial to make it easier to work with and not to get rid of it.
If there are usability gaps between the jj's active commit and git's index, then they should be reported.
- Make a commit off main that includes these private changes
- Make a commit for the work you’re doing
- Create a merge commit on top of these two changes and work there
This works because the “DEBUG=true” change is already committed, but in a commit you never push to the remote. jj makes it easy to continually squash the work you want to keep from the merge commit into one where it belongs. And, there is a “private commits” setting you can use to prevent accidentally pushing that commit somewhere.
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.
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), but jj doesn't have the index and pushes you to commit all changes by default. I know there are workarounds like `jj split` but it ended up being more work than git, where I can just not add those changes in the first place.