Git 2.13-rc1 Released

[phoronix]

Phoronix: Git 2.13-rc1 Released

Git 2.13 has stepped closer to being released with today's 2.13-rc1 debut...

http://www.phoronix.com/scan.php?page=news_item&px=Git-2.13-rc1-Released

[ldo17]

Version control is a good argument for why everything should have a plain-textual representation. Yes, you can put binary files into a Git repo, but then how do you make sense of diffs? What if a binary file was changed differently in two branches, how would you merge them in any sensible way?

[cl333r]

Version control is a good argument for why everything should have a plain-textual representation. Yes, you can put binary files into a Git repo, but then how do you make sense of diffs? What if a binary file was changed differently in two branches, how would you merge them in any sensible way?

This comment shows that idiots have a narrow worldview and try to fit anything in it, and if it doesn't fit throw it away.

[TheBlackCat]

Version control is a good argument for why everything should have a plain-textual representation. Yes, you can put binary files into a Git repo, but then how do you make sense of diffs? What if a binary file was changed differently in two branches, how would you merge them in any sensible way?

Great idea. No raster pictures, no video recordings, no sound recordings. /sarcasm

Text files are just one of countless types of binary file. It is a flaw with git that only properly handles on type of binary data, not a benefit of text files. Of course it is possible to have useful, informative diffs for other data types like raster images, packed binary data, or sound files. It is just that git developers couldn't be bothered to properly support them because those aren't the sorts of files they care about.

And even in cases where there is a valid text representation, like svg, textual diffs aren't generally very useful. Most people can't look at a text diff of non-trivial svg file and tell what actually changed, it is much easier to interpret if you rasterize it and take an image-based diff.

[uid313]

I wish they would release a 3.0 version and fix all the inconsistencies to make it easy to use, easy to understand and be predictable and work as expected.

[ldo17]

Text files are just one of countless types of binary file.

They are the only type where diff(1) and patch(1) make sense.

[ldo17]

This comment shows that idiots have a narrow worldview and try to fit anything in it, and if it doesn't fit throw it away.

So quick to resort to the ad-hominems, so slow to ensure brain is in gear before engaging mouth...

[discordian]

@Ido17:
So how would you solve embedding a micro-controller firmware like its common in embedded systems?
Getting it from somewhere external, or recompiling (with separate tools you might not have installed locally) will add inconsistencies, complexities and problems to any build system.

You should ask yourself twice before adding any binary file, but there are use-cases where it makes sense. Some things just cant be properly "merged", even if they have a textual representation, think of a renewed certificate or media files.

[M@yeulC]

Great idea. No raster pictures, no video recordings, no sound recordings. /sarcasm

Text files are just one of countless types of binary file. It is a flaw with git that only properly handles on type of binary data, not a benefit of text files. Of course it is possible to have useful, informative diffs for other data types like raster images, packed binary data, or sound files. It is just that git developers couldn't be bothered to properly support them because those aren't the sorts of files they care about.

And even in cases where there is a valid text representation, like svg, textual diffs aren't generally very useful. Most people can't look at a text diff of non-trivial svg file and tell what actually changed, it is much easier to interpret if you rasterize it and take an image-based diff.

I am pretty sure one could implement a difftool for any type of data. Raster/svg images, odt documents, even the microcontroller firmware mentioned in the comment thread. Maybe git's interface could be extended to make this easier to work with (automatically starting the correct tool, depending on the content), but one can also write a different frontend to git.
The only real argument one could have regarding git's preference for text file is the storage format. I am pretty sure it could be extended with some plugins, but it would likely complexify distribution of the repositories (because of the required dependencies to checkout an object), and I am pretty sure you wouldn't want that (if you are into EEE, that's a pretty good starting point, I think).
That doesn't mean that git shouldn't include more content-aware patching tools, which is debattable, but I am pretty sure git is designed, and meant to be a DUMB versioning system. That is, NOT content aware.

But yeah, we could definitely use more content-aware diff tools (as opposed to patching tools, which everyone should aggree on before including a new one).

Long live git!

[cj.wijtmans]

how to get png diff in terminal.