9 ms·

I know (or, at least, have known) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a

I know (or, at least, have known) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the commands often enough to remember that information.

Filligree 5y ago
Take a look at https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/? Maybe you've already read it, but this is what let me grok the underlying data.
- cxr 5y ago
  The parent commenter makes it clear that they already grok the underlying data. The problem with Git, as explained so, so many times, is its horribly intuitive mapping from UI to the operations those commands preform on that model. Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be concerned with with people who don't understand the underlying data model. When you been through this enough times, it just comes off as incredibly annoying and a source of tiresomeness.
  - moby_click 5y ago
    I often come back to a local repository to change something and think, while I'm at it, I'll just `git pull` and end up with a non-working working directory. Surely I should know better, but I think it's also hostile to users, when the easy thing to do is often the wrong thing to do. Even worse, I'm not sure I correctly remembered the weird combination of actions and flags to use to get back to the state where I can continue with what I wanted to do in the first place. That article is a good example of the problem. It tells me `git rebase` is an easy thing to do but I better not use that distributed VCS to publish my work that way, where 'publish' probably also applies to different machines of mine.
  - DemocracyFTW 5y ago
    But... a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor ... so what is the problem? /s
- romwell 5y ago
  I think the parent commenter says that they do understand the underlying data. It's just that the command-line interface is very opaque regarding what it does to that data. For instance, say I want to apply the last three commits I made in one branch to another branch. It's a very simple operation conceptually. Good luck remembering that the command that does it is rebase, and what the arguments for it are.
dheera 5y ago
Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?
- handrous 5y ago
  > And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.
  - lamontcg 5y ago
    I guess I have `git pull --rebase` as muscle memory. I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull` Or: > git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD' From: https://github.com/JKrag/git-up https://github.com/JKrag/git-up
    - deleted 5y ago
      [deleted]
    - rjmunro 5y ago
      git config --global pull.rebase true You probably also want: git config --global rebase.autostash true
    - deleted 5y ago
      [deleted]
  - funkymike 5y ago
    I have this in my .gitconfig so the pull will fail rather than merge. [pull] ff = only If it does fail I can decide whether to merge or rebase.
stormbrew 5y ago
definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin master` but when you want to interact with that remote branch otherwise it's `origin/master` instead. The lack of clarity is in what commands operate on what levels, with many of them operating on several at once. There have been some efforts to reform the command set to be more clear, like `git switch`, but the old commands will persist forever along with a lot of other footguns (like `git push --force` really ought to be replaced with `git push --force-with-lease` and moved to `git push --force-I-really-mean-it` so it hardly matters.
- fierro 5y ago
  can you explain the `git pull origin master` thing one more time here?
  - stormbrew 5y ago
    like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/` (or really `refs/heads/origin/`) is just a cached pointer to the last known state of that ref on the remote. All other commands operate only on these local references. So when you want to refer to what you know to be the state of things on `origin`, you can use `origin/master`. Otherwise that command has no particular knowledge of how to talk to origin. Incidentally this is a shortcut I use all the time to update my local master from a remote: `git fetch origin master:master` Which is super unclear in its meaning but it means fetch origin's master HEAD and put it in my local master ref. I actually use this more often than git pull nowadays.
    - deleted 5y ago
      [deleted]
skeeter2020 5y ago
YES! you learn the happy-path commands you use all the time and the handful of "sadder-path" approaches you try when things go south, but there is a dramatic fall-off in knowledge and understanding from there that leaves otherwise clever and confident people feeling stupid and frustrated. This is not a silver-bullet for productivity but still a very worthy problem to address that could have meaningful impact for a lot of people.
Vinnl 5y ago
I'm the same, but I think that's... Fine? If I understand what I want to do in terms of first principles, there's no harm in searching for the exact incantation if I do that only once every few months. For the rest, there's shell autocomplete and muscle memory.
anoncake 5y ago
Maybe for low-level, somewhat rare tasks the ideal Git porcelain would be a GUI that just exposes the data model directly.
- thrashh 5y ago
  SmartGit is pretty good. It's $70/yr though (but well worth it IMO) I'm the guy people go to fix Git screw ups at my jobs but I just click a few buttons or drag a few commits...
zoomablemind 5y ago
I wonder should Undo as a concept apply to all Git actions/commans which have state side-effects on the repo or work dir OR should Undo only cover certain operations (which ones)?
Thorentis 5y ago
I think it's because the commands are poorly named. "Reset" vs. "Revert" tells me nothing about what is happening at the low level, I just have to remember it. And yet the two operations, despite having fairly similar English language meanings, have entirely different meanings in the context of Git.
fisherjeff 5y ago
YES! It always seems like people’s issues are handwaved away with something like “oh you just need to understand the underlying data structures better.” No, the UX is often very bad! Like, I know exactly what I want the underlying repo to do, but how the hell am I supposed to remember which —-option of which command is going to do that thing?

Filligree 5y ago

Take a look at https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/? Maybe you've already read it, but this is what let me grok the underlying data.

cxr 5y ago
The parent commenter makes it clear that they already grok the underlying data. The problem with Git, as explained so, so many times, is its horribly intuitive mapping from UI to the operations those commands preform on that model. Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be concerned with with people who don't understand the underlying data model. When you been through this enough times, it just comes off as incredibly annoying and a source of tiresomeness.
- moby_click 5y ago
  I often come back to a local repository to change something and think, while I'm at it, I'll just `git pull` and end up with a non-working working directory. Surely I should know better, but I think it's also hostile to users, when the easy thing to do is often the wrong thing to do. Even worse, I'm not sure I correctly remembered the weird combination of actions and flags to use to get back to the state where I can continue with what I wanted to do in the first place. That article is a good example of the problem. It tells me `git rebase` is an easy thing to do but I better not use that distributed VCS to publish my work that way, where 'publish' probably also applies to different machines of mine.
- DemocracyFTW 5y ago
  But... a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor ... so what is the problem? /s
romwell 5y ago
I think the parent commenter says that they do understand the underlying data. It's just that the command-line interface is very opaque regarding what it does to that data. For instance, say I want to apply the last three commits I made in one branch to another branch. It's a very simple operation conceptually. Good luck remembering that the command that does it is rebase, and what the arguments for it are.

dheera 5y ago

Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

handrous 5y ago
> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.
- lamontcg 5y ago
  I guess I have `git pull --rebase` as muscle memory. I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull` Or: > git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD' From: https://github.com/JKrag/git-up https://github.com/JKrag/git-up
  - deleted 5y ago
    [deleted]
  - rjmunro 5y ago
    git config --global pull.rebase true You probably also want: git config --global rebase.autostash true
  - deleted 5y ago
    [deleted]
