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

131–140 of 233 posts

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

#131

Post by Aeolun »

martinvonz wrote: post #52
kuboble wrote: post #46

1) What are the advantages of using native backend as compared to git? 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? I remember when I was the only team member using git-svn plugin my coworkers were confused when I svn-committed many commits at once with some of them breaking the time order of the svn history (as git-svn commits in svn were recorded with git ti…

> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend ( https://github.com/martinvonz/jj/issues/27 ). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note…

> git clients won't know what to do with the conflicted files

This seems kind of similar to pushing git files with conflicts with the git client? Maybe the Jujutsu formatting is slightly different, but the concept is the same.

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

#132

Post by gitgud »

uses wrote: post #121

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…

Does that mean that there's no "staged changes" in Jujutsu? That's one of my favourite and ironically hated parts of git...

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

#133

Post by TillE »

uses wrote: post #121

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…

There are already popular Git GUIs like GitHub Desktop which abstract away the staging area. It's also how basically every other VCS works.

Yeah, you should have an appropriately comprehensive .gitignore file, that's good practice in any case.

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

#134

Post by martinvonz »

gitgud wrote: post #132
uses wrote: post #121

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…

Does that mean that there's no "staged changes" in Jujutsu? That's one of my favourite and ironically hated parts of git...

Yes, no staging area. Does https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help address your concern?

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

#135

Post by jareds »

netghost wrote: post #105
fsloth wrote: post #75

Earlier quoted context omitted.

What are the problems that Subversion has? My only experience of svn is of simple personal projects and in that scope it worked pretty well - not contesting your opinion, but would like to know at which point svn becomes problematic.

If subversion had branches, they were not nearly as easy to use as in git. It also didn't have a great notion of offline work (to my memory). For what it's worth, SVN was pretty straightforward and worked well enough at the time. Later, Mercurial addressed SVN's deficiencies with a familiar interface.

IN my experience pull requests were not a thing in Subversion. We would attach patch files to Jira for code reviews. Git allowed for much easier workflow with merging branches instead of directly applying patches to trunk. This probably has a lot to do with the fact that we used Bitbucket for Git hosting and a plain Subversion server with no extra features to help with code reviews.

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

#136

Post by martinvonz »

Aeolun wrote: post #131
martinvonz wrote: post #52

Earlier quoted context omitted.

> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend ( https://github.com/martinvonz/jj/issues/27 ). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note…

> git clients won't know what to do with the conflicted files This seems kind of similar to pushing git files with conflicts with the git client? Maybe the Jujutsu formatting is slightly different, but the concept is the same.

These are representations of conflicts that are stored as special files, they are not regular files with conflict markers in. If you look at the commit with regular `git`, you're going to see a weird file with some JSON in it.

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

#137

Post by martinvonz »

krick wrote: post #127
martinvonz wrote: post #52

Earlier quoted context omitted.

> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend ( https://github.com/martinvonz/jj/issues/27 ). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note…

If we ignore the UI level stuff, like doing something by default when you switch to another branch, etc — is it in any way "smarter" than git? For example, are there situations, when I couldn't reorder my commits when doing git rebase -i without resolving some conflicts manually, while jj would be able to correctly handle them for me?

Yes and no. For example, if you reorder two commits, the new child commit will never have conflicts even if the parent had conflicts. That's because the changes from both original commits still apply afterwards. Similarly, if you rebase a commit and it results on conflicts, you can then rebase it back and the conflicts will go away. See the demo at https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR

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

#138

Post by kazinator »

geofft wrote: post #126
kazinator wrote: post #111

Earlier quoted context omitted.

When you cherry-pick a commit from another branch, it's not doing anything like a read-tree to make your current work look like that commit's snapshot state. It's doing something like three-way merge between that commit, your baseline and a common ancestor (I'm guessing: the same one that would be identified by git merge-base .) That's why cherry-pick identifies conflicts. A cherry-pick deos not just do a diff with i…

It's doing something weirder than that, but "it applies a diff between a specified commit and its parent on top of your current work" is more accurate/intuitive than "it does a three-way merge with a common ancestor". No common ancestor is involved. The first hint that it's doing something interesting is that the implementation of cherry-pick is in revert.c, because it's implemented as a variant of revert: https://gi…

It just sounds like, more or less:

    $ diff3 -m my-file pick-file-parent pick-file

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

#139

Post by lostintangent »

This is awesome! And it’s so exciting to see folks investing energy into this problem space.

Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

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

#140

Post by glandium »

kazinator wrote: post #123
glandium wrote: post #122

Earlier quoted context omitted.

What I would do in this case is two rebase -i. Say you start from: A B And you want: state-of-B state-of-A I'd do a rebase -i with: pick A x git revert HEAD pick A pick B Let's call the resulting commits of the above a, b, c and d. With the following rebase -i, you get what you want: pick a squash d pick b squash a In practice, I just do git revert HEAD; git cherry-pick HEAD~ before working on B, so I only really do…

Problem is, you may get ugly conflicts along the way which serve no purpose to the end goal, and have to be resolved more than once in different directions. It's an abstraction inversion to be doing that. The system doesn't work with diffs and merges: that's just layering on top. The system contains snapshots, and so if you want to rearrange snapshots in a different order, that's the best abstraction layer to work at…

Oh, I actually messed it up. Which in hindsight I don't know why because it's really much simpler than what I started with... but then I usually do it with more intermediate steps, and on an actual command line, not on a mobile phone...

Anyways:

You start with:

  original-state
    A
  final-state
    B
  intermediate-state
You want

  original-state
    X
  intermediate-state
    Y
  final-state
What you just need to do is:

  git revert HEAD
Which gives you:

  original-state
    A
  final-state
    B
  intermediate-state
    revert (C)
  final-state
Then X = A + B and Y = C, so with one rebase -i:

  pick A
  squash B
  reword C
No conflicts. The important thing is that with appropriate reverts and reapplication of commits, you can make your history contain the states you want in the order you want, even if in between you have repeated states in the wrong order. Then you squash things so that you only keep the states you wanted in the first place.

Edit: but yes, you can achieve the same outcome with read-tree or checkout.

Edit2: come to think or it, you can probably do what you want with a couple git replace --graft and a noop filter-branch.

Post reply on HN