11 ms·

Learn the workings of Git, not just the commands (2015)

130 points by philonoist 5y ago

aasasd 5y ago
Pffft, as if anyone actually could just use Git commands without learning the internals.
zelphirkalt 5y ago
In my experience it is fine to first learn only some required commands. One will run into cases, where ones understanding or imagination of how git works will not work any longer. In such cases one can still read up on how it works and build a new working understanding. Only important to not always just shrug, delete the repo and clone again. That will not really facilitate learning. Of course no one is stopping anyone interested in it from reading more about how it works up front.
- taubek 5y ago
  I'm new to git. For now I use it from VSC, but I should probably give CLI a chance. I must admit that I'm at the point where I shrug, delete and clone the repo if I'm stuck. Some errors and messages were to cryptic to me.
- wmf 5y ago
  This usually leads to "my shit's due in an hour, my repo is totally broken and I have no idea why... HEEEEELP".
throw0101a 5y ago
It's been over a decade and I still find this joke amusing: > @wilshipley git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217 (It's a 'spoof' on the Monad joke.)
- zibzab 5y ago
  Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)
  - recursive 5y ago
    We can stop with these comments after another system displaces git as the dominant player.
    - deleted 5y ago
      [deleted]
  - dogleash 5y ago
    >Why... Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a steep learning curve before you can half-ass it. Depending on perspective this is either a damning indictment of git, or just another day at the office. I've been helping people learn git for over a decade now. Unironically the easiest to teach are interns.
    - dmz73 5y ago
      I am using git as a version control system via Tortoise GIT which does a great job of exposing the minimum required functionality of git (maybe a bit more than minimum) and it is only when something goes wrong or I need advanced features that I have to fall back on git command line. So 99.99% of the time I use 10% of git functionality. Even if I did learn all of git (and I doubt there are many people that can make that claim), I would probably forget most of it by the next time I needed to use a particular feature. The main thing that should be explained at the start of any git related tutorial is how git handles the full workflow (from remote to local to work copy and back) because that is one thing that is missing but once you know it the rest becomes easy to understand.
kwertyoowiyop 5y ago
“You need to use git diff --cached to see what is actually in the index: the staged changes.” Like LOTR, everyone has more than one name.
delecti 5y ago
Understanding what git is doing under the hood did more for my ability to use it effectively than it did for most tools. That said, this document in particular does not seem to be a very good way to get that understanding, it's a very "IBM documentation" way of presenting git. I wish I remembered what I read, because it's was a much easier read.
- boppo1 5y ago
  Maybe the git man pages? Iirc the man pages have 2 or 3 'getting started' documents that really made me feel confident. Then I didn't use it for two years and now it's real fuzzy again.
- wmanley 5y ago
  For me it was "Git for Computer Scientists": https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/
- pwitvoet 5y ago
  Perhaps it was Pro Git's chapter 10: Git Internals(1)? I once used it as a guide when writing a basic 'git inspection' tool and definitely found the whole experience useful for getting a better understanding of Git. 1) https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
- jpindar 5y ago
  I found the Git section of "The Missing Semester of Your CS Education" to be helpful.
  - nereye 5y ago
    Seconded, here is the link: https://www.youtube.com/watch?v=2sjqTHE0zok https://www.youtube.com/watch?v=2sjqTHE0zok.
speed_spread 5y ago
Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.
- aequitas 5y ago
  You mean like: https://gitless.com https://gitless.com
  - martinvonz 5y ago
    Or my own project: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. I think https://github.com/Byron/gitoxide https://github.com/Byron/gitoxide also plans to provide a different CLI, but I don't think they've started working on it.