- funkymike 5y ago
  I have this in my .gitconfig so the pull will fail rather than merge. [pull] ff = only If it does fail I can decide whether to merge or rebase.

stormbrew 5y ago

definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin master` but when you want to interact with that remote branch otherwise it's `origin/master` instead. The lack of clarity is in what commands operate on what levels, with many of them operating on several at once. There have been some efforts to reform the command set to be more clear, like `git switch`, but the old commands will persist forever along with a lot of other footguns (like `git push --force` really ought to be replaced with `git push --force-with-lease` and moved to `git push --force-I-really-mean-it` so it hardly matters.

fierro 5y ago
can you explain the `git pull origin master` thing one more time here?
- stormbrew 5y ago
  like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/` (or really `refs/heads/origin/`) is just a cached pointer to the last known state of that ref on the remote. All other commands operate only on these local references. So when you want to refer to what you know to be the state of things on `origin`, you can use `origin/master`. Otherwise that command has no particular knowledge of how to talk to origin. Incidentally this is a shortcut I use all the time to update my local master from a remote: `git fetch origin master:master` Which is super unclear in its meaning but it means fetch origin's master HEAD and put it in my local master ref. I actually use this more often than git pull nowadays.
  - deleted 5y ago
    [deleted]

skeeter2020 5y ago

YES! you learn the happy-path commands you use all the time and the handful of "sadder-path" approaches you try when things go south, but there is a dramatic fall-off in knowledge and understanding from there that leaves otherwise clever and confident people feeling stupid and frustrated. This is not a silver-bullet for productivity but still a very worthy problem to address that could have meaningful impact for a lot of people.

Vinnl 5y ago

I'm the same, but I think that's... Fine? If I understand what I want to do in terms of first principles, there's no harm in searching for the exact incantation if I do that only once every few months. For the rest, there's shell autocomplete and muscle memory.

anoncake 5y ago

Maybe for low-level, somewhat rare tasks the ideal Git porcelain would be a GUI that just exposes the data model directly.

thrashh 5y ago
SmartGit is pretty good. It's $70/yr though (but well worth it IMO) I'm the guy people go to fix Git screw ups at my jobs but I just click a few buttons or drag a few commits...

zoomablemind 5y ago

I wonder should Undo as a concept apply to all Git actions/commans which have state side-effects on the repo or work dir OR should Undo only cover certain operations (which ones)?

Thorentis 5y ago

I think it's because the commands are poorly named. "Reset" vs. "Revert" tells me nothing about what is happening at the low level, I just have to remember it. And yet the two operations, despite having fairly similar English language meanings, have entirely different meanings in the context of Git.

fisherjeff 5y ago

YES! It always seems like people’s issues are handwaved away with something like “oh you just need to understand the underlying data structures better.” No, the UX is often very bad! Like, I know exactly what I want the underlying repo to do, but how the hell am I supposed to remember which —-option of which command is going to do that thing?