101–110 of 164 posts
Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The…
Earlier quoted context omitted.
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When…
> Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases Since when does rerere not work with rebase anymore?
I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh. I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t kno…
Are you making MRs from other branches in the same repo, or are you making e.g. main to main MRs from your own fork?
Earlier quoted context omitted.
It shouldn't matter, under the hood the tree is the same for both. I don't know why jj would complain but git wouldn't, hm.
for me, squash merges are enforced on github, and usually results in some weird / empty commits if i rebase a local stack after pulling in changes with part of the stack merged.
Earlier quoted context omitted.
> Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases Since when does rerere not work with rebase anymore?
I think it does but rerere is not nearly as good as first class conflicts in jj
>> Git records merge resolutions
isn't true either.
Earlier quoted context omitted.
Yeah I definitely hated Subversion, which helped push me to try Git back in the day. Actually, back then I was an `hg` guy. That battle was lost long ago though. I think you linked to the same post as OP, though?
I wonder if there's a parallel universe where people are writing posts about Sapling and getting mercurial users to migrate to it.
I probably would have stuck with Sapling, but my company switched to git and the jj integration was cleaner -- especially being able to run in colocated mode: your project root directory has both .jj/ and .git/ subdirectories, and you can use both jj and git commands without much trouble. If someone gives me a git commit hash, I can just use it directly with jj.
Sapling is good. I'm still fond of it, and in fact still have a few repositories I haven't switched over yet. But being able to do everything with a single tool is useful, plus jj gives me some extra capabilities over sapling (or at least things that I don't know how to do as easily).
one of the better jj writeups. People, just TRY it out.
one of the better jj writeups. People, just TRY it out.
Earlier quoted context omitted.
The best thing that could come out of jujitsu is git itself adopting the change-id system (which I believe I read somewhere is being considered). If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO
git is both a (bad) UI and a protocol. Jujutsu is a UI on top of git (the protocol). There's nothing wrong with taking the time to learn how to use a bad UI, especially if there's no other option. But don't mistake your personal mastery of git for evidence that it's better than jj. In all likelihood, the git proposal you allude to would not extend further than adding a bit of persistent metadata that follows commits…