Hacker News Reader

Comment by TwoHeadedBeast | Hacker News Reader

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.

View on HN

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.)

> The problem is, is that git will happily destroy history.

No, people will happily destroy history. Git is just a tool.

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)

> 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.

I can't control what other users of the repo are doing, so it's not that simple.

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.

Reply on news.ycombinator.com