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

71–80 of 105 posts

Re: Picturing Git: Conceptions and Misconceptions

#71

Post by globular-toast »

hanche wrote: post #34
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.

That reminds me about the old joke about monads: At the moment you finally understand them, you lose the ability to explain them. Seriously, I too find the basic concepts of git quite simple. But whenever I want to do anything slightly out of the ordinary, I find myself wasting a lot of time searching the docs. In fact, I find the naming of commands and their options almost the opposite of intuitive, given my underst…

I can't use the command line at all. It's horrendous and makes no sense. I use magit for everything if I can. If I can't then, like you, I have to spend ages searching the docs.

Re: Picturing Git: Conceptions and Misconceptions

#72

Post by cryptonector »

tempodox wrote: post #66
cryptonector wrote: post #59

Earlier quoted context omitted.

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.

Thanks!

It's simplified, but really, not that much.

Re: Picturing Git: Conceptions and Misconceptions

#73

Post by tharkun__ »

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…

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. I'm all for UIs doing auto add and commit -a equivalent by default. But do not take that ability away from me!

The list you provide sounded great until it came to gl switch. Why is there one specific operation for a branch that is NOT done via gl branch?

I don't understand what fuse is supposed to do from this at all. No idea whatsoever. Merge I get and anyone who has worked with any other versioning tool does conceptually.

Rebase most people seem to have a problem with but the abstract concept really isn't that hard. Just like cherry pick isn't really hard but somehow people have trouble with it. Though conceptually it really isn't hard either.

What really helped me the most with git was the realization that it's just a tree of commits with a bunch of labels. Labels have different types so to speak, like branch or tag, remote branches being special in a way etc. And obviously various commands can interact with these labels. Like a fetch updates the remote labels and moves them around on my local copy.

Re: Picturing Git: Conceptions and Misconceptions

#74

Post by squaresmile »

thewebcount wrote: post #41

> The problem with how people use Git, I’m suggesting, is that their analogical or metaphorical conception of Git doesn’t work — it doesn’t fit the way Git actually behaves — if, indeed, the conception exists at all. No, the problem is not with "how people use Git". The problem is with git. We've known for years how to make clear, concise interfaces that help people understand what's going to happen. Git does not hav…

Fwiw, I'm not sure if it's recent or not but git CLI has pretty good suggestion of what commands to run next. git status gives a decent amount of info. It also suggests the newer commands like switch or restore.

Re: Picturing Git: Conceptions and Misconceptions

#75

Post by alex_smart »

sagonar wrote: post #18
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.

If svn covers 99% of your use cases, then you need more experience with distributed version control systems. Able to commit locally, examine changes work with them and then push is a something you might not need or require if you think about version system like SVN. But if you have learned Git or Mercurial or some other distributed system you would never go back to svn.

I was molded in "git" way of thinking about version control, but I was forced to use SVN in a job. Not having local branches is not that bad. Like, people find ways to work around it: e.g. maintaining changesets in patch-files, or just keep multiple different checkouts.

Re: Picturing Git: Conceptions and Misconceptions

#76

Post by githubalphapapa »

Certhas wrote: post #68
zauguin wrote: post #38

Earlier quoted context omitted.

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

For example, did you clean up some comments and docstrings while you were adding a new feature? Commit those improvements separately, so that if you need to revert the feature commit later, the improvements won't also be reverted. It also makes reviewing much easier, as each commit or patch, having its own purpose, can easily be reviewed separately, and attention can be focused on parts that need changing.

> Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit.

Amending a commit does not serve the same purpose as staging files and hunks separately into the index.

It's my impression that few git users understand the value of the index, because few of them use porcelains that expose its power in simple ways. If I had only "git add -p" to use, I might not, either. But Magit is, well, like its name implies, like magic.

Re: Picturing Git: Conceptions and Misconceptions

#77

Post by recursive »

rendall wrote: post #35
Quenty wrote: post #11

Earlier quoted context omitted.

This article presents an accurate picture of how things work at a high conceptual level. It glosses over certain details, because git is very complex. For example, git has, if I recall correctly, 4 staging areas, of which represent different sources when it comes to a merge conflict. However, this detail can mostly be ignored because it’s not relevant to the high level conceptual ideas this article is trying to prese…

> However, this detail can mostly be ignored because it’s not relevant to the high level conceptual ideas this article is trying to present. Personally speaking, I find knowing and distinguishing among the 4 indexes to be essential to understanding git. Not including and really exploring that detail gives people an incorrect mental model of what's happening. Marvelous, if the metaphors of the article helped you, but…

The official documentation for `git add` refers to "the index". I'm not seeing any reference to multiple indexes. I've been using git for years, and I've never heard of it. I read a book about it. But parts of it are definitely still mysterious to me. Anyway, where can I find any evidence of these 4 indexes?

Re: Picturing Git: Conceptions and Misconceptions

#78

Post by recursive »

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…

I've been using the staging area for a long time. It only makes me wish I could turn it off.

Re: Picturing Git: Conceptions and Misconceptions

#79

Post by recursive »

cerved wrote: post #46
thewebcount wrote: post #41

> The problem with how people use Git, I’m suggesting, is that their analogical or metaphorical conception of Git doesn’t work — it doesn’t fit the way Git actually behaves — if, indeed, the conception exists at all. No, the problem is not with "how people use Git". The problem is with git. We've known for years how to make clear, concise interfaces that help people understand what's going to happen. Git does not hav…

git has a very clear, concise and stable interface if you understand how git works. it's designed this way, intentionally. people should stop complaining about it and either learn how to use it, switch to another tool or just write their own interface

It's not possible to switch to another tool unless you only ever work on code that you wrote, and never need to collaborate with anyone else.

Re: Picturing Git: Conceptions and Misconceptions

#80

Post by gmueckl »

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…

git is FUCKING HARD due to its tons of poorly designed misfeatures. The index/cache/staging area is the worst of them. If git wants to make any progress towards actual usability, this mess needs to be untangled with prejudice.

Other tools have none of this overly stateful bullshit. When I want a file to be included in the next commit, I don't want a silent, implicit copy to be whisked away into some interal storage the moment I flag it. There is NO reason why merges need to destroy the contents of that same storage area. The totally confusing semantics of the reset command with the three nonsensically named modes soft, mixed and hard are also created solely by this particular misfeature of a magical hidden storage area.

There is also no reason to even support destructive history editing. Immutable history is the correct choice. The mercurial evolve extension, for example, supports rebasing without destroying history.

Also, the combination of not being able to close branches instead of deleting them and not storing branch names in commits makes git history completely undecipherable when you have to go back more than a few merges. You might just as well throw it into the garbage bin.

Just take a look at competing tools (free and commercial) to see what's being innovated in this space and how this widespread obsession with git is in fact preventing much needed progress.

Post reply on HN