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

91–100 of 105 posts

Re: Picturing Git: Conceptions and Misconceptions

#91

Post by rendall »

recursive wrote: post #77
rendall wrote: post #35

Earlier quoted context omitted.

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

Sorry, category error. I was using index to refer to the category of which index is a member. Maybe areas is better. These are the 4 ... things...:

working directory - this is the project directory in the OS file structure

index - a.k.a the staging area

repository - in the .git directory

stash - a kind of scratch pad or clipboard for the developer

Understanding these different areas and how and why to move data into each is essential to understanding git

Re: Picturing Git: Conceptions and Misconceptions

#92

Post by spinitch »

antman wrote: post #65
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…

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

Yup. That was exactly the point at which the commenter's promise of "just look at a summary of the commands, you will have an accurate mental model of what's going on" break down for me.

Re: Picturing Git: Conceptions and Misconceptions

#93

Post by Quenty »

rendall wrote: post #91
recursive wrote: post #77

Earlier quoted context omitted.

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?

Sorry, category error. I was using index to refer to the category of which index is a member. Maybe areas is better. These are the 4 ... things... : working directory - this is the project directory in the OS file structure index - a.k.a the staging area repository - in the .git directory stash - a kind of scratch pad or clipboard for the developer Understanding these different areas and how and why to move data into…

While you are correct, this is not what I was referring to.

To be exactly clear, there are actually 4 staging areas within what you referenced as the index. This is indeed a detail most people do not worry about.

Re: Picturing Git: Conceptions and Misconceptions

#94

Post by sigjuice »

Certhas wrote: post #22
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…

Sorry, but what? Specifically: what about your writing justifies the assertion that git is simple? Git is a horrible convoluted set of commands to make a lot of different data structures [1] interact. And if you do it wrong you can get into very weird states. This is not simple in any meaningful sense of the word! Heck, "a monoid in the category of endofunctors" is simpler. [1] From the top of my head: The working tr…

Agreed. I have a couple of things to make my life slightly easier.

I could never understand what kind of twilight zone stashes go into or remember which stash is which when I had too many of them. So I never use stashes any more, I just make a branch instead.

I largely use git add -A, so I can pretend that the index does not exist.

Re: Picturing Git: Conceptions and Misconceptions

#95

Post by tharkun__ »

Certhas wrote: post #89
tharkun__ wrote: post #73

Earlier quoted context omitted.

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

No I did specifically not go to the gitless site because apparently I was supposed to understand it just from the list given in the post. Which isn't true.

I understand what gl branch "is supposed to do" but I don't see why gl switch is its own command given the other reasoning presented for why gl "is better".

I would say it is different. Probably very workable. Completely intuitive and the only reasonable way to do version control? Definitely not.

To me it's very very natural that git checkout will check out any commit I give it. How I specify that commit is up to me. It could be the commit hash. It could be a text label. That text label might on a logical level be a branch. Or a tag. Why do I need to switch branches with a special switch command when checkout handles this perfectly well?

Re: Picturing Git: Conceptions and Misconceptions

#96

Post by jatone »

gmueckl wrote: post #80
deckard1 wrote: post #50

Earlier quoted context omitted.

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

tl;dr; a monkey is given a hammer and is baffled by utility.

rofl. git is perfectly usable. proven by the hundreds of thousands of people using it daily. most of your 'complaints' here are not actually how git works in reality, and are just user error due to not bothering to learn the tool.

1. git never destroys your work inside a repository unless you told it to.

2. git doesn't 'whisk' things away implicitly. you committed them, that's pretty fucking explicit.

3. ummm every version control is stateful. wtf do you think any given version is? its fucking state. SVN has internal state, git, hg, fossil....

4. the commands, sure naming is fucking HARD we know this. we also know git gained different features over time to accommodate different workflows. perfect? absolutely not but a rose by any other name would smell as sweet.

Re: Picturing Git: Conceptions and Misconceptions

#97

Post by jatone »

recursive wrote: post #79
cerved wrote: post #46

Earlier quoted context omitted.

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.

no, its absolutely possible, as demonstrated by the numerous repositories that switched from cvs and svn to git. what you describe is a lack of desire to switch to another tool by your coworkers because you've been unable to make an adequate case for doing so.

Re: Picturing Git: Conceptions and Misconceptions

#98

Post by jatone »

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…

then feel free to build that tool on top of git. nothing is stopping you, given the existence of such tools today.

Re: Picturing Git: Conceptions and Misconceptions

#99

Post by nayuki »

petepete wrote: post #43
BossingAround wrote: post #40

Earlier quoted context omitted.

I've never used SVN, but I assume that because git uniformly won as the VCS tool, it suits most people better than SVN..?

The reason git won was in part due to the success of GitHub. It was the first code sharing platform that wasn't a crap. Once open source projects started moving to it from older platforms (Sourceforge, Trac, etc), developers who might not have cared so much about VCS flavours followed.

In turn, I think GitHub won because of Git.

Centralized version control systems like Subversion are oriented around "committer permissions". Giving someone commit access incurs friction (waiting for a human to respond) and risk (potentially unwanted changes).

None of the old platforms like SourceForge implemented the concept of cloning a whole repository. Even if you made your own clone (manually or otherwise), what good would that do? Your copy would diverge from the upstream and can never be automatically reconciled. You would be forever doomed to sending patches to upstream, and calculating diffs from upstream to apply to your repo. Or just replacing your clone with the upstream's history after your patch gets accepted.

Git natively supports multiple asynchronous repos representing the same "project" because its history is designed around a directed acyclic graph (DAG) structure. You don't need the upstream repo's permission to make your own clone and commit some changes. After you diverge from the upstream, if you solicit them with your branch and they accept, then both of you can converge once again - whereas this is impossible in a linear history model like SVN.

Re: Picturing Git: Conceptions and Misconceptions

#100

Post by Certhas »

tharkun__ wrote: post #95
Certhas wrote: post #89

Earlier quoted context omitted.

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

No I did specifically not go to the gitless site because apparently I was supposed to understand it just from the list given in the post. Which isn't true. I understand what gl branch "is supposed to do" but I don't see why gl switch is its own command given the other reasoning presented for why gl "is better". I would say it is different. Probably very workable. Completely intuitive and the only reasonable way to do…

Everything is perfectly logical after you get used to it enough.

And no, my post did not say that you will understand the details of every command in the list from just looking at the list. It only said that the list demonstrates that a much more coherent, less stateful, simply better UI is possible. That you can not fully explain the difference of fuse and merge in one sentence summaries is not a counterexample to that.

I said you will have an accurate mental model of what's going on. From the summaries you can tell all state you interact with: Working Tree, Commits, Track/Untrack status. That's it. That mental model is perfectly sufficient to accurately predict what most anything will do. And crucially the explanations and mechanisms to achieve all the workflows people asked for in this comment thread can be achieved with these ingredients just fine.

It's what the "Git is easy! You just need to understand that it's a DAG!" crowd pretends git already is.

Post reply on HN