Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of version control

bramcohen.com

Post reply on HN
Print view View original

211–220 of 407 posts

Re: The future of version control

#211

Post by KPGv2 »

sheept wrote: post #198
mamcx wrote: post #185

Earlier quoted context omitted.

Seriously! Why not show the names of the branch + short Id (and when is not direct name, at least "this is from NAME")

doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.

I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source projects rather than someone else's).

HEAD is "the thing we're editing now" but that's not terribly useful when rebasing since you're repeatedly editing a fake history.

Re: The future of version control

#212

Post by KPGv2 »

IgorPartola wrote: post #97
kungito wrote: post #85

Earlier quoted context omitted.

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

> ours means what is in my local codebase

Since it's always one person doing a merge, why isn't it "mine" instead of "ours"? There aren't five of us at my computer collaboratively merging in a PR. There is one person doing it.

"Ours" makes it sound like some branch everyone who's working on the repo already has access to, not the active branch on my machine.

Re: The future of version control

#213

Post by orthoxerox »

cerved wrote: post #207
orthoxerox wrote: post #160

Earlier quoted context omitted.

I had to make an alias for rebasing, because I kept doing the opposite: git checkout master #check out the branch to apply commits to git rebase mybranch #Apply all commits from mybranch Now I just write rebase-current-branch and it does what I want: fetches origin/master and rebases my working branch on top of it. But "ours"/"theirs" still keeps tripping me up.

Tip, you may want to use origin/HEAD over origin/master

Is it the naming-independent identifier of the tip of the trunk?

Re: The future of version control

#214

Post by ozten »

nicoty wrote: post #174
ozten wrote: post #58

Earlier quoted context omitted.

They should mirror on GitHub for marketing purposes

How would they do that if they don't use git for version control? Does GitHub allow other forms of version control other than git?

pijul clone https://nest.pijul.org/pijul/pijul

pijul log --hash-only > all_changes.txt

pijul unrecord --all

git init

``` for HASH in $(cat all_changes.txt); do pijul apply "$HASH" pijul reset # sync working copy to channel state git add -A git commit -m "pijul change: $HASH" done ```

git remote add origin git@github.com:you/pijul-mirror.git git push -u origin main

Re: The future of version control

#215

Post by KPGv2 »

sheept wrote: post #202
marcellus23 wrote: post #109

Earlier quoted context omitted.

That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense. What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better wit…

> Git generally works better without rebases and squash commits.

If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.

Re: The future of version control

#216

Post by afiori »

sroussey wrote: post #180
josephg wrote: post #163

Earlier quoted context omitted.

CRDTs should be able to give you better merge and rebase behaviour. They essentially make rebase and merge commits the same thing - just different views on a commit, and potentially different ways to present the conflict. CRDTs also behave better when commits get merged multiple times in complex graphs - you don’t run into the problem of commits conflicting with themselves. You should also be able to roll back a sing…

In theory, maybe. In practice… last write wins (LWW) is a CFDT operator, so replace every mention of CRDT with LWW and issues will more obvious. Really though, the problem with merges is not conflicts, it’s when the merged code is wrong but was correct on both sides before the merge. At least a conflict draws your attention. When I had several large (smart but young) teams merging left and right this would come up an…

being able to customize the chunking/diffing process with something analogous to an lsp would greatly improve this. In my experience a particularly horribly handled case is when eg two branches add two distinct methods/functions in the same file location (especially if there is some boilerplate so that the two blocks share more than a few lines).

a language aware merge could instead produce

>>>> function foo(){ ... } ===== function bar(){ ... } <<<<<<

Re: The future of version control

#217

Post by KPGv2 »

IgorPartola wrote: post #127
clktmr wrote: post #121

Earlier quoted context omitted.

The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.

Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts. As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits…

This is what I do, and I was taught by an experienced Git user over a decade ago. I've been doing it ever since. All my merges into main are fast forwards.

Re: The future of version control

#218

Post by verdverm »

simonw wrote: post #199
nicoty wrote: post #174

Earlier quoted context omitted.

How would they do that if they don't use git for version control? Does GitHub allow other forms of version control other than git?

SQLite does it despite using Fossil - their mirror is at https://github.com/sqlite/sqlite Git is so established now that it's sensible for alternative VCS to have a mode where they can imitate the Git protocol - or seven without that you can still checkout the latest version of your repo and git push that on a periodic basis.

Similarly, CUE uses Gerrit and has two way sync. If you are building a VCS today, git interop is a must.

Re: The future of version control

#219

Post by danpalmer »

I'm struggling to understand the problem this solves for me. I can see in the abstract why this might be useful, but in practice I don't see the problems.

For me, jj represents a massive step forward from git in terms of usability, usefulness, and solving problems I actually have.

I think the next step forward for version control would be something that works at a lower level, such as the AST. I'd love to see an exploration of what versioning looks like when we don't have files and directories, and a piece of software is one whole tree that can be edited at any level. Things like LightTable and Dark have tried bits of this, it would be good to see a VCS demo of that sort of thing.

Re: The future of version control

#220

Post by nchmy »

aduwah wrote: post #104
alunchbox wrote: post #36

Jujutsu 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're mistaken. I'm an absolute version control slob. JJ allows me to continue like that yet also collaborate with others. It tracks literally everything so I can not only split, squash, and rebase things to wherever they need to be, but can also rollback/restore/recover anything from either the repo-wide oplog or revision-specific evolog

You really ought to dive in deeper. jjui makes it all vastly simpler

Post reply on HN