Gitless: a version control system • Hacker News Board

Re: Gitless: a version control system

#291

Post by ubernostrum » Mon, Oct 03, 2016, 12:44 AM UTC

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..

In this sense, trivially, every tool is a "professional" tool, since if you just rote-memorize every aspect of it you know how to do everything it can do.

The problem with git is the lack of coherence in its default UI. Multiple ways to accomplish the same task, git commands which perform incredibly different functions depending on (invisible) context, inability to decide whether commands or flags should act as the highest-level switches...

It is simply the case that, no matter how beautifully and cleanly designed git's internals might be, the interface it presents to them has zero conceptual integrity.

Re: Gitless: a version control system

#292

Post by kasey_junk » Mon, Oct 03, 2016, 12:49 AM UTC

Grue3 wrote: post #194

kasey_junk wrote: post #138

Earlier quoted context omitted.

Hg is a very similar model to git but doesn't have the cli problems it does. Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does. But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting…

Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing. Dar…

My original comment was really hyperbolic as a response to the comment above, I don't actually think being pro-git is a sign of intellectual weakness.

That said, my main issue is that git is a good set of primitives for file change management. But its main design principles are not about SCM. It sacrifices ease of workflow for source control, in favor of making centralized maintainer worflows simpler. This is a perfectly fine trade off for a system largely optimized for a few linux kernel maintainers, dealing with lots of distributed and unorganized contributors (frequently over email).

Those same workflows are not necessarily the best way to organize a small (tens of developers) team with a linear history product.

Some time try to onboard a new-grad developer to a team like the former. You spend way more time explaining git internals and data structures than you do source control management. This just isn't true if you do the same thing with other source control systems. Its easier to explain TFS, SVN, hg, perforce or accurev (the systems I have actual working experience with) in every instance.

My opinion is, if bitbucket and github had switched business models early on (ie hg repos for free if they were public and git repos free for private repos) hg would have become the defacto standard. Its just much easier to work with for most development workflows.

Re: Gitless: a version control system

#293

Post by copperx » Mon, Oct 03, 2016, 1:11 AM UTC

matt4077 wrote: post #124

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

This is very close to the result of the study that was I believe he reason to write gitless: - Most people use git by learning a set of a few commands - A minority actually understands git on a deeper level But both groups form a mental model of how git works, and that model is apparently usually wrong, which results in those cases were you get stuck and just start with a fresh checkout and manually reapplying the ch…

If both groups get the mental model wrong, how can we ever hope to get it right? read the Git source code?

Re: Gitless: a version control system

#294

Post by yawaramin » Mon, Oct 03, 2016, 1:15 AM UTC

norswap wrote: post #139

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

I think git's concepts are simple and worth learning (unlike what the gitless people said). That being said, the command line interface is "meh" at best and full of byzantine options.

> I think git's concepts are simple and worth learning

For what purpose? The reason for using a VCS is to get your job done. If gitless does that, why should I need to learn the concepts of a content-addressable graph storage and traversal format?

Re: Gitless: a version control system

#295

Post by copperx » Mon, Oct 03, 2016, 1:17 AM UTC

redwall_hp wrote: post #290

nine_k wrote: post #271

Earlier quoted context omitted.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

Professional means it doesn't sacrifice functionality in favour of making things easy for newbies. This is a philosophy I approve of for all software. Vim is great because it offers power at the expense of having a little bit of a learning curve. A shell gives you unlimited power compare to a stripped down and locked down GUI. GUIs and "UX" are generally antithetical to making a computer do what it does best (automat…

> GUIs and "UX" are generally antithetical to making a computer do what it does best

I agree with you, but although CLIs are explicitly automatable, they are almost never are because most operations are one time deals. If you have evet set up a Linux server I think you'll understand what I mean. The CLI is also a usability nightmare with no discoverability.

Re: Gitless: a version control system

#296

Post by shinymark » Mon, Oct 03, 2016, 1:18 AM UTC

Drdrdrq wrote: post #233

lisper wrote: post #228

Earlier quoted context omitted.

Yes, all this is exactly my point. It is nearly impossible to explain the current git UI in a way that isn't embarrassing at best and wrong at worst. And then it's nearly impossible to remember. The number of things you actually want to do 90% of the time is small, so I think there is value in designing a veneer that makes that 90% easy to explain and remember.

Hg did that - unfortunately GitHub won over BitBucket, thus deciding the fate of Mercurial too.

I find Mercurial so much easier to use than Git. Many of the concepts are similar but the hg interface feels much easier to learn and use.

Re: Gitless: a version control system

#297

Post by GutenYe » Mon, Oct 03, 2016, 1:30 AM UTC

I like, just that python is slow.

Re: Gitless: a version control system

#298

Post by mitchty » Mon, Oct 03, 2016, 1:32 AM UTC

bsder wrote: post #257

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

> Git is, like many professional tools, something you simply got to learn. Or, you can use a tool that is built for purpose aka doesn't suck ). I don't use a Stanley #55 Plane to trim an edge even though it can. Mercurial, the author notes, doesn't have most of the pitfalls. Yes, everybody persists in using git because "Linus used it".

I persist in using git mostly because it doesn't also mean I need to have python installed everywhere.

I recognize this may be a minority reason, but that is a significant one. The rest amount to being able to rebase/reorder my commits.

At no point does "linus used it" factor in. What genuine technical points about git besides "doesn't suck" are you espousing as reasons I should switch?

Note, my workplace:

a: uses git

b: is about as likely to switch to hg as a pig would be to fly

c: follows linux upstream closely (we do kernel stuff)

I know of the following things that would be reasons to move to hg, however they're more in the "nice to have" rather than "need" category.

a: evolve extension

b: more consistent ui

If I were to list out all the cons for hg from my current perspective, here would be my top 5:

a: have to unlearn fetch/pull as they are not the same between tools, which is right is academic at this point

b: have to unlearn a lot of git use over the past 8 years, not against it but I need a good carrot to bother

c: now I have to install python on some low power systems, honestly this is dumb needing to install a scripting language just to use a VCS, and I use python daily, but its extra bloat that really shouldn't be needed.

d: last I looked (~6 months ago), i'd need to install extensions to recreate most of my workflow, again, this boils down to more effort than sticking with the status quo which by and large works out of the box.

e: would be nice if hg proponents would stop with the "git users are brain damaged by bad ui" posts, it honestly just makes me roll my eyes and move on, not rethink my position, SHOW ME WHY IT IS BETTER, stop berating as that isn't helping and at best is making me think people are treating VCS choice as a religion or political affiliation, which is easily dismissed and not at all worth my time to reply.

Re: Gitless: a version control system

#299

Post by foxylad » Mon, Oct 03, 2016, 1:36 AM UTC

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

Yep, that's pretty much my git repertoire! I would add branch and merge to this list - conceptually simple, but they add another dimension to version control.

Re: Gitless: a version control system

#300

Post by recursive » Mon, Oct 03, 2016, 1:39 AM UTC

erichocean wrote: post #241

recursive wrote: post #211

Earlier quoted context omitted.

I've been using git for a few years, and often wished I could eliminate the staging area. It's an extra step for every commit, and creates extra complexity for no benefit I've been able to see. I haven't seen a practical example of a use case that's improved by having separate add and commit. By your statement, I also completely misunderstand git. That's entirely possible, but if git is so hard to understand that dai…

> I haven't seen a practical example of a use case that's improved by having separate add and commit. Well, I frequently see random things to fix while I'm working on a problem. When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit. A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to th…

I do this kind of thing often too. To me this all seems like it could be handled at commit time. And more simply too.