3 ms·

Three things that I feel are true about git's model: 1- the model is not intuitive to beginners. There's a really tough learning curve. 2- the model is powerf

by mabbo 4y ago

Three things that I feel are true about git's model: 1- the model is not intuitive to beginners. There's a really tough learning curve. 2- the model is powerful but leads to a few specific workflow. If you don't have the same mental model and don't want to use those workflows, you will have the "misery" the author describes. Otherwise, you'll be perfectly fine. 3- no one has yet to do a great job of describing that model and workflow visually. The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. That's why they are miserable. That's partially because git's model is hard to learn, and partially because after all this time they still haven't taken an hour to deeply learn it.

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?
arxanas 4y ago
> and partially because after all this time they still haven't taken an hour to deeply learn it. I've spent a fair amount of time working directly with the object database, working with the latest Git features, filing bugs to upstream, working on my own source control extensions, working on successor version control systems (Jujutsu), attending and presenting at Git meetups... It's difficult to be more of a Git power user without being on the core developer team itself. > If you don't have the same mental model and don't want to use those workflows The workflows in question support the Linux mailing list patch workflow, which are described in `gitworkflows`, and are indeed what Git was originally created for. Is it possible that maybe you haven't gotten a good feel for the model?
avgcorrection 4y ago
> The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. The author is apparently behind[1] a sucessful alternative UI to Git. It seems safe to assume that they are way beyond merely getting a feel for the Git model. The Bad-UX denialism has really gone too far when authors like that are dismissed over the old You Just Have To Understand The Model talking point. [1] https://github.com/arxanas/git-branchless/ https://github.com/arxanas/git-branchless/
deleted 4y ago
[deleted]

by mabbo 4y ago

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?

arxanas 4y ago

> and partially because after all this time they still haven't taken an hour to deeply learn it. I've spent a fair amount of time working directly with the object database, working with the latest Git features, filing bugs to upstream, working on my own source control extensions, working on successor version control systems (Jujutsu), attending and presenting at Git meetups... It's difficult to be more of a Git power user without being on the core developer team itself. > If you don't have the same mental model and don't want to use those workflows The workflows in question support the Linux mailing list patch workflow, which are described in `gitworkflows`, and are indeed what Git was originally created for. Is it possible that maybe you haven't gotten a good feel for the model?

avgcorrection 4y ago

> The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. The author is apparently behind[1] a sucessful alternative UI to Git. It seems safe to assume that they are way beyond merely getting a feel for the Git model. The Bad-UX denialism has really gone too far when authors like that are dismissed over the old You Just Have To Understand The Model talking point. [1] https://github.com/arxanas/git-branchless/ https://github.com/arxanas/git-branchless/

deleted 4y ago

[deleted]