Hacker News Reader

Comment by efortis | Hacker News Reader

SharePoint has versioning. Also, in industry you see on the footer of forms their revision/version number.

In car parts the last letter is the revision.

Electronic boards have revision numbers: https://youtu.be/LBoF1e5YDdQ?t=799

Sure, but all of that is primitive by the standards of version control systems used in software engineering. An incrementing number to designate a specific revision is not comparable to having branches, merge strategies, cherry-picking, bisecting etc.

can you think of a scenario where you need something like that.

I can only recall a company that used Perforce's image diff.

And a book author, Stoyan Stefanov, suggesting Git for book edits. https://blog.stoyanstefanov.com/dear-technical-copyeditors/

The same scenario that software engineers use it for: Combining work from multiple collaborators into a coherent whole. I don't see why this would be less useful for e.g. a policy institute collaboratively writing a report than it is for programmers collaboratively developing an application.

How often would this kind of report writing, which may involve many reporters, happen in an org like that? I don't think someone would like to invest in training and tooling for something that might happen once a year.

All the time? Such institutes push out 300+ page reports on a regular basis. Do you think those are written by a single person?

While that is true, one could argue that these reports are either split into distinct parts written by individual authors or are not written in parallel.

A report doesn't have ten people writing the same page. If everyone writes a chapter then merging is trivial. No need to learn a complex tool

For drafting yes, but at some point someone will probably want to edit or review the parts collectively. It's easy to prematurely consolidate the chapters into one file, and then any further changes have to be merged into the 'master'. A proper VCS can help here.

But do you need that? How useful is cherry-picking in manufacturing (I guess not so much)? Why should one change a perfectly working system with something new - as far as I know, revision numbers in manufacturing are perfectly fine.

IMHO, git is fine for software, and that's it.

Many software projects have their documentation in Git. That is partly to have the documentation sitting alongside the code, but I would argue it's also because Git is good for managing documentation. Other fields have similar types of documentation and content that Git could be be similarly useful for (whether it's worth learning Git just for those purposes is another question).

Reply on news.ycombinator.com