- pfarrell 5y ago
  Poe's Law is getting me on your comment. If it wasn't sarcasm, what's an example of a weakness? IMHO, there's a learning curve to using git and especially getting to the point where you can be your team's go-to person for git questions. However, I hold the opinion that of the many technologies out there, git is among those that is worth any investment you can make in learning it. Personally, long term use of git has affected the way I code to bring more intention and organization to what I'm doing.
  - _dain_ 5y ago
    quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.
    - zibzab 5y ago
      But are these things a normal user would need to care about? I bet if you created a great git desktop app with outstanding UI it would still have a few corners 99% of users would never touch or understand.
DarkWiiPlayer 5y ago
The important thing to understand is that git is a blockchain
- globular-toast 5y ago
  It goes a lot further than just being a blockchain. Git is a DAG through and through. But this might actually be the best way to make some people understand it. I was gobsmacked one day when a colleague came into work and they were really excited as they'd realised git is actually a blockchain. I was stunned as it seemed so obvious, but if they only just realised then how had we been working successfully with git for so long?
  - cryptonector 5y ago
    A blockchain is one linear branch. Git is just a tree of them, but they're all blockchains. The only other extremely important thing to understand about Git is that it has a way to name commits symbolically (branches and tags), and that those names can be changed, and that leads to understanding what a fast-forward and non-fast-forward change to a branch really is.
- kwertyoowiyop 5y ago
  So each commit is an NFT. Now, where’s my million dollars?
- deleted 5y ago
  [deleted]
erwincoumans 5y ago
"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)
- globular-toast 5y ago
  "Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?
  - erwincoumans 5y ago
    Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.
    - globular-toast 5y ago
      You misunderstand. Do you think I was born understanding how git works? I've messed up at least as much as you, but I spent the time learning how it works rather than going nuclear and deleting the repository. I can't relate to how you think about git because it's been too long for me, that's why I asked if you could explain it from your point of view.
      - seized 5y ago
zibzab 5y ago
A mucher better explanation of git interals: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It is surprisingly simple and efficient. I am starting to think this Linus guy knows what he is doing.
- balefrost 5y ago
  I still very much recommend the Peepcode Git Internals book. https://github.com/pluralsight/git-internals-pdf/releases https://github.com/pluralsight/git-internals-pdf/releases
- kwertyoowiyop 5y ago
  He offloaded the complexity to its users! :-) If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.
  - gjvc 5y ago
    Complexity is unavoidable in the long run, but must be engineered out in the short run.
  - torstenvl 5y ago
    > If the command and option names had just been sensible Holy shit, yes. `git branch` in gitspeak really means `git branch list` in human-readable CLI But `git branch ${NAME}` does not mean `git branch list ${NAME}`, instead it means `git branch create ${NAME}` There is no `git branch switch ${NAME}` but instead it's `git checkout ${NAME}` There is no `git branch log` – that would be `git log`, whereas if you want what should be `git log` what you really want is `git log --all` Don't get me started on whether modified files are added, staged, or indexed...
    - kwertyoowiyop 5y ago
      They are added, staged, indexed, AND cached!
