4 ms·

Pypy described the following in the FAQ: > The difference between git branches and named branches is not that important in a repo with 10 branches (no matter h

Pypy described the following in the FAQ: > The difference between git branches and named branches is not that important in a repo with 10 branches (no matter how big). But in the case of PyPy, we have at the moment 1840 branches. Most are closed by now, of course. But we would really like to retain (both now and in the future) the ability to look at a commit from the past, and know in which branch it was made. Please make sure you understand the difference between the Git and the Mercurial branches to realize that this is not always possible with Git— we looked hard, and there is no built-in way to get this workflow. > Still not convinced? Consider this git repo with three commits: commit #2 with parent #1 and head of git branch “A”; commit #3 with also parent #1 but head of git branch “B”. When commit #1 was made, was it in the branch “A” or “B”? (It could also be yet another branch whose head was also moved forward, or even completely deleted.) In this post they say that "Github notes solves much of point (1): the difficulty of discovering provenance of commits, although not entirely"

dgfitz 3y ago
The question in your example seems odd to me. It can be interpreted as either 2 OR 3 unique branches depending on how you read it. There is either base branch A whose current head is commit #2 / branch B with head of commit #3. OR Commit #1 is branch “default” commit #2 is branch “A” with parent as commit #1 and commit is branch “B” with parent also as commit #1 Consider your same example with forking instead of branching, how would the issue be resolved?
- Dylan16807 3y ago
  > It can be interpreted as either 2 OR 3 unique branches depending on how you read it. The question isn't how many branches, it's what branch the commit was on at the point in time it was created. That's not up to interpretation. It's information that was not recorded. > Consider your same example with forking instead of branching, how would the issue be resolved? Forked repositories don't have IDs, don't generally keep track of each other, and there's no way to even count them. So that's not solvable. But branches do have names, and you almost always make commits onto branches. We shouldn't give up on tracking branches just because tracking forks is hard.

dgfitz 3y ago

The question in your example seems odd to me. It can be interpreted as either 2 OR 3 unique branches depending on how you read it. There is either base branch A whose current head is commit #2 / branch B with head of commit #3. OR Commit #1 is branch “default” commit #2 is branch “A” with parent as commit #1 and commit is branch “B” with parent also as commit #1 Consider your same example with forking instead of branching, how would the issue be resolved?

Dylan16807 3y ago
> It can be interpreted as either 2 OR 3 unique branches depending on how you read it. The question isn't how many branches, it's what branch the commit was on at the point in time it was created. That's not up to interpretation. It's information that was not recorded. > Consider your same example with forking instead of branching, how would the issue be resolved? Forked repositories don't have IDs, don't generally keep track of each other, and there's no way to even count them. So that's not solvable. But branches do have names, and you almost always make commits onto branches. We shouldn't give up on tracking branches just because tracking forks is hard.