For comparison, another simpler (somewhat?) git-compatible client called "game of trees" or got (about which I know to little to compare/contrast well): https://gameoftrees.org/ .
Jujutsu – A Git-compatible DVCS that is both simple and powerful
221–230 of 233 posts
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#222Earlier quoted context omitted.
I did, and it's almost certainly nicer than Git for commit splitting. But even though I might use a tool specifically designed for user-friendly commit splitting, I still want: `git add -e`, `git diff --staged` (to see what I added with `git add -e`) vs `git diff` (to see what I left out), and `git commit` w/o `-a` to commit the contents of the index. This is easier for me than `$WHATEVER commit` followed by `$WHATEV…
That gist seems like a simplified version of https://github.com/mhagger/git-imerge , so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
I'll take a look, thanks for the link!
EDIT: The idea of being able to suspend/resume and push/fetch in-progress merges/rebases is very cool indeed. It's hard to tell if it could speed up the task of rebasing across thousands of commits or not -- the README doesn't say. I like Viktor's script because it's very focused on one thing: quickly rebasing local commits across thousands of new upstream commits with a minimum of conflicts -- a simple solution to a simple problem statement (though the problem can feel huge when you have it).
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#223Earlier quoted context omitted.
It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up. It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.
It must be admitted that if merges are involved , it becomes somewhat harder to do something like this, as you can no longer use the easy and safe path of an interactive rebase to edit the commit and remove the file, and must reach for filter-branch or similar, which are generally a good deal scarier and easier to make difficult-to-identify mistakes with. (Fortunately, the man page git-filter-branch(1) deals with thi…
I hear you, definitely can get tricky. But again, it isn't that hard.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#224Earlier quoted context omitted.
True but there's usually a "git diff --staged" in the middle to check what I am committing.
You can do that with “git show HEAD” (and “git commit --amend -p”).
`git diff --staged` is superior. For one, you get all the options to `git diff`. For another, it has no side effects, unlike `git commit --amend -p`.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#225It's amazing what some people can do in 20% of their work time.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#226Earlier quoted context omitted.
You can do that with “git show HEAD” (and “git commit --amend -p”).
`git diff --staged` is superior. For one, you get all the options to `git diff`. For another, it has no side effects, unlike `git commit --amend -p`.
> `git diff --staged` is superior. For one, you get all the options to `git diff`.
Most of which you can get on git show at least if they're relevant to “what have I added”. And of course you can also use git diff on commits if you need something super specific.
> For another, it has no side effects, unlike `git commit --amend -p`.
… “git commit --amend -p” is the replacement for subsequent “git add -p”, as the GP was talking about a workfliw where they’d intersperse staging stuff and looking at what they’d staged.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#227Maybe 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…
The stage is git's killer feature to me. I'm very iterative, so I tend to change a lot of tangential things as I narrow down the best implementation of my code. Knowing that I'm free to change whatever I want and only commit the parts that I've determined are good is very liberating.
My workflow is basically just change whatever I want to get to my goal. When I finally get the behavior I want, stage the changes and stash the rest. Once I've verified that everything works, commit the stage and drop the stash. I don't have to think about anything not directly related to my commit. Feels like with tools like jujutsu, pijul, mercurial...I'd have a lot of manual cleanup to do _before_ committing...and then what if I accidentally clean up something I didn't realize I needed? It's gone. Whereas, with git I can just pop the stash and stage whatever piece I missed.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#228Maybe 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…
The stage is git's killer feature to me. I'm very iterative, so I tend to change a lot of tangential things as I narrow down the best implementation of my code. Knowing that I'm free to change whatever I want and only commit the parts that I've determined are good is very liberating. My workflow is basically just change whatever I want to get to my goal. When I finally get the behavior I want, stage the changes and s…
Does https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help explain?
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#229Earlier quoted context omitted.
> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?
As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.…
> I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network.
Ah, OK, gotcha. Thanks!
> You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.
Yeah. But fortunately not all that much of a hassle for a small(ish) dev team.
> And if you settle on sharing one central box as the canonical node (which IMO is the right answer),
Yeah, we called it "the Dev server". :-)
> you're no longer truly using a distributed system - it's a de facto centralized system.
But in a corporate (or even Open Source project?) environment, The Powers That Be probably want that kind of / that much centralisation anyway.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#230Earlier quoted context omitted.
> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?
You can have sync conflicts with multiple people pushing to a bare repo on a shared folder at the same time. This kind of file sharing with git only works on NFS or filesystems that support locking (look at the git manual for this warning). Syncthing doesn't support that--it _might_ work for some time, but stress it with multiple people all at once and it will explode into sync conflicts eventually.
Ah, OK, thanks!
Yeah, I've probably just simply been lucky so far: IME with git, which hasn't been very extensive -- and only with a quite small dev team -- that just never happened to occur.