3 ms·

No, git is perfectly fine. You just need to study it to master it, just like every other tool we use in our craft.

by aulin 3y ago

Smaug123 3y ago
"Fine" is not "optimal". The mere fact that something does the job does not make it the best possible thing that does the job. The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot commit a partial resolution of a conflict: you simply have to bail out and try and put your histories in a state that is more acceptable to the merge algorithms before trying again.
- yencabulator 3y ago
  Maybe you want more local clones (git clone -l -s) or to use worktrees, so you can leave a merge conflict pending in one of them? Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.
  - Smaug123 3y ago
    > Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.
    - yencabulator 3y ago
      It's less of a fundamental limitation and more of a thing that hasn't been programmed yet. Feel free to do that.
      - Smaug123 3y ago
        I do, thank you! (But it will never be the case that conflicts are modelled in Git, unless one uses notes or something to build a more expressive database on top of it, whereupon I think it's not really reasonable to call the resulting system "Git".)
        yencabulator 3y ago
        The git object system is based on objects having types. There was a time when the "tag" object type did not exist. The only difference between then and now is the installed base.

No, git is perfectly fine. You just need to study it to master it, just like every other tool we use in our craft.

by aulin 3y ago

No, git is perfectly fine. You just need to study it to master it, just like every other tool we use in our craft.

"Fine" is not "optimal". The mere fact that something does the job does not make it the best possible thing that does the job. The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot commit a partial resolution of a conflict: you simply have to bail out and try and put your histories in a state that is more acceptable to the merge algorithms before trying again.

yencabulator 3y ago
Maybe you want more local clones (git clone -l -s) or to use worktrees, so you can leave a merge conflict pending in one of them? Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.
- Smaug123 3y ago
  > Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.
  - yencabulator 3y ago
    It's less of a fundamental limitation and more of a thing that hasn't been programmed yet. Feel free to do that.
    - Smaug123 3y ago
      I do, thank you! (But it will never be the case that conflicts are modelled in Git, unless one uses notes or something to build a more expressive database on top of it, whereupon I think it's not really reasonable to call the resulting system "Git".)
      - yencabulator 3y ago
        The git object system is based on objects having types. There was a time when the "tag" object type did not exist. The only difference between then and now is the installed base.