NalNezumi 5y ago
I like the attitude of "learn the principles of the simple building blocks behind it" as a good next step from a freshman that just memorized "add, commit & pull/push" But most headache (and heartattack) inducing part of Git when I was a beginner was the "remote vs local repo" and additional complexities this concept introduced. Nothing more stressing for the new guy than making mistakes that screw up for others (mistakeful push, merge, mostly ) or if he think he did. The article does a poor job (imo) regarding this. It skims on a 2 paragraph "Caveat" section how rebase(and later squeeze) can fuck local vs remote repo, but for most people I know, stress memories around this is what made them learn more about Git beyond than "branch & history keeping software & commands. That and if you unfortunately end up in a project that uses subtree or submodules
nyellin 5y ago
There is a great tutorial which teaches git internals by implementing git in python: https://www.leshenko.net/p/ugit/ https://www.leshenko.net/p/ugit/
pjam 5y ago
Feeling required to post about the Building Git[1] book, really love it, for anyone interested in a walkthrough of rebuilding many of the most of important git features, from scratch, in ruby. [1]: https://shop.jcoglan.com/building-git/ https://shop.jcoglan.com/building-git/
enriquto 5y ago
As much as I love and depend on git, the visible user interface seems a bit ugly. You can get used to it over time, but it has a certain non-unix flavor that I dislike... There should be a purely unix way to use git, as in "everything is a file". Sure, you can go to the .git folder and there are files in there. But the structure of these files does not directly represent the structure of the repository. What I want is to "mount" a git repository, so that I can explore its contents using cd, ls and cat. Also, by editing these files I implicitly make commits and create branches to the underlying structure. Would that even be possible? EDIT: A disturbing feature that I don't see a way out is that in git there are "standard" and "history-rewriting" operations, and there is a clear distinction between the two. To what would that correspond in terms of pure file operations? Something about changing the default permissions?
- mikewarot 5y ago
  If I might offer a suggestion, instead of using various git commands, you want to be able to just cp a folder to a mounted git folder, and echo the commit message to a .commitmsg in that folder, or something like that, right?
  - enriquto 5y ago
    Yes, but not only that, I want a folder for each commit, with all the files inside it, including a .commitmsg file with each log message. Thus "git log" could be implemented as cat `find . | grep commitmsg` More interestingly, it would be able to grep around all previous versions of the files.
- cryptonector 5y ago
  > A disturbing feature that I don't see a way out is that in git there are "standard" and "history-rewriting" operations, and there is a clear distinction between the two. To what would that correspond in terms of pure file operations? Something about changing the default permissions? > "history-rewriting" operations Git is a Merkle hash tree. You can never rewrite history. Instead, what you think of as "history-rewriting" operations is just "non-fast-forward" changes to branches. Branches are really just named pointers -- {branch_name, commit_hash}. A change to branch from {$name, $commit0} to {$name, $commit1} is fast-forward IFF $commit0 appears in the linear history of $commit1. A non-fast-forward change to a branch is what you call a "history-rewriting" operation. There's nothing wrong with "history-rewriting" -- I do it all the time. It's only ever bad when you do a non-fast-forward push to a branch that others track, and even then it's not the end of the world because usually those others can recover easily enough with `git rebase --onto`. Rewriting the history of a public branch is a problem, yes, because you want the history to be stable and reliable so you can use it to figure out problems, understand the history of the project, etc, and because making others have to `git rebase --onto` is impolite. It's essential to understand that the only destructive operations in git are a) non-fast-forward branch changes, b) tag changes, c) gc/prune operations when you're like me and you're used to working in detached-HEAD mode. If you're stuck on "Git has history rewriting, and that's bad!", then you've misunderstood everything about modern version control systems. You can -and I have- do the same sorts of destructive operations in version control systems going back to the early 90s (e.g., Teamware, CVS), to say nothing of newer ones like Mercurial, Fossil, and, of course, Git. Inb4 "But Git encourages history rewriting" -- that is neither true nor a good argument.
glynnormington 5y ago
Excellent! Two updates since it was written: use main rather than master for the default branch; use git switch to change or create branches.
zoomablemind 5y ago
As a user, I see absolutely no reason to know the internal workings of Git. It supposedly offers a service, which is tracking and recording changes to files. In a way, it's a very able SaveAs/Open command and also offering some way of altering the recorded history. How it's done internally, as much as it's remarkable, is just an implementation detail. The fact that users are repeatedly being referred to docs/books, points to conceptual inconsistencies or mismatches in the intended application contexts. As a user I operate with directories and files. Now version control also introduces a time-component, which is versions (and version of a version aka branch) and some kind of history/timeline/journal/log. Why would a branch have a "head" and "base", isn't parent/child concept expressive already? Why "ref", if we've got "version" already? Why "stage", "index", "cache"? Why "cherry-pick" if we've got "patch"? Etc.
- shxdow 5y ago
  One reason why you would want to know how Git internally works is to make a better use of it. The interface it exposes is relatively low level and as such suffers when uses don't understand how the software internally operates. If anything, used being repeatedly pointed to docs shows the lack of understanding of Git's inner workings.

