4 ms·

This is a much better post than the one that preceded it. Still... The biggest problem with people's attempts to wrap their heads around Git, its awful UI not

by cxr 3y ago

This is a much better post than the one that preceded it. Still... The biggest problem with people's attempts to wrap their heads around Git, its awful UI notwithstanding, seems to be an insistence on thinking of it foremost in terms of the experience of running any given command. I.e., trying to understand it from the outside in. Indeed, it's awful UI certainly hurts the process. Git's the stupid content tracker. Take a work consisting of a bunch of files, snapshot them, then create a new work (consisting of a lot of similar files, to be sure, but where others differ in some way). Git concerns itself with both of these collections as collections. It's true that it's got all this "branching" imagery, but that's an attempt to describe the relationships between the collections from the metadata attached to each one (collection 0ffcd473 calls collection f7d0c770 its parent). The branches are synthetic, imaginary. Not a lot different from a family tree or the "branches" you would get if you started mapping out the provenance of religious texts copied from another but each with their own copying errors (or deliberately editorialized content). The branches aren't really there—they exist as an aide for the researcher. The only real difference is that Git actually has explicit metadata, but still, the branches aren't there. Focusing on Git's on-disk representation or other internals misses the point. The main thing is getting the files in the collection you're putting together right now to look the way you intend right now. Everything else is recordkeeping. (At least it should be—anything (whether it be a given tool, workflow, etc) that depends on it being any more complicated than this is fundamentally broken.) Git's whole deal was about being an alternative to manually futzing around with tarballs and/or multiple directories of source code sitting next to each other on your disk. (It's still that, but with a somewhat involved—but not very interesting—deduplication scheme in userspace. The other details are even less interesting than that.)

happytoexplain 3y ago
IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command. Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format. So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.
- cxr 3y ago
  > in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can Sorry, I don't think that's compatible with reality at all. Too much experience with people clearly doing exactly that—frustrated people giving up, most often xkcd-style reset to the beginning—says otherwise. (And it's not just a matter of them existing. I'd wager this set probably accounts for the majority.)
  - happytoexplain 3y ago
    People of course give up on trying to grok complex programs like version control all the time, git included. (where "giving up" means just using the UI and trying to derive meaning from the results with the minimal goal of achieving one task at a time). But in my experience, fewer people give up on understanding git internals than comparably complex program internals. I.e. the second layer of understanding is more accessible in git than in other software, where people often don't even start trying to understand the second layer, much less make real progress with that understanding. Edit: Sorry if I am talking past any of your points - I'm not familiar with the XKCD comic you referenced.

by cxr 3y ago

happytoexplain 3y ago

IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command. Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format. So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.

cxr 3y ago
> in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can Sorry, I don't think that's compatible with reality at all. Too much experience with people clearly doing exactly that—frustrated people giving up, most often xkcd-style reset to the beginning—says otherwise. (And it's not just a matter of them existing. I'd wager this set probably accounts for the majority.)
- happytoexplain 3y ago
  People of course give up on trying to grok complex programs like version control all the time, git included. (where "giving up" means just using the UI and trying to derive meaning from the results with the minimal goal of achieving one task at a time). But in my experience, fewer people give up on understanding git internals than comparably complex program internals. I.e. the second layer of understanding is more accessible in git than in other software, where people often don't even start trying to understand the second layer, much less make real progress with that understanding. Edit: Sorry if I am talking past any of your points - I'm not familiar with the XKCD comic you referenced.