git revert is the wrong answer. git revert makes ANOTHER commit to undo the changes of the first commit. Why the hell do you want to preserve mistakes in the history? The accepted answer is more correct than git revert. This is git.
The reversal SHOULD be a new commit. Undoing commits on a distributed SCMs means you're effectively deleting history.
This outage is being going for over an hour now but, according to Amazon, their services are green all across the board with "increased error rates". Almost feels like they're trying to cheat out their own SLAs.
It seems obvious to me that a small string sequence could be identical from two differents long original texts. Even it happend, the hash function is NOT the original message, and a collision could happen. It does'nt mean that the two original texts are the same. Am i right ?
Yes. A hash is nothing more than a function mapping data of arbitrary size to an output of fixed, smaller size so by definition you can always construct two inputs which yield the same hash. What makes crypto hashes secure is that this is normally very, very hard to do - that is, given a hash generate an input from it.
Np. Sorry if i came across as pedantic - i though the distinction was important because from reading other threads people don't really seem to understand what SHA1 is supposed to and not to do.
It doesn't - unless you allow it, of course. You can destroy history on you local repository all you want but the upstream one will reject it unless specifically permitted.
But i don't quite get it yet. git push --force is not supposed to be a straightforward, or even common operation, as it can destroy history. And selecting/enforcing a ranching schemes is a problem you'll run into with every other SCM in existence.
I'll admit that git gives you enough tools to shoot yourself in both foots if you're willing to, but it also provides very straightforward, easy to use commands for everyday operations. Anyone proficient in SVN can pick up git in 20'.
I've been using git on and off for a while and, honestly, it is the most developer-friendly SCM out there. Which kind of problems do you refer to?
My main pet peeve with git is that it really doesn't work well with big repositories, large number of users, or binary files. Other than that it is a joy to work with.
FWIW, you're correct, but "hash function" englobes much more than that. Technically, a CRC is, by definition, a hash function. So is bit parity.
A cryptographic hash function has the properties you mention, plus the fact that it must not be easily reversible and uniformly distribute results over its entire output space.
Git hashes objects (commit, trees, blobs, tags) instead of individual tags. If you managed to somehow create, say, a commit with the same SHA1 as another existing in a repository pushes to it would be simply ignored.
Slashdot Mirror
There are several ways of proving 0.999... = 1. Two very easy ones:
1) If 1/3 is 0.333..., what is 1/3 * 3?
2) What is the difference between 1 and 0.999... ?
0.9999... Is exactly 1.
I know it doesn't feel like, but the guy's been in the POTUS seat for little over a month now. We just don't know.
It is kinda cute how the video narrator gets so excited about that.
git revert is the wrong answer. git revert makes ANOTHER commit to undo the changes of the first commit. Why the hell do you want to preserve mistakes in the history? The accepted answer is more correct than git revert. This is git.
The reversal SHOULD be a new commit. Undoing commits on a distributed SCMs means you're effectively deleting history.
In my own personal experience, good failover is not as easy as expected. Never.
It is kinda cute when people try to think "cloud storage" in terms of HDDs alone.
This. All jokes aside S3 is normally a great service at a very competitive price.
Grrr, it's "someone else's". Thanks phone.
AKA "just someone's else computer".
This outage is being going for over an hour now but, according to Amazon, their services are green all across the board with "increased error rates". Almost feels like they're trying to cheat out their own SLAs.
It seems obvious to me that a small string sequence could be identical from two differents long original texts. Even it happend, the hash function is NOT the original message, and a collision could happen. It does'nt mean that the two original texts are the same.
Am i right ?
Yes. A hash is nothing more than a function mapping data of arbitrary size to an output of fixed, smaller size so by definition you can always construct two inputs which yield the same hash. What makes crypto hashes secure is that this is normally very, very hard to do - that is, given a hash generate an input from it.
Np. Sorry if i came across as pedantic - i though the distinction was important because from reading other threads people don't really seem to understand what SHA1 is supposed to and not to do.
It doesn't - unless you allow it, of course. You can destroy history on you local repository all you want but the upstream one will reject it unless specifically permitted.
Think for a second how good of an actor you have to be to deliver that line and make it instantly memorable. Even more, he ad-libbed it.
May he RIP.
I love the guy but he's been on plenty more than Predator and Aliens.
Personally i though he was a damn underrated director. The Greatest Game Ever Played is a solid movie, but Frailty is a bona fide modern classic IMHO.
But i don't quite get it yet. git push --force is not supposed to be a straightforward, or even common operation, as it can destroy history. And selecting/enforcing a ranching schemes is a problem you'll run into with every other SCM in existence.
I'll admit that git gives you enough tools to shoot yourself in both foots if you're willing to, but it also provides very straightforward, easy to use commands for everyday operations. Anyone proficient in SVN can pick up git in 20'.
This. It is safe to say SHA-1 is effectively broken at this point and existing users should start migrating to better alternatives.
But let's not panic either. The world is not crumbling down to pieces anytime soon.
Seriously? How hard it is to type git revert?
I've been using git on and off for a while and, honestly, it is the most developer-friendly SCM out there. Which kind of problems do you refer to?
My main pet peeve with git is that it really doesn't work well with big repositories, large number of users, or binary files. Other than that it is a joy to work with.
Pretty sure they do.
FWIW, you're correct, but "hash function" englobes much more than that. Technically, a CRC is, by definition, a hash function. So is bit parity.
A cryptographic hash function has the properties you mention, plus the fact that it must not be easily reversible and uniformly distribute results over its entire output space.
...instead of individual files...
Not really: http://marc.info/?l=git&m=1156... .
Git hashes objects (commit, trees, blobs, tags) instead of individual tags. If you managed to somehow create, say, a commit with the same SHA1 as another existing in a repository pushes to it would be simply ignored.
Check the link on my parent post again.
Signed with whichever hash GnuPG supports. That includes the entire SHA family up to SHA-3.
Also, when a commit is signed it becomes bundled with it, which means its associated SHA-1 hash will change.