130 points by philonoist 5y ago

Pffft, as if anyone actually could just use Git commands without learning the internals.

In my experience it is fine to first learn only some required commands. One will run into cases, where ones understanding or imagination of how git works will not work any longer. In such cases one can still read up on how it works and build a new working understanding. Only important to not always just shrug, delete the repo and clone again. That will not really facilitate learning. Of course no one is stopping anyone interested in it from reading more about how it works up front.

taubek 5y ago
I'm new to git. For now I use it from VSC, but I should probably give CLI a chance. I must admit that I'm at the point where I shrug, delete and clone the repo if I'm stuck. Some errors and messages were to cryptic to me.
wmf 5y ago
This usually leads to "my shit's due in an hour, my repo is totally broken and I have no idea why... HEEEEELP".

throw0101a 5y ago

It's been over a decade and I still find this joke amusing: > @wilshipley git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217 (It's a 'spoof' on the Monad joke.)

zibzab 5y ago
Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)
- recursive 5y ago
  We can stop with these comments after another system displaces git as the dominant player.
  - deleted 5y ago
    [deleted]
- dogleash 5y ago
  >Why... Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a steep learning curve before you can half-ass it. Depending on perspective this is either a damning indictment of git, or just another day at the office. I've been helping people learn git for over a decade now. Unironically the easiest to teach are interns.
  - dmz73 5y ago
    I am using git as a version control system via Tortoise GIT which does a great job of exposing the minimum required functionality of git (maybe a bit more than minimum) and it is only when something goes wrong or I need advanced features that I have to fall back on git command line. So 99.99% of the time I use 10% of git functionality. Even if I did learn all of git (and I doubt there are many people that can make that claim), I would probably forget most of it by the next time I needed to use a particular feature. The main thing that should be explained at the start of any git related tutorial is how git handles the full workflow (from remote to local to work copy and back) because that is one thing that is missing but once you know it the rest becomes easy to understand.

kwertyoowiyop 5y ago

“You need to use git diff --cached to see what is actually in the index: the staged changes.” Like LOTR, everyone has more than one name.

delecti 5y ago

Understanding what git is doing under the hood did more for my ability to use it effectively than it did for most tools. That said, this document in particular does not seem to be a very good way to get that understanding, it's a very "IBM documentation" way of presenting git. I wish I remembered what I read, because it's was a much easier read.

boppo1 5y ago
Maybe the git man pages? Iirc the man pages have 2 or 3 'getting started' documents that really made me feel confident. Then I didn't use it for two years and now it's real fuzzy again.
wmanley 5y ago
For me it was "Git for Computer Scientists": https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/
pwitvoet 5y ago
Perhaps it was Pro Git's chapter 10: Git Internals(1)? I once used it as a guide when writing a basic 'git inspection' tool and definitely found the whole experience useful for getting a better understanding of Git. 1) https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
jpindar 5y ago
I found the Git section of "The Missing Semester of Your CS Education" to be helpful.
- nereye 5y ago
  Seconded, here is the link: https://www.youtube.com/watch?v=2sjqTHE0zok https://www.youtube.com/watch?v=2sjqTHE0zok.

speed_spread 5y ago

Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.

aequitas 5y ago
You mean like: https://gitless.com https://gitless.com
- martinvonz 5y ago
  Or my own project: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. I think https://github.com/Byron/gitoxide https://github.com/Byron/gitoxide also plans to provide a different CLI, but I don't think they've started working on it.
pfarrell 5y ago
Poe's Law is getting me on your comment. If it wasn't sarcasm, what's an example of a weakness? IMHO, there's a learning curve to using git and especially getting to the point where you can be your team's go-to person for git questions. However, I hold the opinion that of the many technologies out there, git is among those that is worth any investment you can make in learning it. Personally, long term use of git has affected the way I code to bring more intention and organization to what I'm doing.
- _dain_ 5y ago
  quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.
  - zibzab 5y ago
    But are these things a normal user would need to care about? I bet if you created a great git desktop app with outstanding UI it would still have a few corners 99% of users would never touch or understand.

