"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea:
- when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed
- when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore file, and would then be automatically committed
- staging only some files and comitting is much easier than splitting a commit after the fact
> - staging only some files and comitting is much easier than splitting a commit after the fact
I see this project as a challenge to that conventional wisdom. This view is certainly the one I have embedded in my mind. But is it right? I end up fixing up the index and amending commits post facto quite often. I can also do it pre facto. But in a world where you can't fully avoid editing after the fact, mightn't it be better to have a single workflow for this kind of editing? That is, if you can't totally get rid of post facto commit editing (which I think is reality), can you actually get rid of pre facto editing, and be left with just one editing workflow? If so, maybe that's good!
I haven't used this yet, but this strikes me as a very plausible attack on a conventional wisdom that we take for granted but may not actually be doing us any favors.
I agree. We've gotten used to pick what should go into the commit after we've done the work.
There's a very serious and glaring error in doing that if you don't commit everything. When someone checks out your commit in a clean repo, his codebase is in a state that has never existed before, not even on your computer.
Some people (I think we've all done it at least once) split their work into multiple commits after a few days of hacking. Like "Adding data services for X", "UI features for X". This is a bad example, but you get the point.
Normally this doesn't cause a problem since all commits get pushed at the same time. But it can easily break things like git-bisect (which is just an amazing tool for finding astonishing bugs).
Obviously it depends on your workflow. If you're working on one feature at a time and only saving things out of your editor that you want to go to the project you cloned, it probably is.
That's not my world at all. I have logging and instrumentation all over the place when debugging. I have multiple features in flight. I have tweak patches that I maintain externally I don't want committed. I'm trying things for someone else, etc...
The index is the tool that allows you to manage all that without hating the process. That's why it was invented, in fact. Now, if you don't need it it seems needless, like someone is making you type "git add" for no reason. And jj seems to be aimed at that demographic, and that's fine.
But jj then needs to jump through some odd hoops to get back the "partial commit" workflow that is natural in git. Meh. Not a win for me personally.
There's also the problem of "patch hygiene", which flows like this tend to do pretty badly with. It's routine in some projects (Linux is the flagship here, obviously) to demand clean commit messages and perfect bisectability. Pull requests in that world routinely need to be split/squashed/reworked during review and when moving across branches. You need tooling to do that.
This, to me, reads like you're incredibly used to one workflow so any different one seems "odd". But I don't think it's odd, I think it's just different. If we'd all been doing it the jj way for a decade and a half, I think the "index" and "staging" would be the thing that seems odd to us.
So for instance, to work with the index with all your logging and instrumentation and debugging that you describe, you must be doing a lot of `git add -i` over the course of your workflow to partially stage things. Maybe you're also stashing the unstaged changes to make sure what you have in the index works on its own.
Well, I don't think that interactive add workflow actually seems any different fundamentally from copious use of `split`ing changes out of the working copy commit with jj. And I don't think stashing seems fundamentally different from rebasing the changes you split onto the branch you want to apply them to, leaving behind all the logging and instrumentation.
Yes, it seems like a lot of commit editing. But this is downstream of your workflow that requires some step to differentiate between what to check in and what not to, at a fine-grained level. You would have to split things up manually with jj, but you're already splitting things up manually with git, it's just a different workflow with a different command, but I'm not convinced it's any harder. Just different.
> Pull requests in that world routinely need to be split/squashed/reworked during review and when moving across branches. You need tooling to do that.
Yes, but jj seems to come with all that tooling! And I think its model of implementing all that on top of commits, rather than a combination of the concepts of unstaged+staged+stashed+commits, may actually be a better fundamental model.
But again, I still haven't used jj. My workflow is a lot like yours, at least oftentimes. I split stuff up ahead of time, I use the index a lot, I stash stuff a lot, I edit commits, I rebase interactively, I squash and split. But by my reading of jj, I think I can accomplish all that stuff, and just maybe in a better way.
I'm of the same opinion as you, here. I generally have 10+ "extra" files in my project directory (output files, notes, one-off scripts for certain things, etc). When I add files to a commit, I do it by filename, never "everything that's new/changed". I don't have a use case for "everything I've created/changed goes into the commit, always".
> switch to another branch, the files will still be in your working copy but not listed in your .gitignore file
This is a failing of git, imo. There should be a .local.gitignore to somesuch, that is "added to" .gitignore. It's VERY common for me to have files that I want ignore, but are specific to me; they don't belong in the project's .gitignore. I know there are ways to do this, but all of them are clunky. There should be a simple, out of the box way to do it.
I've used that file before but... it always felt sort of hacky. And every time I want to use it, I need to figure out where it is. It really feels like there should be a more obvious, straight forward way to do it. Admittedly, "user friendly" is not git's strong suit.
The .git directory seems like the obvious location for it; I agree that info/exclude isn't the most obvious path (I had to look up what the exact path was again for my previous comment), but all things considered that seems like a minor issue. I suppose you could symlink .git/ignore to .git/info/exclude or something in the git template.
These might be the clunky way your talking about but you can have “private” git ignored either in ‘.git/info/exclude’ in the repo or in the ‘core.excludesfile’ set in your git config. The later is quite nice because you could actually version control that elsewhere if you version control your system config.
i always have a large pile of temp files and such that should never be committed but it's never been a problem because i never use `git add .` i use `git add -u` which is "only add things that are already being tracked"
there's a newer flag for the same thing but my brain is hardcoded to the old "-u" option from "back in the day". It feels like a "simple, out of the box way to do it" to me.
I do the same, but in all the mess that git status outputs, I occasionally forget to git add some required source code - which leaves entire chains of commits in my repository in a broken, impossible to compile or run state. Worse, I don’t notice until I try to run the code on another computer - and find I’m missing data.
Having a “local gitignore” makes a lot more sense. I’d like to be more explicit about which local files should be ignored.
For point 1, they could easily diff the already tracked to the new ones right ?
Interesting nonetheless, I never liked staging in git but I never hit the case you mention so now I realize there's a need for a phase between a file system and a commit
> - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed
From only reading the README, my understanding is that you would just add the files to .gitignore and at the next auto commit they are removed again from the anonymous working copy commit. I agree it feels unintuitive that files are added and removed from the anonymous working copy commit, instead of not added in the first place. But since the anonymous working copy commit is largely invisible to you it shouldn’t make a difference.
Constantly having to split after the auto-commits feels like I have to keep fighting this automated commit system. It's a bit like the autosave feature of text editors, which some people find useful, but I never felt like it's needed.
A big downside I can see is that sensitive information might end up in the repo forever because I forgot to revert the auto commit.
I think you are misunderstanding the autocommit, but maybe I am.
I think you don't need to do this after every autocommit but only before the manual ones? Isn't that how amending commits in git works? The unamended commit is no longer around, right?
Also it seems to me that you can rewrite old commits in jj to get rid of accidentally committed information a lot more easily than you can remove it from when you accidentally commit it to git...
Meta comment: Bit frustrating to see so many downvotes in these threads when people are just trying to grok what the jj model means concretely for important workflows.
I always end up reading through my commit diffs while committing and then maybe like a third of the time I edit something about them. So for me this seems like it could be a natural acknowledgement of that; just make that editing after the fact be the primary / only workflow.
Haven't used this yet so no idea if it's actually great or terrible, but I like to see ingrained conventional wisdom challenged like this. We're always in some local maximum, so I think it's often interesting to be pushed in some new direction on the gradient.
> staging only some files and comitting is much easier than splitting a commit after the fact
Re this point, how is it any different? "Staging" the files is essentially the same as splitting the commit, anyways — it's just that the newly-split contents go into a "staging area" vs a commit. Do you mean that the tooling to accomplish this is not good?
I am working on a TUI tool for Git/jj to handle staging/splitting. Could you tell me more about what workflow would be problematic for you? For example, if you had to select lines that go in the first commit/staging area, does that work? Would it be better or worse if, for each line, you had to decide whether it would go into the first commit/staged vs second commit/unstaged area? Do you ever need to invert the first commit/staging area vs second commit/unstaged area?
I most definitely agree. To be honest I know I go against the current here, but so far there is nothing I really like from what I’ve seen in jj.
I should try it for real, see how it feels when using it to get a better sense of it.
- when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed
- when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore file, and would then be automatically committed
- staging only some files and comitting is much easier than splitting a commit after the fact