[flagged]
The future of version control
331–340 of 407 posts
Re: The future of version control
#332Earlier quoted context omitted.
Isn't that how the current systems work though? Git inserts conflict markers in the file, and then emacs (or whatever editor) highlights them The big red block seems the same as "flagged", unless I'm misunderstanding something
With git, conflicts interrupt the merge/rebase. And if you end up in a situation with multiple rebases/merges/both, it's easy to get a "bad" state, or be forced to resolve redundant conflict(s) over and over. In Jujutsu and Pijul, for example, conflicts are recorded by default but marked as conflict commits/changes. You can continue to make commits/changes on top. Once you resolve the conflict of A+B, no future merge…
Thank you for the explanation, i did misunderstand! seems like a neat feature
Re: The future of version control
#333Outside of the merit of the idea itself, I thought I was going to look at a repository at least as complete as Linus when he released git after 3 weeks, especially with the tooling we had today. Slightly disappointed to see that it is a 470 line python file being touted as "future of version control". Plenty of things are good enough in 470 lines of python, even a merge conflict resolver on top of git - but it looks…
It clearly says in the article that this is just a demo
A demo as "the future of" something doesn't really resonate with me. It's like saying a melodic motif and a couple well-written lines of lyrics are "the future of" my new music career.
Re: The future of version control
#334You’re still treating code as text which it isn’t (in the same way you wouldn’t treat JSON as text) it’s actually more like an AST. Jujutsi (jj) does that. And it’s git compatible.
No, it doesn't.
Re: The future of version control
#335how are CRDTs magic wrt to merges and conflicts?
im happy to see new entrants into the space. I think I'm a git beginner+. I know enough to be productive and am no longer fearful of it... and I even train up my coworkers on it and help them out of binds... but I am not an expert by any means and still sometimes resort to radical things to get me through some problem I've put myself into.
Re: The future of version control
#336Earlier quoted context omitted.
Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" ( https://git-scm.com/docs/git-config#Documentation/git-config... ). If you do that, Git’s conflict markers show the base version as well: >>>>>> right With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added…
I still find this shit unreadable, even after years of practice.
I've trained myself to avoid this entirely by avoiding changing lines unnecessarily. With LLMs, I also force them to stay concise and ONLY change what is absolutely necessary.
Re: The future of version control
#337Earlier quoted context omitted.
Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.
I have met more than one person who would doggedly tolerate rebase, not even using rerere, instead of doing a simple ‘git merge --no-ff’ to one-shot it, not understanding that rebase touches every commit in the diff between main and not simply the latest change on HEAD. Not a problem if you are a purist on linear history.
not understanding that rebase touches every commit in the diff
it sounds like that's a problem for you. why would that be? i prefer rebase and fast forward, but i am fully aware that rebase rewrites all commits.
Re: The future of version control
#338Why must everyone preprocess their blog posts with ChatGPT? It is such a disservice to ones ideas.
Because writing is really hard.
Re: The future of version control
#339Earlier quoted context omitted.
Have you tried this? It would be a nightmare. The LLM wold "solve" the merge conflict by eliminating the code.
But that should make the builds or some tests to fail no? I think we can consider it as a first approximation and proceed to a manual review. It should be a lot easier than manually resolving the difficult merge..
That’s solved by disabling or removing those tests.
I have tried this. It does’t work.
Re: The future of version control
#340Earlier quoted context omitted.
My understanding of the way this is presented is that merges don't _block_ the workflow. In git, a merge conflict is a failure to merge, but in this idea a merge conflict is still present but the merge still succeeds. You can commit with conflicts unresolved. This allows you to defer conflict resolution to later. I believe jj does this as well? Technically you could include conflict markers in your commits but I don'…
If other systems are doing it too then I guess it must be useful But why is it useful to be able to defer conflict resolution? I saw in a parallel comment thread people discussing merge commit vs rebase workflow - rebase gives cleaner git history but is a massive pain having to resolve conflicts on every commit since current branch diverged instead of just once on the final result with merge commit. Is it that? Defer…
Deferred conflict resolution is amazing in jj because I may never return to some of the branches that are in conflict and therefore might never bother resolving them.
I rebase entire trees of commits onto main daily. I work on top of a dev-base commit and it has all kinds of anonymous branches off it. I rebase it and all its subbranches in 1 command and some of those sub branches might now be in a conflicted state. I don’t have to resolve them until I need to actually use those commits.
dev-base is an octopus merge of in-flight PRs of mine. When work is ready to be submitted it moves from being a descendent of dev-base to a parent of dev-base.
Rebasing all my PRs and dev-base and all its descendents is 1 command. Just make sure my @ is a descendent of dev-base and then run: jj rebase -d main