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

Picturing Git: Conceptions and Misconceptions

biteinteractive.com

Post reply on HN
Print view View original

61–70 of 105 posts

Re: Picturing Git: Conceptions and Misconceptions

#61

Post by seoaeu »

paulddraper wrote: post #47
Certhas wrote: post #30

Earlier quoted context omitted.

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty…

> just demonstrates that the git interface is horribly broken This is HN criticism #94238 on the terrible git CLI. Okay, sure. Would you kindly post your superior git CLI? Or at least the outline of it? --- Snark aside, Git's popularity is not an accident. Bitbucket supported Mercurial too.

> Would you kindly post your superior git CLI? Or at least the outline of it?

You are literally replying to a comment that describes a possible better CLI for git...

Re: Picturing Git: Conceptions and Misconceptions

#62

Post by Buttons840 »

deckard1 wrote: post #50
jimbob45 wrote: post #5

Earlier quoted context omitted.

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained. Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every comman…

Early in my career I was a junior developer on a team using SVN. I knew git and used a git plugin that let it work with SVN. I would often talk about various branches and things I was doing locally in my repository and the other developers would get concerned, because making a branch is SVN is a big deal, and here I am, it seems, making tons of branches. It was fun because when I would finally upstream my work, it would dump a dozen commits into the SVN history all within the same second. It was kind of nice having the linear history forced by SVN though.

Re: Picturing Git: Conceptions and Misconceptions

#63

Post by jimbob45 »

deckard1 wrote: post #50
jimbob45 wrote: post #5

Earlier quoted context omitted.

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained. Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every comman…

>Once an SVN user discovers the magic of a staging area

You can already do that with TortoiseSVN or just through the cline

>stashes

SVN uses shelves

>git isn't hard

This feels like the "lisp is magic" argument that no one can seem to prove, despite how universal its proponents claim the law to be.

Re: Picturing Git: Conceptions and Misconceptions

#64

Post by shepherdjerred »

cerved wrote: post #48
shepherdjerred wrote: post #37

Earlier quoted context omitted.

Git is definitely not simple. It's simple if you have a solid understanding of data structures (trees, graphs), and know the concept of a pointer. Not everyone has that background. The concepts are learnable, but the commands have complex behavior that often require reference to use properly. The commands aren't simple by any measure because of all of the edge cases that exist.

it's almost as if git is a tool that was designed for software engineers and not accountants

Complexity should not be excused solely because the target audience is “smart” people.

Re: Picturing Git: Conceptions and Misconceptions

#65

Post by antman »

Certhas wrote: post #30
karaterobot wrote: post #2

I read most of this long article, and I found it useful, but: It's unsurprising that people's mental model of git is incorrect. Git is not something people study at a conceptual level, it's something they learn recipes for in order to work on some project. Recipes like "how do I save all this work I just did" and "oh shit, everything is hosed, please give me a magic spell I can paste into my terminal to fix it". I do…

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty…

    gl merge - merge the divergent changes of one branch onto another
    gl fuse - fuse the divergent changes of one branch onto another
Good while it lasted though

Re: Picturing Git: Conceptions and Misconceptions

#66

Post by tempodox »

cryptonector wrote: post #59
karaterobot wrote: post #2

I read most of this long article, and I found it useful, but: It's unsurprising that people's mental model of git is incorrect. Git is not something people study at a conceptual level, it's something they learn recipes for in order to work on some project. Recipes like "how do I save all this work I just did" and "oh shit, everything is hosed, please give me a magic spell I can paste into my terminal to fix it". I do…

I use this when I want to teach someone Git: https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...

I find that a good introduction.

“All operations on a repository involve adding commits and/or manipulating the name resolution table.”

It may be simplified, but that statement alone, taken in context, is worth its weight in gold.

Re: Picturing Git: Conceptions and Misconceptions

#67

Post by tempodox »

deckard1 wrote: post #50
jimbob45 wrote: post #5

Earlier quoted context omitted.

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained. Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every comman…

> that's just laughable considering SVN needs a central repo to work…

Do you use GitHub, GitLab, Bitbucket, gitea, ...? There's your central repo. If nothing else, it represents the “backup” facet of using an SCM.

Re: Picturing Git: Conceptions and Misconceptions

#68

Post by Certhas »

zauguin wrote: post #38
Certhas wrote: post #30

Earlier quoted context omitted.

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty…

Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a com…

Interesting. I haven't met many who have. Your two usecases basically never arose for me. If I switch back to a branch and there's random stuff there, then I can just revert easily. So it's an extra operation at a different time to get there. The other usecase for switching branches temporarily where it's one less command, is more important to me though. The crucial thing though is that both behaviours can be accessed easily but we are dealing with one less data store/stateful thing, because we don't need the stash.

As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit.

I wouldn't claim that gitless is a 100% complete git replacement for expert users. It just shows that git has way too much state exposed to users, and has confusing commands to make that state interact. Obviously we all learned git and use it successfully, so it's obviously not broken or anything, it's just worse than it could be (and the constant chorus of "it's so simple, just a DAG!" is a bit grating if you have to teach beginners regularly).

The gitless authors did do some research with users that backs up the claim that this is conceptually easier to use:

https://spderosso.github.io/oopsla16.pdf

Re: Picturing Git: Conceptions and Misconceptions

#70

Post by globular-toast »

Certhas wrote: post #25
globular-toast wrote: post #16

Earlier quoted context omitted.

This is the way I understand git. For me it's dead simple. I've tried to teach others over the years. Not a single person has got it so far.

So what's your conclusion from this failure? That everyone else is stupid? You're a bad teacher? Or it's not actually simple and the above explanation includes a ton of implicit understanding of the subtle interactions of the various moving parts?

For the majority of programmers I think it's lack of experience with data structures of any kind. C programmers have to understand pointers and most (I assume) would have implemented at the very least their own linked list at some point and maybe even a tree. But there are so many programmers who simply lack this experience so talk of pointers, links, graphs etc. is unfamiliar.

Then there are those whom I'm sure should have the necessary experience (because they are C programmers, for example), but still don't seem to get it. These people I think just don't care. They don't care about version control and therefore it's irrelevant what git is trying to represent. They just want to get their code merged.

Post reply on HN