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

Ask HN: Can we do better than Git for version control?

news.ycombinator.com

Post reply on HN
Print view View original

301–309 of 309 posts

Re: Ask HN: Can we do better than Git for version control?

#301

Post by gitaarik »

grecy wrote: post #250
Apreche wrote: post #77

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…

> I’m old enough to have used RCS, CVS, SVN, then finally Git I'm old enough to have used CVS, SVN and then a bit of git. I remember the big selling point to go from CVS to SNV was "you can put binaries in there!" ... which we never did. And now I see the selling point to go from SNV to Git is "you can do really complicated stuff like rebase".... which we've never done. For a team who just does run of the mill distri…

SVN doesn't do very good conflict resolution. It especially becomes more of a problem when you have multiple people working on several branches, that might want to merge some of each other's work. Apart from this, git also came with many more advanced features that improves branch and history management.

Re: Ask HN: Can we do better than Git for version control?

#303

Post by withinboredom »

Noneofya wrote: post #291
allarm wrote: post #286

Earlier quoted context omitted.

Maybe they just need to follow carefully written instructions created by more technical people?

When has that ever worked? And why does this count as a solution rather than a poor workaround for you?

Since forever? It's not like people are born with an innate knowledge of how any software works.

Manuals/guides/tutorials are the most scalable way to teach people how to do literally anything.

Re: Ask HN: Can we do better than Git for version control?

#304

Post by withinboredom »

Noneofya wrote: post #290
withinboredom wrote: post #185

Earlier quoted context omitted.

This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft t…

>Most of this was built by Microsoft to work on Windows with git. Hacking git into something it is not does not qualify as learning to cope with git in my book. Apparently git does not solve all problems and there is indeed value in exploring other options and building new systems that fill other niches.

umm. it's still git. Git is basically content-addressable storage with a couple of layers on top (heads/tags/trees) which is itself content-addressable storage. If you can offload that storage to a remote, you still have git... and can use git as you've always used git. The tricky part is making it feel like the storage is local and your own, instead of shared.

You only need this when, well, you need it. You can go a surprisingly long way (nearly a decade of daily commits by hundreds of programmers) and stick to vanilla git.

Re: Ask HN: Can we do better than Git for version control?

#305

Post by slalomskiing »

allarm wrote: post #294
Noneofya wrote: post #291

Earlier quoted context omitted.

When has that ever worked? And why does this count as a solution rather than a poor workaround for you?

What has ever worked, reading and following manuals? Like, forever? Stop pretending there's a simple solution. People just need to use their brains. Both people who write those manuals and those who read them.

There literally already is a simpler solution for non-technical people, it’s called Perforce and tons of game studios use it

But I’m sure you’re smarter than the whole industry so you probably know better

Re: Ask HN: Can we do better than Git for version control?

#306

Post by allarm »

slalomskiing wrote: post #305
allarm wrote: post #294

Earlier quoted context omitted.

What has ever worked, reading and following manuals? Like, forever? Stop pretending there's a simple solution. People just need to use their brains. Both people who write those manuals and those who read them.

There literally already is a simpler solution for non-technical people, it’s called Perforce and tons of game studios use it But I’m sure you’re smarter than the whole industry so you probably know better

Hey smart man, this is a thread about git, not perforce. Just fyi.

Re: Ask HN: Can we do better than Git for version control?

#307

Post by trevyn »

phyzome wrote: post #190
trevyn wrote: post #160

Earlier quoted context omitted.

Is there a difference?

Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.

So just make sure the moves and edits are in separate commits?

Re: Ask HN: Can we do better than Git for version control?

#308

Post by phyzome »

trevyn wrote: post #307
phyzome wrote: post #190

Earlier quoted context omitted.

Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.

So just make sure the moves and edits are in separate commits?

Yes, that's the standard workaround.

Re: Ask HN: Can we do better than Git for version control?

#309

Post by fragmede »

vtbassmatt wrote: post #184
fragmede wrote: post #78

Yes we can. The shortcomings of git are that it doesn't handle binary files well, and you can't clone a slice of a repo. the system after git will handle both of those. mono repo or not is not a question with aftergit because you can clone just a subdir and work there, without the overhead of cloning the whole thing, but also without the weight of keeping up with commits happening outside of your directory.

Like this? https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

I've seen that. Shallow clones have too many reason to upgrade to a full clone to be totally useful, as well as the additional load on the server it causes. Partial clones don't (yet) let me just checkout a subdir of the repository with the checkout rooted in that subdir.
Post reply on HN