2 ms·
> “If I’m on rev 1000 and see the bug and you are on rev 990 and don’t see the bug then we have 9 possible culprit commits” Sure, that's easy for humans, but o
by akx 8y ago
> “If I’m on rev 1000 and see the bug and you are on rev 990 and don’t see the bug then we have 9 possible culprit commits”
Sure, that's easy for humans, but on the other hand “If I’m on rev 4093e8 and see the bug and you are on rev 9b6dd8 and don’t see the bug then we have $(git log --oneline 4093e8..9b6dd8) possible culprit commits” works just as well.
As for why there is no blessed-branch-on-blessed-server-and-commits-are-numbered-there behavior, it's just not conceptually clean for a distributed, decentralized version control system. GitHub or GitLab or Bitbucket could build this sort of behavior... but it still doesn't feel very Git-y.
- alkonaut 8y ago> then we have $(git log --oneline 4093e8..9b6dd8) possible culprit commits” works just as well. It does - but that’s also why it’s so annoying that it’s behind a very cumbersome cli front end. As fotdistributed vcs: I realize that Git was designed as decentralized, and almost not even designed as version control - just a “stupid content manager”, and that higher level functionality is built on top (such as GitHub). But that doesn’t change the fact that the 99 or 99.9% use case is centralized version control in the sense that there is a central blessed repo, making it absolutely trivial to agree on a shared global history in git just like in subversion. I still think this sort of behavior should be part of core git, ie a higher level functionality layer of the kind now added by GitHub or some plugin code. Such as features for the centralized development model that almost everyone uses git for. These features include: - file locking for non-text content (now available e.g in lfs). - pull requests (now added eg by GitHub) - Simple chronological history Etc.