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

Gitless: a version control system

gitless.com

Post reply on HN
Print view View original

261–270 of 390 posts

Re: Gitless: a version control system

#261

Post by snoman »

chowells wrote: post #216
tree_of_item wrote: post #187

Earlier quoted context omitted.

> Git is, like many professional tools, something you simply got to learn. No. Why do people think "professional" has to mean "poorly designed"? But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.

"Professional" doesn't mean "Poorly designed". It means "designed so that people with lots of domain knowledge and experience with the tool find that it never gets in their way." In that sense, git is a professional tool. If you know everything about it, it doesn't get in your way. The problem is when you don't know everything about it..

The burden of having to know everything about it, is precisely what gets in your way. Granted, I use an actual tool (sourcetree) that abstracts away the BS that is the git commandline.

This idea that 'if you don't like the tool, it's because you're not good enough to use it, because you don't know everything about it' is elitist hokum.

Re: Gitless: a version control system

#262

Post by popmystack »

maker1138 wrote: post #230

I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging…

>I'm surprised at how many people are responding negatively to software that improves user experience.

At the cost of doing things technically correct.

Re: Gitless: a version control system

#263

Post by Certhas »

zajd wrote: post #181
Certhas wrote: post #166

Earlier quoted context omitted.

"It's really not though." That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power. Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws. And I don't work with programmers.

It's not an argument because that Koans article is horrible satire that people are trying to pass off as a legitimate argument. I detailed in my post one direct example as to why that post shouldn't be taken seriously. Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which cou…

It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion.

It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive:

http://gitless.com/#vs

If you want the detailed analysis of weaknesses of git that led to the design of gitless, it's here:

https://people.csail.mit.edu/sperezde/onward13.pdf

I don't necessarily agree with everything in there but I think it's an excellent analysis overall and worth reading as a case study anyways.

Re: Gitless: a version control system

#264

Post by bsder »

lbotos wrote: post #163
skybrian wrote: post #143

Earlier quoted context omitted.

I'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers? If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn…

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…

> Version control is arguably confusing for beginners

NO IT IS NOT. That kind of thinking is broken.

Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works.

As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it.

They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content.

Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken.

I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag."

And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week.

Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.

Re: Gitless: a version control system

#265

Post by laurentdc »

tadfisher wrote: post #246
nardi wrote: post #160

In this thread, lots of people wanting to demonstrate their deep knowledge of an arcane tool, thus proving the whole point.

Posted this upthread, but here's an apt Linus quote: > The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at…

That sounds like a very elitist approach. So the technology is good as long as it's arcane, but as soon as it becomes mainstream then it's "the beginning of the end"?

...do we even need a "reliable indicator of geek status"?

Re: Gitless: a version control system

#266

Post by loup-vaillant »

cm3 wrote: post #209
loup-vaillant wrote: post #205

Earlier quoted context omitted.

> running git-am on the isolated commit Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch). You wouldn't happen to try and save the state of one branch in the working copy, then using that…

I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.

Oh my, I was confusing git commit -am with git am. Didn't know about that last one.

Knowing that, it is very strange that the two methods should yield different results: the patch file is supposed to rely on a parent commit that should be accessible on the local repository, just like a local series of commits. That somehow the associated info/environment differs indicates there's a bug somewhere —or at least yet another poorly thought out corner of the UI.

Re: Gitless: a version control system

#267

Post by austinjp »

gnuvince wrote: post #235
maker1138 wrote: post #230

I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging…

I think the author address that point in the introduction: > Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws. Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must…

Indeed. Also known as "sunk cost fallacy".

Re: Gitless: a version control system

#268

Post by afro88 »

dahart wrote: post #93
whack wrote: 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…

> With git, I'm forced to either make an extraneous commit... You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing. > The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch I started a big ol thread on stash yesterday, but there are a bunch of s…

> You only need to commit or stash if there are conflicts

Unless you're wanting to take a look at the other branch clean, then you have to stash or do the extraneous commit. Most of the time I change branches to check someone else's work, or compare something that isn't working to develop/master. The stash/commit dance is a regular annoyance for me

Re: Gitless: a version control system

#269

Post by jrapdx3 »

X86BSD wrote: post #105

Git just is not my thing. I prefer Fossil SCM. Now that is a sweet little SCM.

I like Fossil too, and use it for many small projects. To some extent projects can be converted to/from git, but I haven't done much at all with that and I'm sure there are limits. Nonetheless, Fossil is an option with good usability that doesn't lock users in when there are reasons to convert repositories to other tools.

Re: Gitless: a version control system

#270

Post by varcharlie »

Do people really consider git hard to use? It's very easy to learn... In fact, if you can't learn git I would not be confident in your ability to learn any other important technology using the internet as your resource. You don't even need to have internet access as long as you have `man`.
Post reply on HN