4 ms·

>One use case is given branch X, tell me what the branch looked like N commits in the past. What am I not understanding here? You definitely can go N commits i

>One use case is given branch X, tell me what the branch looked like N commits in the past. What am I not understanding here? You definitely can go N commits in the past on each branch, and even any commit. And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).

stevelosh 10y ago
┌─────┐◀──────── master │Merge│◀──────── bugfix └▲───▲┘ │ │ │ │ │ ┌─┐ │ │B│ │ └▲┘ ┌─┐ │ │A│ │ └▲┘ │ └───┤ │ ┌────────┐ │Ancestor│ └────────┘ Which branch was commit `B` made on? What did the `bugfix` branch look like one commit ago?
- grzm 10y ago
  Nice use of Unicode! Do you have a tool to help you construct a diagram like this?
  - deleted 10y ago
    [deleted]
- sampo 10y ago
  If you were in master when you merged bugfix in ("git merge bugfix"), then you can git cat-file -p master and see which commit, A or B, is listed as the first parent. This belongs to the master.
- justinlaster 10y ago
  > Which branch was commit `B` made on You can do some basic heuristics to figure it out, but I'm not sure what the point of knowing this is. >What did the `bugfix` branch look like one commit ago? `git checkout bugfix; git log bugfix^1`
zck 10y ago
In the case of merges, how would you tell which parent to look at? Branches might have been deleted, moved, or merged. > And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out). The reflog is not moved across remotes, is it? If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago.
- justinlaster 10y ago
  You're right, it's not moved across remotes. I'm just confused to why the information would ever be needed. It seems to not have any real use case. You can recreate a branch any where at any point in the history, why would you care what commit a branch originally came from? It seems like a solution in search of a problem. Or maybe even a solution to a problem that shouldn't need solving in the first place! >If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago. This isn't true with Mercurial either. A lot can happen in a year, and it might even make the information misleading (having similar named branches, history deletion, etc). It's useless at best and misleading at worst.
  - zck 10y ago
    "This commit has a bad commit message. Why did I commit it? Oh, it's on the branch add-search-functionality." I find that having a branch name that was the sole branch name when the code was made gives context to the commit; why it was made and what its purpose was. Being reachable from a branch pointer doesn't give that same context. Yes, commit messages should handle this. But I find they don't. > It's useless at best and misleading at worst. This has not been my experience. I haven't found a great need for "what's the whole state a year ago"; more so "what was the context around this commit", which I think a mercurial-style branch name answers.
    - justinlaster 10y ago
      I'm sorry, in what practice are you in where your commit messages are somehow so lackluster that a branch name (not even a PR!) can give you more information about why something is being done? And to make sure no one responds with some silly "just because you don't have a use for it, doesn't mean don't have their uses for it": I get what you're trying to say. I'm really just not buying it as an actual use case. If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. If you're relying on a <20 character branch name to give you sufficient context about a commit a year later, I simply have no words. >which I think a mercurial-style branch name answers. I find that extremely suspect.

stevelosh 10y ago

┌─────┐◀──────── master │Merge│◀──────── bugfix └▲───▲┘ │ │ │ │ │ ┌─┐ │ │B│ │ └▲┘ ┌─┐ │ │A│ │ └▲┘ │ └───┤ │ ┌────────┐ │Ancestor│ └────────┘ Which branch was commit `B` made on? What did the `bugfix` branch look like one commit ago?

grzm 10y ago
Nice use of Unicode! Do you have a tool to help you construct a diagram like this?
- deleted 10y ago
  [deleted]
sampo 10y ago
If you were in master when you merged bugfix in ("git merge bugfix"), then you can git cat-file -p master and see which commit, A or B, is listed as the first parent. This belongs to the master.
justinlaster 10y ago
> Which branch was commit `B` made on You can do some basic heuristics to figure it out, but I'm not sure what the point of knowing this is. >What did the `bugfix` branch look like one commit ago? `git checkout bugfix; git log bugfix^1`

zck 10y ago

In the case of merges, how would you tell which parent to look at? Branches might have been deleted, moved, or merged. > And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out). The reflog is not moved across remotes, is it? If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago.

justinlaster 10y ago
You're right, it's not moved across remotes. I'm just confused to why the information would ever be needed. It seems to not have any real use case. You can recreate a branch any where at any point in the history, why would you care what commit a branch originally came from? It seems like a solution in search of a problem. Or maybe even a solution to a problem that shouldn't need solving in the first place! >If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago. This isn't true with Mercurial either. A lot can happen in a year, and it might even make the information misleading (having similar named branches, history deletion, etc). It's useless at best and misleading at worst.
- zck 10y ago
  "This commit has a bad commit message. Why did I commit it? Oh, it's on the branch add-search-functionality." I find that having a branch name that was the sole branch name when the code was made gives context to the commit; why it was made and what its purpose was. Being reachable from a branch pointer doesn't give that same context. Yes, commit messages should handle this. But I find they don't. > It's useless at best and misleading at worst. This has not been my experience. I haven't found a great need for "what's the whole state a year ago"; more so "what was the context around this commit", which I think a mercurial-style branch name answers.
  - justinlaster 10y ago
    I'm sorry, in what practice are you in where your commit messages are somehow so lackluster that a branch name (not even a PR!) can give you more information about why something is being done? And to make sure no one responds with some silly "just because you don't have a use for it, doesn't mean don't have their uses for it": I get what you're trying to say. I'm really just not buying it as an actual use case. If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. If you're relying on a <20 character branch name to give you sufficient context about a commit a year later, I simply have no words. >which I think a mercurial-style branch name answers. I find that extremely suspect.