[deleted]
The future of version control
141–150 of 407 posts
Re: The future of version control
#142What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT. Engineer A intended value = 1 Engineer B intended value = 2 CRDT picks 2 The outcome could be semantically wrong. It doesn't reflect the intent. I think the primary issue with git and every other version control is the terrible names for everything. pull, p…
For that you need a very centralized VCS, not a decentralized one. Perforce allows you to lock a file so everybody else cannot make edits to it. If they implemented more fine-grained locking within files, or added warnings to other users trying to check them out for edits, they'd be just where you want a VCS to be.
How, or better yet, why would Git warn you about a potential conflict beforehand, when the use case is that everyone has a local clone of the repo and might be driving it towards different directions? You are just supposed to pull commits from someone's local branch or push towards one, hence the wording. The fact that it makes sense to cooperate and work on the same direction, to avoid friction and pain, is just a natural accident that grows from the humans using it, but is not something ingrained in the design of the tool.
We're collectively just using Git for the silliest and simplest subset of its possibilities -a VCS with a central source of truth-, while bearing the burden of complexity that comes with a tool designed for distributed workloads.
Re: The future of version control
#143I think there are still strong advantages to the centralized locking style of collaboration. The challenge is that it seems to work best in a setting where everyone is in the same physical location while they are working. You can break a lock in 30 seconds with your voice. Locking across time zones and date lines is a nonstarter by comparison.
It seems like in a reasonable sized org you should not be merging so often that “centralized locking … across time zones” should be an issue. Are people really merging that often? What is being merged? Doc fixes?
[dead]
Re: The future of version control
#144Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance. It's been amazing watching it grow over the last few years.
The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"
But you do have the op log, giving you a full copy of the log (incl. the contents of the workspace) at every operation, so you can get out of such mistakes with some finagling.
You can choose to have a workflow where you're never directly editing any commit to "gain back autonomy" of the working copy; and if you really want to, with some scripting, you can even emulate a staging area with a specially-formatted commit below the working copy commit.
Re: The future of version control
#145Earlier quoted context omitted.
I used to use rebase much more than merge but have grown to be more nuanced over the years: Merge commits from main into a feature branch are totally fine and easier to do than rebasing. After your feature branch is complete you can do one final main-to-feature-branch merge and then merge the feature branch into main with a squash commit. When updating any branch from remote, I always do a pull rebase to avoid merge…
I am now wholly bought into the idea of having a feature branch with (A->B->C) commits is an anti-pattern. Instead, if the feature doesn't work without the full chain of A+B+C, either the code introduced in A+B is orphaned except by tests and C joins it in; or (and preferably for a feature of any significance), A introduces a feature flag which disables it, and a subsequent commit D removes the feature flag, after it…
I treat each feature branch as my own personal playground. There should be zero reason for anyone to ever look at it. Sometimes they aren’t even pushed upstream. Otherwise, just work on main with linear history and feature flags and avoid all this complexity that way.
Just like you don’t expect someone else’s local codebase to always be in a fully working state since they are actively working on it, why do you expect their working branch to be in a working state?
Re: The future of version control
#146Earlier quoted context omitted.
I always checkout the branch I am merging something into. I was vaguely aware I could have main checked out but merge foo into bar but have never once done that.
git checkout mybranch git rebase main A conflict happens. Now "ours" is main and "theirs" is mybranch , even though from your perspective you're still on mybranch. Git isn't, however.
Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.
Re: The future of version control
#147Is it a good thing to have merges that never fail? Often a merge failure indicates a semantic conflict, not just "two changes in the same place". You want to be aware of and forced to manually deal with such cases. I assume the proposed system addresses it somehow but I don't see it in my quick read of this.
They address this; it's not that they don't fail, in practice... the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails.
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
Re: The future of version control
#148Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance. It's been amazing watching it grow over the last few years.
The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"
You can be messy. The lack of an explicit staging area doesn't restrict that. `jj commit` gives the same mental model for "I want to commit 2 files from the 5 I've changed".
Re: The future of version control
#149Earlier quoted context omitted.
iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed. I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.
git checkout mybranch git rebase main Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the reb…
Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"
Re: The future of version control
#150Do I have it right that it’s basically timestamp based, except not based on our clocks but one it manages itself?
So as long as all updates have been sent to the server from all clients, it will know what “time” each character changed and be able to merge automatically.
Is that it basically?