[Zak]

A great many successful tech companies can be described in terms of more consumer-friendly Unix tools.

Slack has the better part of a billion dollars in funding for what's essentially resource-hungry IRC with pictures. Dropbox does little you couldn't accomplish with a server and rsync.

What I'm really eager to see is git for everyone else.

[nlawalker]

>> git for everyone else

When you simplify and generalize git to the point where "everyone else" can use it, you get Apple's Time Machine and Windows' File History. I'm not that familiar with Time Machine, but if File History had a more visible interface that you could use to easily "checkpoint" individual documents or directories on demand, you'd pretty much be there.

Branching is too complicated for most people to work with and overkill for most scenarios.

[exikyut]

What would "everyone else" do with Git? It's a Rube Goldberg solution implementing a highly specific set of ways to do file versioning.

Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/

[Zak]

People I know who definitely have this problem tend to work in creative fields - especially musicians and (digital) visual artists. They almost universally have a bunch of files with names like project_final2_revised_reallyfinal3_with_edits_from_sally.psd.

Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.

[exikyut]

Ah, that. Yes, absolutely I'd love for a solution that fixes that.

It would definitely need to work with large files though, which categorically precludes Git.

The first point, I think, would be building a delta engine with case-specific code for the most common ubiquitous file formats, like docx, xlsx, psd, etc. Of course it wouldn't be able to be perfect with everything but it would certainly be better than eg just recompressing each version or something equally naive.

The UX would be the next major hurdle. Time Machine is a good example of the kind of simplicity that would be needed, but it would need to be a have a bit more surface area to be applicable and useful to all scenarios.

One other feature that comes to mind, which would be incredibly difficult to get right but probably critical, would be useful version diffing. I think keeping this simple and just building something that can do $anything->SVG (with maybe cheats where bunches of the SVG is mostly just a bitmap in certain cases) and then doing something fast on the SVG (and/or its bitmap contents...) would probably be the most viable target.

[Zak]

It think it does need branching and collaboration. There needs to be a way for Sally to contribute those edits, and they might not actually make it in to the final result.

No doubt there would be a learning curve. I think that's OK. The target market here is serious users who already dedicate time to learning professional tools like Photoshop.

[exikyut]

Oh no. Now you need full file format parsing so that you can resolve merge conflicts.

:(

That would take years to get anywhere with ._.

The diffing idea I suggested above is just manageable, a la macOS Preview, with hacks. Branching requires folding-back-in, and that's not just a case of "A or B", it's a case of "A, B and C conflict with D and E, while F G and H are okay," where I could then say "save B and E but drop F". If B is a layer, E is an imported asset and F is a custom filter... you get the picture. You need a reimplementation of Photoshop (halting problem).

:/

Sad that everyone hates GIMP.

But... hmm, this could get folded into Blender, and then make the rest of the industry jealous.......

[antoineMoPa]

What about grep/sed/find for everyone else?

Also, to get more ideas:

   echo "Make a startup with "$(ls /bin /usr/bin | sort -R | head -n 3)