6 ms·

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

adrianmsmith 7y ago
Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)
anoncake 7y ago
> The problem is, is that git will happily destroy history. No, people will happily destroy history. Git is just a tool.
- wyoung2 7y ago
  Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger. In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)
  - anoncake 7y ago
    > Fossil's opinion Tools don't have opinions, people do. Fossil is just inflexible. You don't want to alter history? Don't do it then. Git supports not altering history just fine.
    - TwoHeadedBeast 7y ago
      I can't control what other users of the repo are doing, so it's not that simple.
      - anoncake 7y ago
        If you are their superior, other users disregarding your orders is s social problem, not a technical one. If you aren't, it's a good thing they are able not to do what you want. Tools being more flexible is strictly a good thing. If they are misused, the person that misused them is responsible. It is that simple.

6 ms·

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

by TwoHeadedBeast 7y ago

adrianmsmith 7y ago
Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)
anoncake 7y ago
> The problem is, is that git will happily destroy history. No, people will happily destroy history. Git is just a tool.
- wyoung2 7y ago
  Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger. In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)
  - anoncake 7y ago
    > Fossil's opinion Tools don't have opinions, people do. Fossil is just inflexible. You don't want to alter history? Don't do it then. Git supports not altering history just fine.
    - TwoHeadedBeast 7y ago
      I can't control what other users of the repo are doing, so it's not that simple.
      - anoncake 7y ago
        If you are their superior, other users disregarding your orders is s social problem, not a technical one. If you aren't, it's a good thing they are able not to do what you want. Tools being more flexible is strictly a good thing. If they are misused, the person that misused them is responsible. It is that simple.