3 ms·

If you can understand the data structure git uses (Merkel Trees) it becomes easy to understand git (won't help with the CLI though). I think it can be summariz

If you can understand the data structure git uses (Merkel Trees) it becomes easy to understand git (won't help with the CLI though). I think it can be summarized as Linked List in reverse. New entries are always added on head instead of tail. The pointer used to track the growing list is 'branch' pointer. The pointer that is fixed to a specific node is 'tag'. Since we are adding on Head, we can have multiple nodes point to one node.

layer8 4y ago
That’s the easy part. It doesn’t tell you how local and remote interact and how the working tree, index and repository interact, and how to handle the issues you can run into with merging, rebasing, etc.
- smusamashah 4y ago
  Rebasing is when a whole branch (a chain of commits) is picked up and moved on to some other commit. It's easy to build up on that. Working tree is current state of files. Index is the staging area or the buffer (if I am not forgetting) where you put your changes you are about to permanently commit. Git is distributed system. Your repo can point to another repo as its remote copy. Can have multiple remotes. The default remote is 'origin'. When pushed, changes are uploaded to that remote repo. The remote repo doesn't have to be on a server. You can have it locally in another folder. When you push, your changes will be copied to that one too. Edit: I don't know how merge really works, and merge issues have been difficult to resolve therefore.
  - layer8 4y ago
    I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them. I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc. I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on. Those are the things where people get in trouble and into broken states.
    - seba_dos1 4y ago
      > I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them. I found it rather obvious? Git usually tells you how to deal with it, and conflict markers are easy to understand. What could be more visible is that rerere exists, as that can save you a lot of energy if you're rebasing frequently. Also, conflicts from stashes are a weird special case, which can be confusing (but so are stashes in general). > I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc. That's also obvious, and Git tells you what happens as you do this stuff too. If it couldn't switch a branch, it tells you why; if there's an uncommited change, it's listed during checkout. I don't think I'd be able to tell how various commands interact with index without having git in front of me, and yet it doesn't cause me any visible troubles (and I'm a somewhat heavy git user). > I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on. I don't really understand what's problematic with those. All of the things you mentioned are really basic commands. A good tutorial could easily cover it all. There's plenty of stuff to criticize about git's UI, but I'm very surprised that this is what you found worth mentioning.
    - smusamashah 4y ago
      > but how they interact under the various commands > but about how to deal with different remotes, how to have local branches If you are saying this in context of CLI. I have no clue. What I am saying is, if you understand the concepts and have a good GUI tool at your disposal you can solve almost all problems with ease. I have previously used SmartGit which lets you drag and rearrange commits. It also allows interactively selecting the lines/chunks from you want to make part of commit. Same goes for resolving conflicts. IntelliJ also has a very good GUI which I use these days at work. Something I didn't find much help with was how to squash commits which include merge commits as well. But overall, GUIs help alot if you know what you want to do.

layer8 4y ago

That’s the easy part. It doesn’t tell you how local and remote interact and how the working tree, index and repository interact, and how to handle the issues you can run into with merging, rebasing, etc.

smusamashah 4y ago
Rebasing is when a whole branch (a chain of commits) is picked up and moved on to some other commit. It's easy to build up on that. Working tree is current state of files. Index is the staging area or the buffer (if I am not forgetting) where you put your changes you are about to permanently commit. Git is distributed system. Your repo can point to another repo as its remote copy. Can have multiple remotes. The default remote is 'origin'. When pushed, changes are uploaded to that remote repo. The remote repo doesn't have to be on a server. You can have it locally in another folder. When you push, your changes will be copied to that one too. Edit: I don't know how merge really works, and merge issues have been difficult to resolve therefore.
- layer8 4y ago
  I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them. I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc. I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on. Those are the things where people get in trouble and into broken states.
  - seba_dos1 4y ago
    > I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them. I found it rather obvious? Git usually tells you how to deal with it, and conflict markers are easy to understand. What could be more visible is that rerere exists, as that can save you a lot of energy if you're rebasing frequently. Also, conflicts from stashes are a weird special case, which can be confusing (but so are stashes in general). > I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc. That's also obvious, and Git tells you what happens as you do this stuff too. If it couldn't switch a branch, it tells you why; if there's an uncommited change, it's listed during checkout. I don't think I'd be able to tell how various commands interact with index without having git in front of me, and yet it doesn't cause me any visible troubles (and I'm a somewhat heavy git user). > I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on. I don't really understand what's problematic with those. All of the things you mentioned are really basic commands. A good tutorial could easily cover it all. There's plenty of stuff to criticize about git's UI, but I'm very surprised that this is what you found worth mentioning.
  - smusamashah 4y ago
    > but how they interact under the various commands > but about how to deal with different remotes, how to have local branches If you are saying this in context of CLI. I have no clue. What I am saying is, if you understand the concepts and have a good GUI tool at your disposal you can solve almost all problems with ease. I have previously used SmartGit which lets you drag and rearrange commits. It also allows interactively selecting the lines/chunks from you want to make part of commit. Same goes for resolving conflicts. IntelliJ also has a very good GUI which I use these days at work. Something I didn't find much help with was how to squash commits which include merge commits as well. But overall, GUIs help alot if you know what you want to do.