Live data from Hacker News

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

gitless.com

31–40 of 143 posts

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

#31
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 obviously require a more complicated syntax and conceptual model.

In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant

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

#32

After reading the referenced papers explaining the academic rationale, Gitless gets a big "meh" from me. A quick tl;dr of the referenced paper "Purposes, Concepts, Misfits, and a Redesign of Git" ( https://spderosso.github.io/oopsla16.pdf ): > The changes made to Git’s concept model are: > 1. The redefinition of “tracked” and “untracked,” and the elimination of “assume unchanged” and the “staging area.” > 2. The rede…

Good points overall, I don’t disagree but I’ll try to give another POV.

I think the focus on stashing is that it’s basically an hidden state. If for instance you switch back to a branch after a while and you don’t remember you stashed, it will just be lost work. Overall I wish stashed were shown as candidate commits, I actually end up making temporary commits that I amend afterward, most of the time.

For the switching between branches during conflict resolution, it might be for people like me who check back and forth reference branches when merging code.

For instance a conflict can be between two feature branches I want to merge, and I’d need to check on master what is the current behavior. Or what’s the behavior on other branches that will need merging as well. Currently I’d just open github/gitlab on the other branches and compare from there, but I’d see the value in switching the local files.

All in all I feel git is too aggressive in making the user deal with all the details when it could have sane non destructive defaults

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

#33
post #9

Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff.

I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.

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

#34

Earlier quoted context omitted.

Can you elaborate on the deep problems? I personally find it relatively conceptually elegant.

I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.

Is OO simple ?

It is supposed to be, but I am not sure it delivers on that part. That’s another discussion, but for instance I wouldn’t bet on having a random 10 yo kid understand OO beyond the bare Cats and Dogs tutorial everyone goes through at first.

And that’s what I would say about git as well. Even after knowing the internals and how it is supposed to work, I still feel that for a tool it’s pretty unelegant and puts a significant burden on the user to know what needs to be done in what situations.

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

#35
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 a fair amount also. Plus, emacs is awsome :-P

[1] https://en.m.wikipedia.org/wiki/Rational_ClearCase

[2] https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility

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

#36
post #9

Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.

I split file changes into multiple commits all the time. That alone makes many diffs much more readable and changes easier to follow, even if it results in occasional git-log clutter.

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

#37
post #9

Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.

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

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

#38
I like the idea of working with the simple datastore of git - immutable objects pointing to each other - and manipulate them with a programming language.

But there's lots of things you routinely want to do that aren't convenient this way. Still has some appeal.

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

#39
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…

Conceptual problems themselves may be shallow, deep, or both. Wrapping machine code with assembly makes it easier to use but doesn't fix nasty issues with lack of memory boundaries.

Conceptually programmers having to mentally convert every line is poor ergonomics and will reduce speed and increase errors. Going to labels instead of numbers is an improvement even if shallow and able to improved upon further.

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

#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 code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding.

then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting.

finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?

Post reply on HN