This might be not as crazy as it sounds, as I recently learned:
A few weeks ago, there was a short presentation about Git, targeted at non-programmers such as graphics and web designers. After the presentation, one of the designers (who apparently already knew about Git) stood up and criticized the presenter for not going deeper into branches and auto-branching.
Of course, the presenter intentionally left that topic out, in order to not confuse all those Git newbies.
However, the designer argued that this is what would make Git interesting for designers. He said that all this diff/commit/push/pull stuff was boring for designers where a "diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway. But branching has the power to reflect the natural work-flow of a designer who permanently goes back to previous versions in order to try different variants. Reflecting this via "Save as ..." (and naming files accordingly) is very cumbersome.
Although I personally think this guy overrated the power of branches, this might change once the Git user interfaces becomes simpler to use, more targeted to designers (rather than just software developers) and better integrated into graphical tools like Gimp, Inkscape or even Photoshop.
I use Git, and its a wonderful piece of software craft indeed, but it does not have Windows/Mac clients, that designers often use, as their base OS.
A decent usable frontend for Git, on platforms other than Linux too, needs to be developed, for it to be usable by designers.
Edit - I meant to say officially supported frontend and support for other oses by git.
Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git. I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.
(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)
GitX is available at https://github.com/brotherbard/gitx/downloads (Get the experimental branch)
Git Tower is available at http://www.git-tower.com/
Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers).
And Giggle (http://live.gnome.org/giggle).
Windows is the only OS lacking a good client, but I use GitX for Mac every day, as do the less technical "devs" at our Startup.
I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.
I use TortoiseHG and I expected parity.
Given that git was created for hosting the Linux kernel, it should be obvious why it's not a first-class citizen.
And of course, the command line option through msysgit is great.
Git Extensions (http://sourceforge.net/projects/gitextensions/) is actually really, really, good. The UI is well-designed and fast. Wish more people knew about it.
I'd love to see the OSS community develop better source control software targeted towards designers. :)
That's what the commit comments are for.
BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)
Both problems seem "hard but solvable" to me. Isn't there software doing that already?
Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.
What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?
And the most important thing: How to display that in a way to be easily understood by non-technical people?
For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.
"merge"
Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.
So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.
However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.
Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.
Too bad it's not Free Software ...
Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.
In other words the document have many states at once depending on what you make visible or not.
On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.