Live data from Hacker News

Gitless: A simple version control system built on top of Git

gitless.com

91–100 of 143 posts

Re: Gitless: A simple version control system built on top of Git

#91

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…

I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow.

First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code.

Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure.

Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.

Re: Gitless: A simple version control system built on top of Git

#92
post #88

Earlier quoted context omitted.

Well I'm definitely not a git expert ( i guess I should just invest more time into it). But was wondering the other day. Isn't GIT "as good" as its(source control) going to get ? Giving the problem its trying to solve:source control,distributed teams/repo's, branching etc... I mean what comes after GIT ?

There are some projects that aim to improve the merging model of Git, such as pijul[1]. Git uses "three-way merge" and it is fairly well-known that the repository state you end up with for non-fast-forward merges (merges that need merge commits) is not necessarily well-understood in all cases. Pijul uses a more efficient algorithm that has well-understood merge characteristics, and is designed around patches not repo…

git was easier to use :) - thanks will check it out

Re: Gitless: A simple version control system built on top of Git

#93

Earlier quoted context omitted.

Not everyone here is a 'professional' software developer. Git does have a steep learning curve. (I've used git extensively for years, just playing devil's advocate)

To reinforce your point - I have worked with people in the past, mostly older, that struggled a lot with Git when all they were trying to do was something simple like commit some static files generated from third-party software to my project. These people only needed the bare minimum (stage, commit, push) of Git yet found themselves baffled and fighting with the tool because of all the possibilities and things it cou…

There's a fair amount of tools capable of manipulating a Git repo, not all of which are `/usr/bin/git`. "Everybody must use this complex CLI power tool, therefore people struggle" is simply untrue here, in the premise.

Re: Gitless: A simple version control system built on top of Git

#94

Earlier quoted context omitted.

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obvious…

Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.

No, you also have the choice of using separate repositories, and just connecting them with dependency lists. I never understood the obsession with putting hundreds of millions of lines of code¹ in a single repo. Whatever happened to decoupling?

¹ Git can handle dozens of millions, as shown by the Linux kernel

Re: Gitless: A simple version control system built on top of Git

#95
post #58
post #37

Earlier quoted context omitted.

You might not use it to do partial commits but many others do.

Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?

It could. OTOH, most workflows I've seen use the approach "do whatever you wish in your repo and in your branches, but merging requires that the tests pass on a CI server, which only has access to the repository and has exactly zero uncommited files.

In other words, go ahead and break your builds six ways from Sunday, but they won't get merged until they pass based solely on the state of the repo.

Re: Gitless: A simple version control system built on top of Git

#96

Earlier quoted context omitted.

Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.

No, you also have the choice of using separate repositories, and just connecting them with dependency lists. I never understood the obsession with putting hundreds of millions of lines of code¹ in a single repo. Whatever happened to decoupling? ¹ Git can handle dozens of millions, as shown by the Linux kernel

Well even the entire windows sits in a single git repo https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...

Re: Gitless: A simple version control system built on top of Git

#97
post #47
post #40

I feel like this is just another "git is hard so lets make it easier" program that makes collaborative development a pain. maybe its just my puritan work ethic. first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added cod…

Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hy…

"Didn't achieve its dominance based on technical superiority" - I partially disagree. Compared to SVN, Git was superior in multiple aspects. Perhaps it was not The VCS To End All VCSs, but lacked the annoying warts of CVS and SVN. (Mercurial does have some nice features, sure - but wasn't quite there when Git was on the up-and-up)

Re: Gitless: A simple version control system built on top of Git

#98
post #15

I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original cla…

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obvious…

My perspective is this. I am a quite experiance CNC operator and have used this particular model for over a decade. I don’t have a problem with it, even though I admit it took a bit of getting used to originally and I still agree that the controls aren’t intuitive, but that doesn’t matter to me cause I know them by heart... but now I’m running a shop with 5 other CNC operators who constantly break the machine and shut down work for trivial completely non problems like John used Peters Machine and now Peter is back so John is back on his own machine, suddenly none is able to turn on their machines so they’ve all started cutting out parts by hand. So I’m spending tons of time dealing with complete bullshit things that would not otherwise have been a problem had it not been for this particular brand of CNC. It doesn’t matter how well I personally know the machine, because the problem is that I’m now wasting my time trying to prevent them from wasting theirs. This is not a problem of inexperienced operators, it’s a problem with a machine that only works with the aid of a super-user, and which doesn’t easily show the path of how people should develop super-user abilities without breaking stuff and working really hard to understand what they broke and why before they can move on to fix it.

Thank god I’ve never had to deal with a CNC machine like that. But git is that machine.

Secretly I think this is the true reason for gits popularity. It’s like vim, a wonderful tool once you get past the first hill, but I would never force a whole team to use vim, I know it would be a disaster productivity wise. But because of gits popularity it is indeed forced on almost every developer.

Re: Gitless: A simple version control system built on top of Git

#99
post #84

Earlier quoted context omitted.

Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.

Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.

Branch seems to fit the dictionary definition: "something that extends from or enters into a main body or source". And in fact, it didn't originate with git, it's at least as old as CVS.

Re: Gitless: A simple version control system built on top of Git

#100
post #91

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…

I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally…

The model is fairly similar to CVS, which also keeps histories of files instead of a history of the repository. The ability to have half of your repository come from one "branch" and the other half from a different branch is actually seen as a feature. This enables workflows similar to what you can do with submodules in git.

Having to manage your config specs and the inability to go back to old versions of your software (or in fact just have something reproducible for your build servers) unless you meticulously label everything makes Clearcase of course barely useable. It gets extra interesting if you use multi-site Clearcase and your replicas stop synching.

Post reply on HN