6 ms·

I disagree. The model is intuitive. It's just that Git dresses it up in confusing language, a terrible CLI and a gazillion half baked GUIs. It doesn't help that

by timhh 4y ago

I disagree. The model is intuitive. It's just that Git dresses it up in confusing language, a terrible CLI and a gazillion half baked GUIs. It doesn't help that lots of people recommend not using a GUI which is terrible advice for learning. Btw I would recommend GitExtensions for learning Git. It has the most intuitive interface I've found. For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs.

goku12 4y ago
Git model is intuitive until you have to deal with merge conflicts, rebasing etc. Are you judging with that experience? > For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs. This is exactly the problem I mentioned. For one, each commit is a snapshot in the sense that it shows us a snapshot. Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. But you probably knew this already. The real confusing part comes when you have to amend a commit, merge branches, interactive rebases, etc. The changes between the commits are propagated as patches. Even the merge algorithm uses a 3-way diff. Rebases is all about diffing and patching behind the scene. Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. You should know when to use snapshot model and when to use diff-patch model in Git. This part is also rarely mentioned in Git tutorials or tools (stgit on the other hand, exposes this diff-patch idea very well)
- timhh 4y ago
  > Are you judging with that experience? Yes. Again, merge conflicts are intuitive (there were two different edits to the same code; you have to resolve the conflict). But yet again Git makes things difficult - using words like "Ours" and "Theirs" (when they're often both "ours"). It even gets them backwards in some cases! Rebases are also pretty intuitive. For once it's not too bad a name - you take all the changes in a branch and reapply them to a new base commit. Re-base. > Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. That is the snapshot. It's deduplicated but it is still a snapshot. I'm not sure what your point is here. > Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. It really doesn't. It just means you have to describe what things do properly. Rebase calculates the changes from one diff to another and tries to apply those changes again from a different starting point. Easy no?

by timhh 4y ago

goku12 4y ago

Git model is intuitive until you have to deal with merge conflicts, rebasing etc. Are you judging with that experience? > For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs. This is exactly the problem I mentioned. For one, each commit is a snapshot in the sense that it shows us a snapshot. Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. But you probably knew this already. The real confusing part comes when you have to amend a commit, merge branches, interactive rebases, etc. The changes between the commits are propagated as patches. Even the merge algorithm uses a 3-way diff. Rebases is all about diffing and patching behind the scene. Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. You should know when to use snapshot model and when to use diff-patch model in Git. This part is also rarely mentioned in Git tutorials or tools (stgit on the other hand, exposes this diff-patch idea very well)

timhh 4y ago
> Are you judging with that experience? Yes. Again, merge conflicts are intuitive (there were two different edits to the same code; you have to resolve the conflict). But yet again Git makes things difficult - using words like "Ours" and "Theirs" (when they're often both "ours"). It even gets them backwards in some cases! Rebases are also pretty intuitive. For once it's not too bad a name - you take all the changes in a branch and reapply them to a new base commit. Re-base. > Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. That is the snapshot. It's deduplicated but it is still a snapshot. I'm not sure what your point is here. > Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. It really doesn't. It just means you have to describe what things do properly. Rebase calculates the changes from one diff to another and tries to apply those changes again from a different starting point. Easy no?