Live data from Hacker News

Gitless: a version control system

gitless.com

151–160 of 390 posts

Re: Gitless: a version control system

#151
post #148

Earlier quoted context omitted.

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?

It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes.

The staging area is also known as the 'index' and the 'cache'.

(Git has a consistency-of-naming problem.)

Re: Gitless: a version control system

#152
post #68
post #57

Earlier quoted context omitted.

I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...

I disagree; `hg` is a CLI as well, but it's far simpler and safer than `git`. That said, I have far more experience with git than hg. Further, gitless itself is a cli, and it's also simpler than git.

I have experience with both daily, and I mostly just don't notice any meaningful difference. Especially with the bookmark extension.

Re: Gitless: a version control system

#153
post #68
post #57

Earlier quoted context omitted.

I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...

I disagree; `hg` is a CLI as well, but it's far simpler and safer than `git`. That said, I have far more experience with git than hg. Further, gitless itself is a cli, and it's also simpler than git.

[deleted]

Re: Gitless: a version control system

#154
post #43
post #30

Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…

Just use the normal git fallback command

[deleted]

Re: Gitless: a version control system

#155
post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

Whereas when people say they do like Git, I lose a little faith in them as a programmer and/or engineer. Because the only ways you could like Git are either to be so lazy and incurious as to be unfamiliar with the alternatives (Mercurial, and everything else that's come along since), or to have such bad judgment that you prefer Git to them.

Re: Gitless: a version control system

#156
post #2

See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git" https://news.ycombinator.com/item?id=12612333 (1 day ago, 106 comments)

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

How do you know that they misunderstand it, as opposed to disagree with it?

Re: Gitless: a version control system

#157
post #148

Earlier quoted context omitted.

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?

Please refer to the linked discussion. Various people ask about it and various people try to explain it (including me).

Re: Gitless: a version control system

#158
post #156

Earlier quoted context omitted.

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

How do you know that they misunderstand it, as opposed to disagree with it?

Please refer to the linked discussion.

Re: Gitless: a version control system

#159

Earlier quoted context omitted.

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users. The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. EDIT: editing this to expand on why I think the index is essential: Being able to use the VCS tool to fashion a commit se…

> it tries to hide the index and thus encourages bad habits in git users.

I'm curious what you mean by this. What are good & bad habits wrt the index?

It makes sense the index is there for conflict resolution, and it seems really convenient for interactive adds & rebases. But I could imagine implementing those things without having an explicit staging area. Are there other more important requirements for the index? It mostly seems like a convenience that it's exposed, but not something that provides either more safety or better practice.

Many VCSs that predate git don't have an index because they don't need one, and having one wouldn't encourage better habits. Git has an index and rebasing almost entirely as a result of it's strict enforcement of lineage, which older VCSs didn't have. In Perforce you can create and manage multiple changes before you push, and you can push them in any order. Because git enforces order, it basically needs rebase and an index to make using git sane. In that sense, these things can be seen as a UI disadvantage over other VCSs. Of course we know there are much bigger advantages that come with strict lineage, so we learn to stage, rebase, etc.

What other benefits does the index provide that I'm missing?

Post reply on HN