6 ms·

You don't need to know this, by the way. You can totally just think of git as simply storing a copy of your entire repo every time you make a commit. This is on

You don't need to know this, by the way. You can totally just think of git as simply storing a copy of your entire repo every time you make a commit. This is one part of git that actually is a good abstraction. Of course it is fun to know this but it won't help you understand git really, and please don't tell people who are just learning git. Just say git makes a copy of the whole project every time you commit.

recursive 3y ago
"I don't commit that often because I don't have that much hard drive space."
- jxy 3y ago
  It's kind of true with git-lfs.
- mostlylurks 3y ago
  I wonder if anyone has built a system with the philosophy of the opposite extreme. "Oh yeah, space is cheap, so I just let my automated system make 10,000 commits per second. It'll be fine."
  - quickthrower2 3y ago
    I have been thinking about this. Why no record all keystrokes. Then checkpoint where you are whenever you desire. These days AI could describe any arbitrary span of code changes.
    - mikewarot 3y ago
      >Why not record all keystrokes? That was Google Wave, it stored everything as an "operational transform". The presentation they used when showing it off to the world was brain damaged, they insisted as showing it off as a ton of separate blocks, instead of one continuous document, which gave people the wrong impression of it, and tanked it. In a similar way, the impression that Git stores deltas, got stuck in my head somehow at the beginning and made it an opaque mystery for me. It was only years later, when I somehow I managed to learn the truth, that Git stores full snapshots, and except for compression in extreme cases to save storage, it doesn't do anything with deltas (except fake them to show diffs)
    - globular-toast 3y ago
      It's not quite "all keystrokes", but git-wip is meant to add a commit every time you save a file: https://github.com/bartman/git-wip https://github.com/bartman/git-wip I've been using this (via magit-wip) for a while now and it stays out of the way. I've never needed to use it, though. I'm probably too careful now having been trained in a world without git-wip.
      - tarsius 3y ago
        Magit stopped using the git-wip script ten years ago.
glhaynes 3y ago
I feel like git culture is one of the worst about these sorts of things. I've run into people that think you're a loser if you don't use it from the command line, but my commits using a GUI client are much cleaner and I seem to have much less trouble than they do.
- quickthrower2 3y ago
  I use command line for pull/push/new branch, VSCode for commits and Tortoise for archeology and merges. I just use whatever seems easiest for the task.
- poorlyknit 3y ago
  What GUI are you using and how do I make my commits cleaner?
  - globular-toast 3y ago
    I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane. A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit. With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
    - Vinnl 3y ago
      For those who do prefer the command line (you do you), what you want is git add --patch
solarkraft 3y ago
Yeah. I want to understand git. But by that I mean using it. I don't need to know about the internals for that; I need to know common approaches to typical merge problems (where all of a sudden git loses a lot of its elegance).
- visarga 3y ago
  I found out that GPT-4 is pretty good at helping me find/format git commands and solve git issues. These are usually short responses, repeated in many places on the web, and easy to memorise for the LLM. GPT is really a game changer related to git anxiety.

recursive 3y ago

"I don't commit that often because I don't have that much hard drive space."

jxy 3y ago
It's kind of true with git-lfs.
mostlylurks 3y ago
I wonder if anyone has built a system with the philosophy of the opposite extreme. "Oh yeah, space is cheap, so I just let my automated system make 10,000 commits per second. It'll be fine."
- quickthrower2 3y ago
  I have been thinking about this. Why no record all keystrokes. Then checkpoint where you are whenever you desire. These days AI could describe any arbitrary span of code changes.
  - mikewarot 3y ago
    >Why not record all keystrokes? That was Google Wave, it stored everything as an "operational transform". The presentation they used when showing it off to the world was brain damaged, they insisted as showing it off as a ton of separate blocks, instead of one continuous document, which gave people the wrong impression of it, and tanked it. In a similar way, the impression that Git stores deltas, got stuck in my head somehow at the beginning and made it an opaque mystery for me. It was only years later, when I somehow I managed to learn the truth, that Git stores full snapshots, and except for compression in extreme cases to save storage, it doesn't do anything with deltas (except fake them to show diffs)
  - globular-toast 3y ago
    It's not quite "all keystrokes", but git-wip is meant to add a commit every time you save a file: https://github.com/bartman/git-wip https://github.com/bartman/git-wip I've been using this (via magit-wip) for a while now and it stays out of the way. I've never needed to use it, though. I'm probably too careful now having been trained in a world without git-wip.
    - tarsius 3y ago
      Magit stopped using the git-wip script ten years ago.

glhaynes 3y ago

I feel like git culture is one of the worst about these sorts of things. I've run into people that think you're a loser if you don't use it from the command line, but my commits using a GUI client are much cleaner and I seem to have much less trouble than they do.

quickthrower2 3y ago
I use command line for pull/push/new branch, VSCode for commits and Tortoise for archeology and merges. I just use whatever seems easiest for the task.
poorlyknit 3y ago
What GUI are you using and how do I make my commits cleaner?
- globular-toast 3y ago
  I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane. A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit. With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
  - Vinnl 3y ago
    For those who do prefer the command line (you do you), what you want is git add --patch

solarkraft 3y ago

Yeah. I want to understand git. But by that I mean using it. I don't need to know about the internals for that; I need to know common approaches to typical merge problems (where all of a sudden git loses a lot of its elegance).

visarga 3y ago
I found out that GPT-4 is pretty good at helping me find/format git commands and solve git issues. These are usually short responses, repeated in many places on the web, and easy to memorise for the LLM. GPT is really a game changer related to git anxiety.