3 ms·

In fairness to GP, they said VCS, not Git, even if they are somewhat synonomous today. Other VCSes did support graph histories. Still, "3rd dimension" code re

by necovek 8mo ago

In fairness to GP, they said VCS, not Git, even if they are somewhat synonomous today. Other VCSes did support graph histories. Still, "3rd dimension" code reasoning (backwards in time) has never been merged well with code editing.

eru 8mo ago
> Other VCSes did support graph histories. Yes, git ain't the only one, but apart from interface difference, they are pretty much compatible in what they allow you to record in the history, I think? Part of the problem here is that we use git for two only weakly correlated purposes: - A history of the code - Make nice and reviewable proposals for code changes ('Pull Request') For the former, you want to be honest. For the latter, you want to present a polished 'lie'.
- necovek 8mo ago
  Not really. Launchpad.net does not have any public branches I could share atm as an example, but Bazaar (now breezy) allowed having a nested "merge commit": your trunk would have "flattened" merge commits ("Merge branch foo"), and under it you could easily get to each individual commit by a developer ("Prototype", "Add test"...). It would really be shown as a tree, but smartness was wven richer. This was made possible by using a DAG for commit storage and referencing, instead of relying on file contents and series of commits per reference. Merge behaviour was much smarter in case of diverging tip or criss-cross merges. But this ultimately was harder and slower to implement, and developers did not value this enough and they instead accepted the Git trade-offs. So you seamlessly did both with a different VCS without splitting those up: in a sense, computers and software worried about that for us.
  - eru 8mo ago
    I am not quite sure what you are describing here. Git's underlying commit graph is a DAG. You can use different, custom merge-drivers (or whatever it's called) for Git to get the behaviour you describe here.
    - necovek 8mo ago
      Certainly, but merges are treated differently by default, and getting to this sort of output would require "custom" tooling for things like "git log". Whereas bzr just did the expected thing.
      - 1718627440 8mo ago
        You can select whether you want the diff to the first or the second parent, which is the difference between collapsing and expanding merges. You can also completely collapse merges by showing first-parent-history. Or I do not understand what you mean with "the expected thing".
        eru 8mo ago
        Yes, `git log --first-parent` has been a godsend for coping with our team's messy non-cleaned up history.
- 1718627440 8mo ago
  > - A history of the code Which is a causal history, not a editing log. So I don't perceive these to be actually different.
1718627440 8mo ago
> In fairness to GP, they said VCS, not Git I did say VCS, but I also don't know what Git is missing in this relation. > Other VCSes did support graph histories. How does Git do not? > Still, "3rd dimension" code reasoning (backwards in time) has never been merged well with code editing. Maybe it's not perfect, but Git seems to do that just fine for my taste. What is missing there?

by necovek 8mo ago

eru 8mo ago

> Other VCSes did support graph histories. Yes, git ain't the only one, but apart from interface difference, they are pretty much compatible in what they allow you to record in the history, I think? Part of the problem here is that we use git for two only weakly correlated purposes: - A history of the code - Make nice and reviewable proposals for code changes ('Pull Request') For the former, you want to be honest. For the latter, you want to present a polished 'lie'.

necovek 8mo ago
Not really. Launchpad.net does not have any public branches I could share atm as an example, but Bazaar (now breezy) allowed having a nested "merge commit": your trunk would have "flattened" merge commits ("Merge branch foo"), and under it you could easily get to each individual commit by a developer ("Prototype", "Add test"...). It would really be shown as a tree, but smartness was wven richer. This was made possible by using a DAG for commit storage and referencing, instead of relying on file contents and series of commits per reference. Merge behaviour was much smarter in case of diverging tip or criss-cross merges. But this ultimately was harder and slower to implement, and developers did not value this enough and they instead accepted the Git trade-offs. So you seamlessly did both with a different VCS without splitting those up: in a sense, computers and software worried about that for us.
- eru 8mo ago
  I am not quite sure what you are describing here. Git's underlying commit graph is a DAG. You can use different, custom merge-drivers (or whatever it's called) for Git to get the behaviour you describe here.
  - necovek 8mo ago
    Certainly, but merges are treated differently by default, and getting to this sort of output would require "custom" tooling for things like "git log". Whereas bzr just did the expected thing.
    - 1718627440 8mo ago
      You can select whether you want the diff to the first or the second parent, which is the difference between collapsing and expanding merges. You can also completely collapse merges by showing first-parent-history. Or I do not understand what you mean with "the expected thing".
      - eru 8mo ago
        Yes, `git log --first-parent` has been a godsend for coping with our team's messy non-cleaned up history.
1718627440 8mo ago
> - A history of the code Which is a causal history, not a editing log. So I don't perceive these to be actually different.

1718627440 8mo ago

> In fairness to GP, they said VCS, not Git I did say VCS, but I also don't know what Git is missing in this relation. > Other VCSes did support graph histories. How does Git do not? > Still, "3rd dimension" code reasoning (backwards in time) has never been merged well with code editing. Maybe it's not perfect, but Git seems to do that just fine for my taste. What is missing there?