DarkWiiPlayer 5y ago

The important thing to understand is that git is a blockchain

globular-toast 5y ago
It goes a lot further than just being a blockchain. Git is a DAG through and through. But this might actually be the best way to make some people understand it. I was gobsmacked one day when a colleague came into work and they were really excited as they'd realised git is actually a blockchain. I was stunned as it seemed so obvious, but if they only just realised then how had we been working successfully with git for so long?
- cryptonector 5y ago
  A blockchain is one linear branch. Git is just a tree of them, but they're all blockchains. The only other extremely important thing to understand about Git is that it has a way to name commits symbolically (branches and tags), and that those names can be changed, and that leads to understanding what a fast-forward and non-fast-forward change to a branch really is.
kwertyoowiyop 5y ago
So each commit is an NFT. Now, where’s my million dollars?
deleted 5y ago
[deleted]

erwincoumans 5y ago

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)

globular-toast 5y ago
"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?
- erwincoumans 5y ago
  Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.
  - globular-toast 5y ago
    You misunderstand. Do you think I was born understanding how git works? I've messed up at least as much as you, but I spent the time learning how it works rather than going nuclear and deleting the repository. I can't relate to how you think about git because it's been too long for me, that's why I asked if you could explain it from your point of view.
    - seized 5y ago

zibzab 5y ago

A mucher better explanation of git interals: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It is surprisingly simple and efficient. I am starting to think this Linus guy knows what he is doing.

balefrost 5y ago
I still very much recommend the Peepcode Git Internals book. https://github.com/pluralsight/git-internals-pdf/releases https://github.com/pluralsight/git-internals-pdf/releases
kwertyoowiyop 5y ago
He offloaded the complexity to its users! :-) If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.
- gjvc 5y ago
  Complexity is unavoidable in the long run, but must be engineered out in the short run.
- torstenvl 5y ago
  > If the command and option names had just been sensible Holy shit, yes. `git branch` in gitspeak really means `git branch list` in human-readable CLI But `git branch ${NAME}` does not mean `git branch list ${NAME}`, instead it means `git branch create ${NAME}` There is no `git branch switch ${NAME}` but instead it's `git checkout ${NAME}` There is no `git branch log` – that would be `git log`, whereas if you want what should be `git log` what you really want is `git log --all` Don't get me started on whether modified files are added, staged, or indexed...
  - kwertyoowiyop 5y ago
    They are added, staged, indexed, AND cached!

NalNezumi 5y ago

I like the attitude of "learn the principles of the simple building blocks behind it" as a good next step from a freshman that just memorized "add, commit & pull/push" But most headache (and heartattack) inducing part of Git when I was a beginner was the "remote vs local repo" and additional complexities this concept introduced. Nothing more stressing for the new guy than making mistakes that screw up for others (mistakeful push, merge, mostly ) or if he think he did. The article does a poor job (imo) regarding this. It skims on a 2 paragraph "Caveat" section how rebase(and later squeeze) can fuck local vs remote repo, but for most people I know, stress memories around this is what made them learn more about Git beyond than "branch & history keeping software & commands. That and if you unfortunately end up in a project that uses subtree or submodules

nyellin 5y ago

There is a great tutorial which teaches git internals by implementing git in python: https://www.leshenko.net/p/ugit/ https://www.leshenko.net/p/ugit/

pjam 5y ago

Feeling required to post about the Building Git[1] book, really love it, for anyone interested in a walkthrough of rebuilding many of the most of important git features, from scratch, in ruby. [1]: https://shop.jcoglan.com/building-git/ https://shop.jcoglan.com/building-git/

enriquto 5y ago

