4 ms·

Are you saying that the "natural way" you think about branches is as a DAG terminating at one point? Because that is true; that is accurate. Thus, I don't unde

Are you saying that the "natural way" you think about branches is as a DAG terminating at one point? Because that is true; that is accurate. Thus, I don't understand your original claim that branches work in an unintuitive way.

Espressosaurus 3y ago
A branch in Git is just the pointer to the tip of the DAG. The way I find it natural to think about is it's the entire DAG of commits. To put this in programming terms, a git branch is a pointer. I think of a branch as the value is the most natural way to think about it. This mismatch is what leads to endless tutorials on what git actually means when it uses its vocabulary.
- Buttons840 3y ago
  If I created my own git implementation with the exact same CLI, but under the hood I didn't use a "pointer", but instead used the "value", would this be more intuitive to you? One problem I'm trying to express with that question is: You say it's unintuitive, but when asked why you refer to a very low level technical detail. My suspicion is that people find git branches unintuitive, and thus they think something more intuitive must exist. They have vague ideas about what "more intuitive" might mean, usually it means "just do what I want in this one situation I'm currently facing". My theory is that, if pressed, nobody can fully define a behavior for branches that is more intuitive than the current git implementation.
  - Espressosaurus 3y ago
    Well, you're still using the same CLI which is part of the problem. Git's CLI reflects its patched-together-hacked-executable history. It shouldn't be controversial to say the porcelain can and should be much more straightforward to use. DVCS concepts like the DAG and where you want to apply diffs are complicated the first time around, but after you get the concepts it should be easy to use, not difficult. Mercurial's branches are a better match for how I've seen branches use in practice. Tags are essentially the same between both. Evolve's hidden commits make it easier to recover lost data than Git's reflog, though the underlying implementation not permitting garbage collection kind of sucks.
- cryptonector 3y ago
  > To put this in programming terms, a git branch is a pointer. I think of a branch as the value is the most natural way to think about it. The branch name is a pointer. All pointers (commits) are also branches of the DAG, just anonymous. Orphaned commits (i.e., not reachable from any named branch or tag) can be garbage collected (deleted). The point is that raw pointer values do not make for user-friendly interfaces. Humans deal well with names and poorly with numbers. Thus we need names. Every VCS in the world supports branch names. The issue here is that Git's default rules for branches are shockingly simple for users coming from Mercurial and other VCSes, but those default rules are also the simplest possible default rules and you can add rules on top. Like you, I have no problem working with the raw pointer values some of the time, so I often work in detached-HEAD mode, though in the end I have to always name commits I don't want to lose to GC and that I want to be able to find in the future -- in the end I still need names for commits, I still need named branches and tags.

Espressosaurus 3y ago

A branch in Git is just the pointer to the tip of the DAG. The way I find it natural to think about is it's the entire DAG of commits. To put this in programming terms, a git branch is a pointer. I think of a branch as the value is the most natural way to think about it. This mismatch is what leads to endless tutorials on what git actually means when it uses its vocabulary.

Buttons840 3y ago
If I created my own git implementation with the exact same CLI, but under the hood I didn't use a "pointer", but instead used the "value", would this be more intuitive to you? One problem I'm trying to express with that question is: You say it's unintuitive, but when asked why you refer to a very low level technical detail. My suspicion is that people find git branches unintuitive, and thus they think something more intuitive must exist. They have vague ideas about what "more intuitive" might mean, usually it means "just do what I want in this one situation I'm currently facing". My theory is that, if pressed, nobody can fully define a behavior for branches that is more intuitive than the current git implementation.
- Espressosaurus 3y ago
  Well, you're still using the same CLI which is part of the problem. Git's CLI reflects its patched-together-hacked-executable history. It shouldn't be controversial to say the porcelain can and should be much more straightforward to use. DVCS concepts like the DAG and where you want to apply diffs are complicated the first time around, but after you get the concepts it should be easy to use, not difficult. Mercurial's branches are a better match for how I've seen branches use in practice. Tags are essentially the same between both. Evolve's hidden commits make it easier to recover lost data than Git's reflog, though the underlying implementation not permitting garbage collection kind of sucks.
cryptonector 3y ago
> To put this in programming terms, a git branch is a pointer. I think of a branch as the value is the most natural way to think about it. The branch name is a pointer. All pointers (commits) are also branches of the DAG, just anonymous. Orphaned commits (i.e., not reachable from any named branch or tag) can be garbage collected (deleted). The point is that raw pointer values do not make for user-friendly interfaces. Humans deal well with names and poorly with numbers. Thus we need names. Every VCS in the world supports branch names. The issue here is that Git's default rules for branches are shockingly simple for users coming from Mercurial and other VCSes, but those default rules are also the simplest possible default rules and you can add rules on top. Like you, I have no problem working with the raw pointer values some of the time, so I often work in detached-HEAD mode, though in the end I have to always name commits I don't want to lose to GC and that I want to be able to find in the future -- in the end I still need names for commits, I still need named branches and tags.