Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu: A Git-compatible DVCS that is both simple and powerful

github.com

Post reply on HN
Print view View original

181–190 of 269 posts

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#181

Post by dingnuts »

jayd16 wrote: post #156
KolmogorovComp wrote: post #38

Earlier 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…

Git should really steal the only thing I like about perforce, many uncommited change lists. It should be an easy workflow change to add 'named stages' along side the default stage. That way you can just leave changes in a different stage, tracked but uncommitted.

Unless I have misunderstood your feature request, that feature exists, and it's called "worktrees"

Worktrees allow you to have multiple branches open potentially with dirty state on any or all of them

https://git-scm.com/docs/git-worktree

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#182

Post by yCombLinks »

derealized wrote: post #104

It's nice to have alternatives and maybe I have Stockholm Syndrome about this topic, but isn't git's complexity inherent to the area?

Git fails to make the common paths simple. There's no need for most of the complexity to be so prevalent in day to day use

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#183

Post by dingnuts »

guilherme-puida wrote: post #112
Certhas wrote: post #97

Earlier quoted context omitted.

So in your workflow you never "git commit -a"? So you have to always manually mark what you stage. Which is probably more work than always manually removing the changes you don't want to commit. The ability to rewrite older commits easily in jj also looks like it would help with this usecase if you get it wrong once. Concretely I think you would do is: Instead of staging part of your changes and then committing as in…

> So in your workflow you never "git commit -a"? I like seeing what I'm about to commit, so I always do `git commit -p` or `git add -i`. Most people where I work do the same, so I don't think this workflow is uncommon.

if I don't do this (actually I use magit to select each hunk to stage, but that's just add -p with a fancy interface) then I'll accidentally commit testing log lines and that sort of experimental code

I never, ever commit -a. That flag horrifies me. I want to choose, specifically, each line of code that I am going to publish.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#184

Post by [deleted] »

Joker_vD wrote: post #157
BaseballPhysics wrote: post #125

Earlier quoted context omitted.

Because I have always and will always prefer to interact with my VCS on the command-line. The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), across editors (I don't have to learn and re-learn how each editor interacts with the VCS), and I can use all my familiar tools to work with it. As for those workflow examples, I can just as eas…

I, on the other hand, have always and will always prefer to interact with my VCS via the editor-integrated plugin with GUI. The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), and I can use all my familiar plugins from the extension marketplace to work with it. Yes, when I switch my favourite editor I'll have to relearn most of the pa…

[deleted]

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#185

Post by BaseballPhysics »

calvinmorrison wrote: post #132
Double_a_92 wrote: post #131

Earlier quoted context omitted.

You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.

If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore. The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree. Also to explain i…

> from an UI

Just a really quick aside...

Do you... say "oooey" instead of "you eye" when reading "UI"?

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#186

Post by BaseballPhysics »

Joker_vD wrote: post #157
BaseballPhysics wrote: post #125

Earlier quoted context omitted.

Because I have always and will always prefer to interact with my VCS on the command-line. The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), across editors (I don't have to learn and re-learn how each editor interacts with the VCS), and I can use all my familiar tools to work with it. As for those workflow examples, I can just as eas…

I, on the other hand, have always and will always prefer to interact with my VCS via the editor-integrated plugin with GUI. The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), and I can use all my familiar plugins from the extension marketplace to work with it. Yes, when I switch my favourite editor I'll have to relearn most of the pa…

> No thanks, I'd stick with GUI which shows me what exactly I am going to modify and how. Would that be so hard to believe?

It's not. That's, you know, why I specifically said "I don't claim my way is any better than your way."

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#188

Post by sedatk »

me-vs-cat wrote: post #47
vesinisa wrote: post #17

This 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…

The README's footnote: At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend.

That footnote has a “won’t be big and professional like GNU” feeling to it.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#189

Post by nkjnlknlk »

9dev wrote: post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

How well does your integration handle stacked PRs (if at all)? I find that the majority of my interaction with git is super basic that I get no value add replacing `git add -p` (esp. since I'm always in my terminal with Vim/tmux).

What _is_ annoying and something I could probably automate if I thought about it for more than a few minutes is when:

a) I have stacked PRs for isolation/workflow purposes in the form of: A b) we use squash and merge

c) now when A gets merged I need to fix B and C because while the change set is the same the history is not (because of the squash & merge)

d) when B gets merged I have to fix C for the same reasons

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#190

Post by happymellon »

theLiminator wrote: post #170
motoboi wrote: post #160

Earlier quoted context omitted.

Why do you want such big files in a git repo?

How about why not? The only reason it's not done is because git doesn't support it.

This isn't true at all. We were storing binary files separately via Maven for Java projects for almost 20 years now.

This was done with SVN projects. Keeping the blobs out of your source repos has been the preferred way for a long time.

[Edit] The only folks who seem to want to do this are game developers, and they are generally not people you would want to emulate.

Post reply on HN