As much as I love and depend on git, the visible user interface seems a bit ugly. You can get used to it over time, but it has a certain non-unix flavor that I dislike... There should be a purely unix way to use git, as in "everything is a file". Sure, you can go to the .git folder and there are files in there. But the structure of these files does not directly represent the structure of the repository. What I want is to "mount" a git repository, so that I can explore its contents using cd, ls and cat. Also, by editing these files I implicitly make commits and create branches to the underlying structure. Would that even be possible? EDIT: A disturbing feature that I don't see a way out is that in git there are "standard" and "history-rewriting" operations, and there is a clear distinction between the two. To what would that correspond in terms of pure file operations? Something about changing the default permissions?

mikewarot 5y ago
If I might offer a suggestion, instead of using various git commands, you want to be able to just cp a folder to a mounted git folder, and echo the commit message to a .commitmsg in that folder, or something like that, right?
- enriquto 5y ago
  Yes, but not only that, I want a folder for each commit, with all the files inside it, including a .commitmsg file with each log message. Thus "git log" could be implemented as cat `find . | grep commitmsg` More interestingly, it would be able to grep around all previous versions of the files.
cryptonector 5y ago
> A disturbing feature that I don't see a way out is that in git there are "standard" and "history-rewriting" operations, and there is a clear distinction between the two. To what would that correspond in terms of pure file operations? Something about changing the default permissions? > "history-rewriting" operations Git is a Merkle hash tree. You can never rewrite history. Instead, what you think of as "history-rewriting" operations is just "non-fast-forward" changes to branches. Branches are really just named pointers -- {branch_name, commit_hash}. A change to branch from {$name, $commit0} to {$name, $commit1} is fast-forward IFF $commit0 appears in the linear history of $commit1. A non-fast-forward change to a branch is what you call a "history-rewriting" operation. There's nothing wrong with "history-rewriting" -- I do it all the time. It's only ever bad when you do a non-fast-forward push to a branch that others track, and even then it's not the end of the world because usually those others can recover easily enough with `git rebase --onto`. Rewriting the history of a public branch is a problem, yes, because you want the history to be stable and reliable so you can use it to figure out problems, understand the history of the project, etc, and because making others have to `git rebase --onto` is impolite. It's essential to understand that the only destructive operations in git are a) non-fast-forward branch changes, b) tag changes, c) gc/prune operations when you're like me and you're used to working in detached-HEAD mode. If you're stuck on "Git has history rewriting, and that's bad!", then you've misunderstood everything about modern version control systems. You can -and I have- do the same sorts of destructive operations in version control systems going back to the early 90s (e.g., Teamware, CVS), to say nothing of newer ones like Mercurial, Fossil, and, of course, Git. Inb4 "But Git encourages history rewriting" -- that is neither true nor a good argument.

glynnormington 5y ago

Excellent! Two updates since it was written: use main rather than master for the default branch; use git switch to change or create branches.

zoomablemind 5y ago

As a user, I see absolutely no reason to know the internal workings of Git. It supposedly offers a service, which is tracking and recording changes to files. In a way, it's a very able SaveAs/Open command and also offering some way of altering the recorded history. How it's done internally, as much as it's remarkable, is just an implementation detail. The fact that users are repeatedly being referred to docs/books, points to conceptual inconsistencies or mismatches in the intended application contexts. As a user I operate with directories and files. Now version control also introduces a time-component, which is versions (and version of a version aka branch) and some kind of history/timeline/journal/log. Why would a branch have a "head" and "base", isn't parent/child concept expressive already? Why "ref", if we've got "version" already? Why "stage", "index", "cache"? Why "cherry-pick" if we've got "patch"? Etc.

shxdow 5y ago
One reason why you would want to know how Git internally works is to make a better use of it. The interface it exposes is relatively low level and as such suffers when uses don't understand how the software internally operates. If anything, used being repeatedly pointed to docs shows the lack of understanding of Git's inner workings.