111–120 of 128 posts
Earlier quoted context omitted.
You're still missing the why and more specifically how. It's not enough to tell a story full of vague assertions, you have lead the reader through what amounts to a tutorial.
There are plenty of specific, pointed assertions being made. Maybe they don’t resonate with you. Again, that’s fine. You are not owed an explanation that meets your personal set of criteria.
Earlier quoted context omitted.
I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see…
Can confirm this. I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.
Earlier quoted context omitted.
Third time? SVN was a big improvement over CVS. CVS was full of UX blunders, kind of like Git compared to something with good UX.
Did the Subversion creators have a lot of prior experience working on CVS?
> In February 2000, they contacted Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999), and asked if he'd like to work on this new project. Coincidentally, at the time Karl was already discussing a design for a new version control system with his friend Jim Blandy. In 1995, the two had started Cyclic Software, a company providing CVS support contracts, and although they later sold the business, they still used CVS every day at their jobs
You may recognize Jim as one of the authors of Programming Rust.
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…
IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".
Earlier quoted context omitted.
Did the Subversion creators have a lot of prior experience working on CVS?
Yes: https://svnbook.red-bean.com/en/1.7/svn.intro.whatis.html#sv... > In February 2000, they contacted Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999), and asked if he'd like to work on this new project. Coincidentally, at the time Karl was already discussing a design for a new version control system with his friend Jim Blandy. In 1995, the two had started Cyclic Software, a company provi…
Earlier quoted context omitted.
Hah. I didn't even realize you could _not_ name them. I just do: jj b c zellyn/appname-update-plugh-tests jj git push
jj git push -c will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.
EDIT: Docs here: https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix...
I have used jj for about one month on a project with a colocated git repo. So far, I enjoy it a lot. Previously I would have a bunch of 'wip', 'fix typo' commits, but my commit history got much cleaner with jj. It's very easy to jump to old changes and apply fixes right in the place they belong. All changes + tests are now committed as one unit. I would never bother to do it in git, but because it's so easy now, I do…
In my opinion the traditional git workflow is flawed, but wanting the commit history to be cleaner is fundamentally the wrong approach.
There are basically two main reasons to look at a chronological list of commits: reading it as a changelog, and bisecting to find a bug. As a changelog, you want the history to be clean, organized, and concise. Rebase-based workflows are good for this and it's what Jujutsu excels at. For bug hunting, every commit should build successfully and be a faithful representation of what was on the developer's machine at the time they made the commit. Merge-based workflows are good for this.
But these are conflicting requirements. If you optimize for readability, you lose reproducibility and vice-versa. To achieve both you need to stop trying to use commit histories as a changelog. It doesn't matter how messy it is if you never look at it.
But then you need some kind of history to look at. Personally I haven't seen any open source tools that solve this well enough to be a viable alternative. Stacked diffs are probably the closest.
I like Jujutsu but it feels more like an incremental improvement over Git as opposed to something that actually addresses the deeper issues of VCS.
Earlier quoted context omitted.
Third time? SVN was a big improvement over CVS. CVS was full of UX blunders, kind of like Git compared to something with good UX.
...and don't ask about the first version control tool I had the "pleasure" of using, M$'s Visual SourceSafe o_O
Earlier quoted context omitted.
`jj --config ui.color=never` Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises. Think about literally other technology post on this site. Nothing is universally loved.
Just said I don't want color==never. That's the problem, no one can cogently/concisely explain why. I don't love git but have sanded its rough edges already. Gitlab did the rest. I recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/ Doesn't have to be this long but note his writing style.
Based in part on the parallels of their respective titles, this post may be similar enough in style to potentially be informative about Jujutsu: https://v5.chriskrycho.com/essays/jj-init/#outline
I've linked directly to the Outline/TOC in order to provide a more immediate overview of the post's content but there's also a chunk of more "philosophical" introductory text before the Outline: https://v5.chriskrycho.com/essays/jj-init/
The introductory text has parallels with the "Subversion Re-education" section of Spolsky's document--including the apparently mandatory (though stated in more reserved terms) reference to the effect the incumbent VCS has on one's brain: "just how weirdly Git has wired your brain". :D
As to the "why", to quote from the intro:
----
Jujutsu is two things:
(1) It is a new front-end to Git. This is by far the less interesting of the two things, but in practice it is a substantial part of the experience of using the tool today. [...]
(2) It is a new design for distributed version control. This is by far the more interesting part. In particular, [...] a few key concepts [...]:
(2.1) Changes are distinct from revisions: [...]
(2.2) Conflicts are first-class items: [...]
(2.3) The user interface is not only reasonable but actually really good: an idea borrowed from... literally every VCS other than Git.
----
As someone who reluctantly stopped using Mercurial primarily due to the friction around using hg-git to interoperate with GitHub, I think Jujutsu's approach of focusing initially on developing atop the "git backend" for interoperability is both wise & IMO pretty much a requirement for any project hoping to become the next industry standard VCS that everyone complains about. :D
Having said that, while I'm positive about the project's approach & potential, have read multiple Jujutsu articles, docs & even downloaded a binary, I'm yet to actually use it.
By now the main reason I've been less inclined to prioritize trying JuJutsu out is the project's mandatory CLA requirement for contributions: CLAs are anti-developer & an abuse of the power differential between individual developers and corporate entities.
I'm sure they'll realise the error of their ways eventually. :)
And, yes, perhaps I'm tilting at windmills--but that's probably also why I stuck with Mercurial for so long and why I'm even considering/hold out hope for a git replacement... :D