So, uh, yeah I agree absolutely with you.
Custom LaTeX classes made this more trouble than I was willing to deal with, so I decided to not pursue it further. I suspect Markdown might have similar challenges dealing with this, although given that the "verbose mode" is just HTML, I might be able to make it work.[1]
The print media type has been around for eons, but the @page rules don't support everything I need and are generally absent in WebKit browsers.
How do you merge destructive edits to image files?
In an office environment, modern MS Word gives you a really nice version history, with automatic or manual/named versions, plus multi-user simultaneous editing, with a slick and fast UI. It’s even cross platform - I send a coworker a link to a document, and they can open it and work on Word for Windows while I edit the same doc on Word for Mac or even on the web-based Word.
It’s shockingly good.
While some of the ideas are great, the overall experience was pretty bad. Leaving autosave on often slowed down Word to an unworkable pace and after a few other issues (I'm not exactly sure what, wasn't involved) we just made sure only one person at a time works on the document.
Some other annoying small issues I experienced: when working together sometimes your undo history is gone. I guess that's because someone else edited too and correctly undoing something someone else edited in between is not simple. IMO it's impossible and any system doing merges automatically will fall apart at some point.
Track edits cannot track deleting rows of a table
Wed based word works actually pretty fine, but it misses random features. Adding captions seems not to be supported.
It's the little things...
I use it every day and really haven’t had slowness issues, even when running via Parallels on the Mac side. Of course, typically my docs are <100 pages and light on images.
I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
MS Word as a whole is definitely very far from flawless, but it’s still better than the alternatives I’ve seen, and it’s extremely entrenched. That’s why it’s hard to see “git for office docs”succeeding.
~250 pages, ~100 images, not something I expect a modern computer to struggle with. We used the web version on Linux sometimes, but I think it also happened when we didn't.
>I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
The other way is like git does it, manual merging and conflict resolving. I don't think there's a way around that once you work with enough people together on a file.
Personally for the kinds of documents I work on, I'd rather risk losing my undo history than have to deal with manually merging changes from multiple users.
Plus, without real-time concurrent editing, the changes are much more likely to conflict.
In my experience it starts to creak on large documents with multiple editors. I did a project many years ago where the key deliverable was a large report, worked upon by 3-4 contributors over 12 weeks.
That last week was absolute madness. Document got corrupted, and we tried all sorts of things. We ended up importing the corrupt document into Google Docs, which, oddly enough, did a better job of working with a corrupt Word document than MS Word did.
It doesn't help that there are lots of versions of online Word - there's the one that lives in Sharepoint, the one I get to via Outlook, the one in Teams, and (maybe? somehow?) the desktop Word when editing an online file.
These features are nice and all, but the thing is, most users not only don't care about using them, but don't care about even the idea of them to know they exist, so they continue with the old workflow.
Most of the time its better to get out of the users way, but in cases like this, if you truly do want to get rid of the infinite finals, they need a bit of a nudge
Microsoft word can't even open files from old version of the same software.
None of these word document will be readable in 50 years from now, a text file though.
Most of what bothers me is trying to view, read-only a previous version. Usually I have several Word or Excel documents up on my screen, and it's easy to begin modifying a past version that then becomes the latest. It's not reflex to open a previous version and untoggle autosave. It bites me all the time.. In Office's pursuit to help people avoid losing data, I wind up overwriting what I need to preserve. A lot..
I have not seen manual version names in Word doc history. Maybe I'm sheltered :s
From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.
In my opinion, the following configuration should have been the default with Git:
git config --global rerere.enabled true
git config --global rerere.autoUpdate true
The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.
I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.
The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.
That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.
I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.
Really? One new added line, and one delete/add two lines above it.
it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!
But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up.
Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.
There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.
No, you just add it at the end of the commit chain?
> And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.
git log actually has the --first-parent for this, which hides all of the commits that were merged into the branch, without destroying the history when you try to go back and try to understand why the choices were made. The idealized version of history created by constant rebasing serves neither purpose.
> Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
Agreed, tools that cope poorly with merges should be fixed, rather than forcing people to hack around it by rebasing.
> None of those issues is better handled by merging than by rebasing.
Not quite, rebasing generates more false positives, since it tries to merge every intermediate commit instead of only looking at the end states and the common ancestor.
Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.
In addition to plaintext documents, I have found that a simple JSON diff is also a very effective way to demonstrate changes between 2 complex biz objects. Non-developers can cope with this as long as the differences are visually obvious (red=removed, green=new, etc) and the object graph is reasonably flat. Everything can be trivially serialized to a JSON document, so this scales super well in my experience. We use a port of Google's DiffMatchPatch to generate human-friendly HTML reports of object diffs in our latest administration tools.
Git would be a byzantine disaster for 'everyone else'.
The graph and abstractions involved introduce enormous unnecessary complexity.
Now, 'historical changes for everyone' - yes.
But not Git. Git is very powerful, but ultimately a questionably valuable product in many cases overall. And we've now settled on it, so it's a bit difficult to displace.
Then I switched jobs to avoid touching .docx files ...
The best alternative I've found to generate .docx output is R markdown, which uses pandoc under the hood and let's you program the whole document the way LaTeX would.
And all tracked under CVS with a management/tracking layer on top.
# make command_doc
and the pile of text became a lovely 250 page postcript ready for the laser printer.
I do the same with markdown in Zettlr, which has a nice inline-preview format and can be used by my non-tech partners.
The generated .docx has a limited range of styles, but we see that as an advantage.
docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.
The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed.
Now prepare to spend several hours trying to make sense of the xml. :-p
Definitely binary once compressed, though, and even when extracted not an easy format to parse. It might be XML, but it’s still representing the full complexity of an MS Office document.
I love some of the collaborative nature of Microsoft Teams and CRDT editing Word/Excel, but I'm usually pretty remote. Text over a tenuous WAN connection is ideal.
I work at a government agency and I was /just today/ getting them to review and approve Git and VS Code for our staff use - and pandoc. A couple years ago we never would have gotten open-source software approved. I wish I knew of an equivalent to SELinux or AppArmor for Windows so they could lock down things a semi-trusted application can do. VS Code will be used in a few different departments, but I mostly want it to help those unfamiliar with Git and its CLI (Git Graph is nice).
There's a trick out there to first convert things like Word documents to Markdown, and then do a diff of that intermediate output: https://hrishioa.github.io/tracking-word-documents-with-git/
Pandoc can only do so much. I'm trying to convince my part of the gov to put policy documents we disseminate to staff in a git repo, so we can track who did what and why (based on commit messages). This will be a big step, but thankfully one part of our org is already moving toward version control for IT and data analytics so I'm proposing this and suggesting we hop on their bandwagon. Momentum.
There's a Word template that we commonly use for legal purposes where it gives you line numbers and you write text to align with the numbers. When reviewing it's easy to say "change line 23 to read ....". This - for example - will not translate well through pandoc because the numbers and the text are separate text elements.
There's a market for making pandoc better. Visually translating how elements "flow" from 1 format to another, instead of simply transpiling XML to Markdown.
I'm still excited thinking in a year I might be able to git-blame the legal department for things. Or see a diff from 1 administration to the next.
Some thoughts:
1. Policy makers think they write policy in English (or other human language). But more and more it is the software.
2. "policy engines" aren't going to cut it - we need to introspect code to decide what the code does - and translate that back to policy.
3. at my work the best solution i have got is using unit tests to explain what the policy is based on test comments - and again that's using english and again it's terrible ("best")
I think the real solution is both wider software literacy so that discussion happen "in code" and code that is more like policy (composable functional languages are thus likely to be useful here)
But great to hear you are taking any steps at all - would an HN letter writing campaign to your ministers help?
Worked on a “Git for Word” project [1], which is currently on hold.
The diff part was manageable, though not trivial to get diffs that make sense for prose/regular text.
The hard parts are UX/UI (making Git concepts transparent to “normal” users) and merging. Yet without automatic merging, branching is not very convenient.
Would love to collaborate on this in the future again. Reach out if you are working in this space, happy to share.
Sourcetree is the best git GUI I've used. That could be used as a model.
I think an old-style solution to merging would be fine: output a word file that uses a unique font style to indicate which user made what conflicting changes, have the user edit the document and remove all of the "merge styles", then continue.
Wrapping version control with a non-tech-friendly porcelain could help a lot of people escape user domestication from vendor lock-in.
Luckily, that responsibility is not in my wheelhouse, I just have to live with whatever decisions are made.
So yeah, mass adoption in the consumer space, I don't see that happening.
A revert or a rebase gone wrong and wails of "what happened to my file?"
iirc this was the original pitch for Dropbox
> “Git for everything“ would be a multi-billion dollar startup easily.
Dropbox is valued at 8.5 billion
I like Dropbox, but for documents, 30 days worth of version history is not fantastic.
[1]: https://help.dropbox.com/files-folders/restore-delete/versio...
From Sep 15, 2008: https://www.maketecheasier.com/dropbox-backs-up-and-syncs-fi...
Just to show how useful this is here’s Indian Constitution with amendments as commits:
AIUI, git is already prepared to be that, it just needs diff programs that can handle whatever format. I mean, other than git's interface being its own impediment to non-technical users.
It's not proprietary by definition. A nightmare to implement? Yes.
But definitely not proprietary.
And there you go, a human readable diff.
Most people have no issues navigating a full folder of revisions to get to “Report Final Final draft v3.docx” but anything resembling version control would simply be unused. At corporate level, the version features of box.net, egnyte, and others are rarely used. I'd say most people don't even know they can navigate the revisions until they are in a data loss situation and asking about how to recover a corrupted file (which occurs most frequently with Excel files in my experience)
Version control with online MS Office and Google Docs seems to be going pretty strong.
Which is the next thing. Git works just local and uses servers to sync. The purpose of servers is syncing and not depending on them. From this everything else comes, autonomous usage, speed, reliability, recovery.
I feel like building a Google docs clone for simple text files. Just one feature - versioning (A Time machine like interface) and perhaps add collaborative editing later. I just want to write and store a text document without having to create multiple files. Automatic versioning of snapshots so I can go back in time and refer to any timestamp.
http://www.oilshell.org/blog/2022/02/diagrams.html#text-narr...
https://news.ycombinator.com/item?id=30483914
It's generally not something you want to reimplement ...
macOS Time Machine and Windows Shadow Copy aren't perfect git-based versioning systems, but it's nice something in the general direction exists.
When they introduces this they changed the standard file operations and replaced "Save as…" with "Save a copy" - this was not universally welcomed.
Didgets (recently surfaced here on HN) seems like a sane approach to this, from the file system up. Pretty incredible performance too.
https://didgets.substack.com/p/where-did-i-put-that-file
Sadly not (yet) open source, though the developer is considering it.
Google docs has a similar feature built in too I think.
First thing I do on a new device is setup my mega shared drives - and there is a lot of plaintext files there!
So you won't have a neat revision history, unless you implement something in the pipelines to also convert .docx to something human readable, because .docx and OpenXML isn't.
It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering.
“Git for everything“ would be a multi-billion dollar startup easily.