101–110 of 481 posts
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
Earlier quoted context omitted.
> They learn a set of narrow workflows and never explore beyond. And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem. I don't need to know how a fi…
svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
Would have been great if they used an European alternative ( like Codeberg ).
Earlier quoted context omitted.
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them. Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.
Earlier quoted context omitted.
Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
The reason is that it is more than code. Managing identity is hard and for many projects besides having a source of truth for the repository you also need some degree of project management (bug tracking) And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally a…
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
Earlier quoted context omitted.
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
To be fair, most of the its difficulty is realized when you're stuck with a teammate rewriting history. Who, much like anyone anyone doing the same, hasn't bothered reading a book explaining things.
Earlier quoted context omitted.
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
I regard the Git docs as being fully equal to scientific Wikipedia articles. Everything is fully and completely explained, in terms which mean nothing.
(They ain't perfect, of course.)