131–140 of 193 posts
A checkout is a working space after all, why can't it be (temporarily) dirty whilst you work?
I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…
You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…
You can't possibly see a use-case for long-lived branches? Say what you will of git, at least it exposes enough knobs that it can mostly accomodate every workflow (possibly with a heavy porcelain layer to hide the plumbing). JJ seems to swing too far in the other direction, great for a "live on head" mentality but less ideal for other setups.
(The fact that all edits are automatically recorded is my personal peeve with JJ. I'm ok with lack of staging area like in Mercurial, but mercurial doesn't try to automatically amend the commit with my pending changes. Sure I can pretend that "@" is my staging commit then squash as needed, but then I also need to remember that checking out a commit is "jj new" which feels like absurd mental gymnastics to me.)
Earlier quoted context omitted.
Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win. It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list. Actually I think that property is a much bigger obstacle to ad…
I use magit on a daily basis. And I do use tig occasionally (I don't like lazygit). Most of my magit workflows only requires a handful of keys (most are only two keys). If you've not tried Magit before, it's like vim for a git repo. tig is more barebones, but I could quickly configure it to be able to do most of the magit tricks I need. Git cli is tedious. But like all cli operations the goal is always to script your…
> Latter commits overwrite work that was done in earlier commits and the story breaks. > Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess. Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match
I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…
> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development. I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use gi…
sorry about that.
I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…
> why can't it be (temporarily) dirty whilst you work?
Because that would go completely against how jj changes work.
Just give me the PR, don't sweat the individual patches. But maybe also work on not committing your first idea as finished work.