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

81–90 of 105 posts

Re: Picturing Git: Conceptions and Misconceptions

#81

Post by MathMonkeyMan »

tomxor wrote: post #57
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 don't really blame people, since git itself does nothing to teach you how it works. Git it is the definition of something you have to deal with in order to do something more important to you. Some people want to dig deep and understand how the system works: it's nice to sit near that person and ask them for help sometimes. The official git handbook, freely available on the official git-scm site is not terribly lo…

I was going to write a blog post conveying my mental model of what git is (having had one too many conversations along the lines of "no, git is not a ledger of diffs").

So, I started reading through https://git-scm.com/book/en/v2/Git-Internals-Git-Objects> again to make sure I didn't have anything wrong.

But now there's no point in writing a blog post. Maybe I'll write one that just links to https://git-scm.com/book/en/v2/Git-Internals-Git-Objects>.

It even has nice diagrams, which I think are essential for this kind of thing.

Re: Picturing Git: Conceptions and Misconceptions

#82

Post by lmm »

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…

I hate the inconsistency that stash brings, but gitless is useless since it destroys the primary use case for stashing: I start making changes and then realise I'm working on the wrong branch. Git's solution to the problem is awful, but it's better than nothing.

Re: Picturing Git: Conceptions and Misconceptions

#83

Post by OneEyedRobot »

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…

>Some people want to dig deep and understand how the system works

I'd say that's definitely the case but also a problem.

Sophisticated users mixed with people who just want to do a few simple things is a bad combination. I seem to remember that ClearCase had the same issues.

Re: Picturing Git: Conceptions and Misconceptions

#84

Post by dreamcompiler »

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…

The tax code is a completely inscrutable mess but git's internal model is one of the most simple and elegant structures in modern computer science. It's just covered over with utterly stupid commands and terminology that obscures the beauty of the underlying architecture.

I used to despise git because it was so hard to learn. Then as an exercise I started writing my own code to read and write its underlying files and it finally dawned on me how simple the whole thing was.

Git's a very unusual piece of software; it's mind-bogglingly useful, the basic data structures and algorithms are perfectly matched to its job, and it has a UI that's a train wreck.

Re: Picturing Git: Conceptions and Misconceptions

#85

Post by MathMonkeyMan »

MathMonkeyMan wrote: post #81
tomxor wrote: post #57

Earlier quoted context omitted.

> I don't really blame people, since git itself does nothing to teach you how it works. Git it is the definition of something you have to deal with in order to do something more important to you. Some people want to dig deep and understand how the system works: it's nice to sit near that person and ask them for help sometimes. The official git handbook, freely available on the official git-scm site is not terribly lo…

I was going to write a blog post conveying my mental model of what git is (having had one too many conversations along the lines of "no, git is not a ledger of diffs"). So, I started reading through https://git-scm.com/book/en/v2/Git-Internals-Git-Objects > again to make sure I didn't have anything wrong. But now there's no point in writing a blog post. Maybe I'll write one that just links to https://git-scm.com/book…

here: https://www.davidgoffredo.com/git

Re: Picturing Git: Conceptions and Misconceptions

#86

Post by mhh__ »

megous wrote: post #12
bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

Reminds me of: Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -Linus Torvalds Anyway, it's not for everyone to get to understand git this way, I guess. Some people will just react "just tell me how to do X in git!"

I work with some very good programmers who don't worry about code. Past a certain point it bites. You have to be thinking about scalability early so someone else doesn't have to refactor someone else's pride and joy because it's become full of overly concrete logic.

Re: Picturing Git: Conceptions and Misconceptions

#87

Post by mhh__ »

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

We do have regular humans using git internally - godsend for remote work. They manage fairly well because they don't really need to anything complicated.

There are some funny neologisms like "check it out on the git" since they don't know what git actually is Vs how to use it but still.

Re: Picturing Git: Conceptions and Misconceptions

#88

Post by Certhas »

githubalphapapa wrote: post #76
Certhas wrote: post #68

Earlier quoted context omitted.

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 accesse…

> 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. It's not a power-user feature, and it shouldn't be considered one. It should be taught as a standard part of any workflow: before committing, look at the changes you're about to add, and use hunk-staging features (e.g. trivial using Magit) to stage and commit unrelated ch…

gitless has the --partial flag that allows you to commit parts of files interactively.

And your workflow of gradually building up an index of (parts of) files can be achieved by partial/amendable commits. You simply iteratively/interactively add files and partial files to your latest commit until you're done. Instead of building up the index and then committing it, you just build up the commit directly.

This also means you can interact with the "in progress commit" in the same way as with all other commits.

There is no need for having an index to realize what you want.

Another minor point: Your workflow _is_ a power user workflow in my world. Out of twenty people that have reason to use git, one has use for this workflow.

It seems we roughly agree that there is a lot of scope for improving git though. I looked at magit and it looks nice. It exposes all the moving parts in a user interface. I would prefer to just have fewer moving parts, but if they are there it's sensible to make them obvious (and it puts to rest the idea that all you need to understand is that the git data structure is a DAG...)

Re: Picturing Git: Conceptions and Misconceptions

#89

Post by Certhas »

tharkun__ wrote: post #73
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…

In the same vein as my sibling but not repeating what he said I agree with him though, I regularly commit just specific files. I actually teach every GUI I use that comes with git integration NOT to Auto add and such nuisances. I use the command line and in probably 90% of cases a git commit -a is what I do. Another 5 is git add the entire directory tree I am in and the other 5 are specifically picking what to commit…

Did you actually look at the page the list is from? THis isn't some sketch, it's a fully implemented way of working with git repos that supports everything you ask for. Committing just specific files is done in gitless via

    gl commit a.foo b.bar
committing all but some files is done with

    gl commit -e a.foo b.bar
gl commit -p allows you to interactively commit parts of files.

gl doesn't take any abilities away (it's just git under the hood after all), it just exposes the abilities in sane ways.

If you actually look at the homepage of gitless you will also immediately see what fuse does:

https://gitless.com/#gl-fuse

I believe that by reading that one, not very long page, most people (including non-programmers) can use gl correctly most of the time. This is not the case for git.

BTW, gl branch is for creating/deleting branches, gl switch is for switching your working tree from one branch to another. These are very different things, why should they be under the same command?

For git, the last paragraph is a necessary but in no way sufficient step towards using it proficiently. Gitless is actually much closer to realizing that vision.

Seriously, people need to go back and teach beginners git to realize how bad it is. We have internalized so much of the bad design decisions in git that we don't notice them anymore.

Re: Picturing Git: Conceptions and Misconceptions

#90

Post by kjeetgill »

seoaeu wrote: post #61
paulddraper wrote: post #47

Earlier quoted context omitted.

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

I suspect it was added in an edit in response to this comment. Dad is downvoted!
Post reply on HN