Hacker News Reader

Comment by vxNsr | Hacker News Reader

This is a great idea, both one drive and gdrive have a versions feature but the UI isn’t great. This is terrific UX.

It’s obvious UI on the level of pinch to zoom and mouse input. Hard to come up with but obviously the right choice once suggested.

View on HN

I’d also like to add on a different note, I don’t really get why git can’t support docx, pptx, and xlsx. They’re open standards not binary blobs. Basically just zipped xml.

You can configure it to support it. Git supports configuring different diff programs for different file types. And there are tools to diff docx etc.

For Excel there is this: https://www.xltrail.com/ I haven't tried it but it looks OK.

Can you explain how to do that? I must be missing something because all I could find was merge tool support but no mechanism to tell Git globally that all files with extension "xyz" should use this specific merge tool.

According to this StackOverflow post [1], you'll need to write merge driver. I was looking at this when trying to hack git to use conflict-free replicated data types (CRDTs) as a fallback for a specific document type.

[1] https://stackoverflow.com/questions/23140240/git-how-do-i-ad...

If you write VBA in Excel, there is a free Git extension called Git XL that we maintain which is able to properly Git merge your code directly in Excel: https://github.com/xlwings/git-xl

Can I configure Git such that the merge of Haskell source code (any language will do) with base A:

    add x y = x + y

left B:

    add z y = z + y

and right C:

    add x w = x + w

succeeds without a conflict?

I don't like the example. Unless I'm missing something, all three of these are exactly equivalent, so you could accept any of them as the result of a merge.

But the problem with that idea is that two different people explicitly made a change that looks meaningless. That tells us that we're evaluating "equivalent" incorrectly, which means we don't actually have any remaining justification for picking one over another, and the conflict is hopeless without further input.

The correct merge, in my opinion would be D:

    add z w = z + w

My justification is that if you put each identifier on a separate line like this:

    fn add(
        x: i32,
        y: i32,
    ) -> i32 {
        x
        +
        y
    }

then as far as I know, Git would happily merge B and C into D.

Seems like you’d need a language-aware diff algorithm that can parse the language then diff the AST.

Now if only github desktop had built in support for those extensions/configurations.

Diffing the contents of an Office document is not trivial. See https://news.ycombinator.com/item?id=22222667

Implementing good enough .docx parsing is very very hard/tedious.

For example... .docx sometimes actually contains binary blobs...

Unzip a few MS Office documents and have a go yourself.

These files can contain binary data for embedded objects like pictures.

Reply on news.ycombinator.com