I was expecting to be meh, but by halfway through the readme I was thinking "this actually sounds great!"
I was (and still am) meh. YMMV I guess.
Jujutsu: A Git-compatible DVCS that is both simple and powerful
51–60 of 269 posts
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#52my initial reaction, half OT:
Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine on your white-on-black terminal. Have you tried this on a white-on-firebrick terminal? Yellow-on-green? Or anything else than _your_ "normative" setup? Man ...
Also not sure the information presented is adequate. E.g. consider commit 76(2941318ee1) - jj makes it look like that was committed to that repository, while it was done to another. The git presentation looks more spot-on (for that particular commit, while the rest of the display is just a mess - ASCII art that does not add semantics, random colors); also where is 1e7d displayed in jj's output? Why is jj's order different? I remain unimpressed by both UIs.
" Create a file at ~/.jjconfig.toml" ... $XDG_CONFIG_HOME ?
When is that working copy committed? When I run jj? Why bother, when it's not working asynchronously and automatically? And if you commit working copies, do you sync under the hood with stuff the other folks you collaborate with? If not, why bother?
Oh nice, a command to fix "stale" workspaces.. how about you don't let workspaces go stale?
This may all seem to make sense to git-minded people, given the comments here. To me, neither jj nor git make sense (as fossil-minded person who has to work with git), so shrug enjoy....
..but please fix that ASCII Art and Color Stuff, thank you very much.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#53This looks promising. One question I had after reading about its git compatibility is that they seem mostly focused on the use case where a Jujutsu user accesses a git repository (hosted by e.g. GitHub) with jj. But does it support the converse way of working, i.e. accessing a native Jujutsu repository with git? I ask this because most developers are already quite familiar with the git CLI so in production use one wo…
I would assume there would always be the expectation that you either use Jujitsu as a frontend to a git repo, or have a complete Jujitsu based remotes. If you're going to work on and contribute to a project that is already using Jujitsu, it is reasonable to expect that you'd adapt your workflow to the project itself and not the other way around.
Thanks, it makes sense. I don't understand why this was downvoted.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#54Earlier quoted context omitted.
Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…
Isn’t this just .gitignore? I feel like I’m missing something.
That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#55"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…
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.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#56Earlier quoted context omitted.
Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…
Isn’t this just .gitignore? I feel like I’m missing something.
[deleted]
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#57Earlier quoted context omitted.
Isn’t this just .gitignore? I feel like I’m missing something.
That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
Why wouldn't it work? You gitignore that file, and your modification is ignored, even if it is committed? Or will git delete that file from everyone?
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#58my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine…
I don’t mind color, but pushing beyond the 16 colors is often a stretch without a very specific use case & bound to lead to a lack of legibility for some unless both foreground & background are defined—which has a tendency to look just as bad in a terminal. Similar issues happen with CSS when folks define color but not background color.
But the one CLI trend that annoys me is using Emoji terminal. I often find their colors and shapes to be too distracting, commanding too much of the visual hierarchy of output. They also have a tendency to kind of fall apart when some characters or combinations of characters are missing or they no longer line up with the monospace output. A big part of CLI output is being able to scroll through the logged output, but the Emoji actually make visual scanning more difficult.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#59Jujutsu started as author's personal project and now author's full-time project at Google. It's presented at Git Merge 2022: Jujutsu: A Git-Compatible VCS - Git Merge 2022: Video: https://youtu.be/bx_LGilOuE4 Slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX...
> started as author's personal project and now author's full-time project at Google That's got to feel good!
Absolutely, good for the author. However, given the numerous examples of Google pulling the plug on nonessential projects, I don’t see this as strictly positive development.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#60Earlier quoted context omitted.
That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
Why wouldn't it work? You gitignore that file, and your modification is ignored, even if it is committed? Or will git delete that file from everyone?
gitignores are usually committed (they're treated like a normal file), so yes, in this context that would delete it from everyone.
There's .git/info/exclude, but that has some kinda large surprises if it excludes a tracked file and I don't recommend anyone use it unless they know what to look for and can always remember what they've excluded.