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 manage the equivalent of .gitignore? What am I misunderstanding about the benefits of how this works?
Jujutsu – A Git-compatible DVCS that is both simple and powerful
121–130 of 233 posts
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#122In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarba…
What I would do in this case is two rebase -i.
Say you start from:
A
B
state-of-B
state-of-A
pick A
x git revert HEAD
pick A
pick B
pick a
squash d
pick b
squash a
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#123In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarba…
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.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#124Maybe 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…
You are too brainwashed by git.:)
The bigger picture is that the project is trying to provide a better interface on top of the existing git data store. As someone who used darcs for a major project before Git dominated DVCS, there are much better user interfaces than what Git offers, and attempts to improve upon Git is a diversity to encourage.
Unlike picking your own text editor, a whole team has to agree about the choice of DVCS, making it harder to try new ones.
The beauty of a solution with a Git-compatible data store is it allows some people on the team to experiment with it while still collaborating with people using Git.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#125Maybe 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…
Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on the screen at that point, I'm as likely to notice mistakes there as I am in somebody else's code, if not less.
When I'm adding a change, on the contrary, it's something I wrote minutes to seconds ago, I know what's in that code, and by adding that I'm kind of making a statement that this wasn't some random bullshit I do with the code, but something I intend to keep (even if later I'll completely change that while interactively rebasing or something like that).
On the other hand, I didn't complain that much back in the day when I was using SVN. But I feel like my current workflow that employs most unique features of git is actually much better. Basically, horribly inconsistent CLI is the only complaint I have about git.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#126Earlier quoted context omitted.
> In git, every commit is a snapshot and not a delta. I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot. I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the sc…
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://github.com/git/git/blob/v2.35.1/builtin/revert.c#L23...
Both the "revert" and "cherry-pick" operations initialize a sequencer object with a single operation in the sequence. (This is the same mechanism underlying "git rebase -i").
From there we can find the call to sequencer_pick_revisions, which leads us to the sequencer implementation, where there's a fast-path for ordinary cherry-picks leading us to a short function single_pick, which in turn calls do_pick_commit: https://github.com/git/git/blob/v2.35.1/sequencer.c#L2066
This operation then does the following:
- Determine what we're applying a diff on top of: https://github.com/git/git/blob/v2.35.1/sequencer.c#L2083-L2...
- Find a parent commit. If the commit has more than one parent, it requires you to specify a "-m" option indicating which parent to diff against. https://github.com/git/git/blob/v2.35.1/sequencer.c#L2109-L2...
- Set up the commit message and some other stuff.
- Set the variable "base" to the parent it found and "next" to the commit being cherry-picked. https://github.com/git/git/blob/v2.35.1/sequencer.c#L2187-L2...
- Assuming no merge strategy (or either of the standard strategies "ort" or "recursive") was specified on the command line, call do_recursive_merge. https://github.com/git/git/blob/v2.35.1/sequencer.c#L2237-L2...
In turn, do_recursive_merge calculates a head_tree from the current HEAD (https://github.com/git/git/blob/v2.35.1/sequencer.c#L645), and then calls either merge_incore_nonrecursive (the current default, from the new "ort" merge strategy) or merge_trees (from the older "recursive" merge strategy) with three trees (i.e., with no further ancestry information): the base is the parent it found, and the two sides being merged are your current HEAD and the (tree of) the commit being cherry-picked.
That is to say, at no point does it care whether the two commits even have a common ancestor! It's just doing an operation on trees. It is doing a three-way merge, yes, but the graph of the merge it's doing is one that potentially doesn't actually exist in reality.
Or, in other words, it's trying to compute the tree that could be equally well described as the result of
- applying the diff of the commit you're cherry-picking to your current HEAD
- applying the diff between your current HEAD and the parent of the commit you're cherry-picking to the commit you're cherry-picking
So this is more powerful than purely applying a diff with no information about the base of the diff, but it is very much like applying a diff.
One way you can test this without drilling into source code is to make two independent commit histories (using either two git repos, or git checkout --orphan, or whatever) where a commit in one history has a diff that would apply to a file in the other history if applied with the "patch" command. Then try cherry-picking it into the second history. It should work.
(In the revert case, it more or less does the same thing, just with "base" and "next" flipped. That is, if you have commits A, B, and C, and you want to revert B, it does a three-way merge where the base is the tree after B, one side is the tree after A, and the other side is the tree after C!)
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#1271) 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…
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?
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#128Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature bra…
I think a lot of git is overkill for what most people use it for it. It's time for a new tool to do these basic operations push/pull/undo/redo. Branching is helpful, but if you work in a relatively small codebase a tool that did cp -r under the hood would work perfectly 99% of times.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#129Maybe 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…
Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on…
> I wouldn't want anything to be added by default
This line of reasoning works really well for those who understand (and want to understand) how git works. I know plenty of people who don't care about their development tools (e.g. scientists), and for them the index is a chore in the way of more important problems.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#130Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature bra…
I’m not sure I understand how you can have a git compatible data store, but not have git compatible feature branches?