6 ms·

Although in implementation, a commit is not done on a branch, for the user, that is precisely what happens. You checkout a branch and you do a commit while on t

Although in implementation, a commit is not done on a branch, for the user, that is precisely what happens. You checkout a branch and you do a commit while on that branch. Thus, to the novice, it might be perfectly normal to expect Git to tell him what branches the commit was made on, even though that makes no sense from Git's point of view. I've never had that use case (knowing what branch a commit was made on), but if many people need it, surely explaining to them how Git works doesn't make Git any better for not being able to provide what the user needs.

philwelch 14y ago
Branches are just mutable pointers to commits. You're imposing a mental model onto Git that simply isn't present. Git is revolutionary, in part, because instead of asking "what's the mental model we want to emulate and then never mind if that matches the implementation", they gave developers credit that they can understand a handful of simple concepts and made the actual design and data model as simple as possible. Programmers know what pointers, SHA-1 hashes, and DAGs are, so just use them.
- aidenn0 14y ago
  Maybe Linux kernel devs deserve that credit, but it's becoming increasingly clear that developers as a whole don't deserve that credit.
  - philwelch 14y ago
    That's their problem. There are tools for fools. I'm glad I don't have to use them.
    - Anderkent 14y ago
      Of course everyone who doesn't like your tool is a fool. It's just not possible they'd have different but equally valid requirements!
      - philwelch 14y ago
        Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.
        aidenn0 14y ago
        Going back to my comment, I think for a lot o peole it's not that they can't understand the Git data model, it's that they: 1) don't magically know that they're supposed to understand the data model in order to use it 2) Come for help when they screwed up because they don't understand it and are basically told "You screwed up because you're an idiot"; since they are already in a bad mood, they then ragequit.
        Anderkent 14y ago
        >If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Well, the fact that I can't easily find what commits were done on a branch, for one. And yes, I understand why it's not possible, they way git does branches. Or that it doesn't track renames/moves, other than on similarity basis that often fails to detect rename when viewing a file history, for example. The git answer to both of these is usually 'well your viewer could be doing that', except they don't, because it's hard when you don't track that information in commits.
        philwelch 14y ago
        Lets back up: why are you trying to figure out what branch a historical commit was on? What problem does that solve for you? I've never found that information terribly important or interesting.
        Anderkent 14y ago
        Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch. It also means I can easily request all commits made in the master branch, to see what features were merged in recently.
- pilgrim689 14y ago
  You're making the same mistake as GP. I love Git, and I know that asking "what branch was this commit on" makes no sense. My point is that some users have different requirements as to what a DVCS should provide. If Git can't fulfill some of these requirements, then just say "Git can't do this" rather than beating around the bush.
  - philwelch 14y ago
    I'm saying that "for the user" is a distinction not necessary for a tool designed for the type of people who actually know how software works. For the user, Git does the same thing that it does for the programmers who wrote Git. There's only one side of it. It's not two-faced like most software. The only possible explanation is to explain how Git works.
    - Anderkent 14y ago
      No, a possible explanation would be 'that is unnecessary, because: ...'. Except of course tagging commits with branches is not unnecessary, because that's the only way a user might make sense of ancestors of a merge commit... Unless you like manually tracking parents of a commit, and trying to guess which branch is which based on commit messages. Fun! I've seen many workarounds to this clear deficiency, the simplest of which is simply putting the branch name at the start of the commit title. Of course that usually cuts the space available for the actual commit title down from ~60 characters to 20-40, depending on how verbosely you call your branches.
      - philwelch 14y ago
        > Unless you like manually tracking parents of a commit Git tracks the parents of a commit. There are ways to visualize that, even with command-line git. When you do this, it's usually clear which branch is master and which branch was the feature branch, and since the merge commit has a default commit message like "merge <<branch-name>> to master" it's even easier to figure out. It's also entirely possible to use a Git workflow where you rebase your branches onto master before merging then in with a fast-forward, which means there are no merge commits. This workflow usually involves squashing. Conversely, you can use a workflow where you never fast-forward merge to master, in which case master is the branch that consists of a series of commits called "merge <<branch-name>> to master".

philwelch 14y ago

Branches are just mutable pointers to commits. You're imposing a mental model onto Git that simply isn't present. Git is revolutionary, in part, because instead of asking "what's the mental model we want to emulate and then never mind if that matches the implementation", they gave developers credit that they can understand a handful of simple concepts and made the actual design and data model as simple as possible. Programmers know what pointers, SHA-1 hashes, and DAGs are, so just use them.

aidenn0 14y ago
Maybe Linux kernel devs deserve that credit, but it's becoming increasingly clear that developers as a whole don't deserve that credit.
- philwelch 14y ago
  That's their problem. There are tools for fools. I'm glad I don't have to use them.
  - Anderkent 14y ago
    Of course everyone who doesn't like your tool is a fool. It's just not possible they'd have different but equally valid requirements!
    - philwelch 14y ago
      Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.
      - aidenn0 14y ago
        Going back to my comment, I think for a lot o peole it's not that they can't understand the Git data model, it's that they: 1) don't magically know that they're supposed to understand the data model in order to use it 2) Come for help when they screwed up because they don't understand it and are basically told "You screwed up because you're an idiot"; since they are already in a bad mood, they then ragequit.
      - Anderkent 14y ago
        >If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Well, the fact that I can't easily find what commits were done on a branch, for one. And yes, I understand why it's not possible, they way git does branches. Or that it doesn't track renames/moves, other than on similarity basis that often fails to detect rename when viewing a file history, for example. The git answer to both of these is usually 'well your viewer could be doing that', except they don't, because it's hard when you don't track that information in commits.
        philwelch 14y ago
        Lets back up: why are you trying to figure out what branch a historical commit was on? What problem does that solve for you? I've never found that information terribly important or interesting.
        Anderkent 14y ago
        Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch. It also means I can easily request all commits made in the master branch, to see what features were merged in recently.
pilgrim689 14y ago
You're making the same mistake as GP. I love Git, and I know that asking "what branch was this commit on" makes no sense. My point is that some users have different requirements as to what a DVCS should provide. If Git can't fulfill some of these requirements, then just say "Git can't do this" rather than beating around the bush.
- philwelch 14y ago
  I'm saying that "for the user" is a distinction not necessary for a tool designed for the type of people who actually know how software works. For the user, Git does the same thing that it does for the programmers who wrote Git. There's only one side of it. It's not two-faced like most software. The only possible explanation is to explain how Git works.
  - Anderkent 14y ago
    No, a possible explanation would be 'that is unnecessary, because: ...'. Except of course tagging commits with branches is not unnecessary, because that's the only way a user might make sense of ancestors of a merge commit... Unless you like manually tracking parents of a commit, and trying to guess which branch is which based on commit messages. Fun! I've seen many workarounds to this clear deficiency, the simplest of which is simply putting the branch name at the start of the commit title. Of course that usually cuts the space available for the actual commit title down from ~60 characters to 20-40, depending on how verbosely you call your branches.
    - philwelch 14y ago
      > Unless you like manually tracking parents of a commit Git tracks the parents of a commit. There are ways to visualize that, even with command-line git. When you do this, it's usually clear which branch is master and which branch was the feature branch, and since the merge commit has a default commit message like "merge <<branch-name>> to master" it's even easier to figure out. It's also entirely possible to use a Git workflow where you rebase your branches onto master before merging then in with a fast-forward, which means there are no merge commits. This workflow usually involves squashing. Conversely, you can use a workflow where you never fast-forward merge to master, in which case master is the branch that consists of a series of commits called "merge <<branch-name>> to master".