Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git's initial commit

github.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Git's initial commit

#71

Post by Someone »

workingandtired wrote: post #14
benihana wrote: post #12

Is there a reason there aren't any braces around single-line if statements? Is that a C thing? It seems kind of inviting to bugs to me.

It's a C-style language syntax option. If it's only a single line in after the if, the braces are optional. I've also seen it in C++ and PHP. Whether or not it's sloppy is up for debate and just a matter of personal preference.

"If it's only a single line in after the if, the braces are optional."

Not _line_, _statement_. Consider

  if(flag)
    foo(); bar();
and

  if(flag)
    foo =
      bar +
      baz;
That first example always calls bar().

Warning: I haven't tested this, and am beginning to doubt a bit. It must be correct, but why, then, don't I remember seeing this in underhanded C contests? Combining that with macros allows you to hide the semicolon.

Re: Git's initial commit

#72

Post by thret »

MichaelGG wrote: post #29
meowface wrote: post #18

Earlier quoted context omitted.

>I wonder if there are any git sha1 collisions out there in aggregate, say across all of github. Despite the incredibly high number of all commits there must be, I think the chance of a collision is still very unlikely. 2^160 is a pretty big number.

The number of inputs before a likely collision is more on the order of 2^80. Which is still pretty large.

This is comparable to the number of atoms in the universe. Pretty large! We will never see an accidental collision.

Re: Git's initial commit

#73

Post by kzrdude »

6chars wrote: post #32
byteCoder wrote: post #5

Following the tradition of sports, I propose that commit id e83c5163316f89bfbde7d9ab23ca2e25604af290 be officially retired.

Done. Don't ask me how I did it, but you will never see that hash come up again naturally during your lifetime.

it is SHA-1 though, might still be broken during our liftime

Re: Git's initial commit

#74

Post by alblue »

asdfaoeu wrote: post #54
jastanton wrote: post #52

Earlier quoted context omitted.

Does anyone know if the structure of git has changed much? I would like to read this thinking this is pretty close to the current implementation but I would have no idea. anyone?

You can just see the structure with git cat-file -> % git cat-file -p 8c48d1a36c3d11db44c75a431d4f09cb0035222f tree 288c2d5379768f685f391bdbffd31b8965318c63 parent 002ae35061beef02453b7fb1045a50fa2f7f30f8 author Denis Bilenko 1246939605 +0700 committer Denis Bilenko 1246939605 +0700 MANIFEST.in: include libevent.h and libevent-internal.h -> % git cat-file -p 288c2d5379768f685f391bdbffd31b8965318c63 100644 blob 6e543d…

I wrote about the format of git trees (and other object types) here:

http://alblue.bandlem.com/2011/08/git-tip-of-week-trees.html

Re: Git's initial commit

#75

Post by keypusher »

userbinator wrote: post #45
meowface wrote: post #18

Earlier quoted context omitted.

>I wonder if there are any git sha1 collisions out there in aggregate, say across all of github. Despite the incredibly high number of all commits there must be, I think the chance of a collision is still very unlikely. 2^160 is a pretty big number.

There's a table in http://en.wikipedia.org/wiki/Birthday_attack which gives some numbers, but it's missing the 160-bit entry. Nevertheless, even the number of 128 bits hashes required for a random collision are extremely high. In hindsight, it's good that git didn't choose MD5, since collisions for MD5 can be generated almost trivially now. However, the decreasing security of SHA-1 could be a concern for the future.

I don't think commit hash was ever intended to be cryptographically secure. It's just a unique identifier.

> Source control management systems such as Git and Mercurial use SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said about Git: "If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed. [...] Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.

http://en.wikipedia.org/wiki/SHA-1#Data_integrity

Re: Git's initial commit

#77

Post by elwell »

desdiv wrote: post #17
benihana wrote: post #12

Is there a reason there aren't any braces around single-line if statements? Is that a C thing? It seems kind of inviting to bugs to me.

It's pointless to argue over these kind of things. Every major project/company has their own codified code style guide, and if you want to contribute/earn your salary then you must follow that style guide to the T. Here's the relevant quote from the Linux kernel coding style[0]: Do not unnecessarily use braces where a single statement will do. if (condition) action(); [0] https://www.kernel.org/doc/Documentation/Codi…

You can sidestep the braces debate by using a lisp.

Re: Git's initial commit

#78

Post by pdw »

PurplePanda wrote: post #66
kevin_thibedeau wrote: post #16

Earlier quoted context omitted.

In the C grammar, braces denote compound statements. Control flow statements can take any type of statement as their body rather than just the compound variety.

It confuses me that it doesn't work for functions. like int main() return 0;

In K&R C, the function braces serve to separate parameter declarations and local variables:

    int main(argc, argv)
      int argc;
      char **argv;
    {
      int local;
    }

Re: Git's initial commit

#79

Post by sytelus »

guelo wrote: post #51
desdiv wrote: post #17

Earlier quoted context omitted.

It's pointless to argue over these kind of things. Every major project/company has their own codified code style guide, and if you want to contribute/earn your salary then you must follow that style guide to the T. Here's the relevant quote from the Linux kernel coding style[0]: Do not unnecessarily use braces where a single statement will do. if (condition) action(); [0] https://www.kernel.org/doc/Documentation/Codi…

I consider that a bug in their style spec. Single line if statements are known to cause bugs.

That's what I'd thought for may be over a decade. About ~3 years ago I revamped my personal coding style to eliminate as unnecessary baggage as possible. As part of that I stopped using braces for single line if and I'd yet to bump in a bug because of that. Overall I find code looks more compact and cleaner, may be even less friction to read. Nowadays when I see a braces around single line if I get that "oh that's clunky code" feeling in my stomach. Things are worse with C# and lot of Java code where people insist not only having braces around single line if but also have { on its own separate lines.

I think a good language shouldn't have braces to mark blocks in first place. Given indentation,they are redundant most of the times and they just contribute in clunk. This is exactly the case with Python and hence this is essentially a default style and people hadn't be complaining about it's causing bugs.

Re: Git's initial commit

#80

Post by tripa »

vacri wrote: post #56
jonesetc wrote: post #35

Earlier quoted context omitted.

Overloading the term. The OP presumably meant that the source for git was under git source control.

'Hosting' means 'contain', 'serve'. A building can host a department or a convention, and a married couple can host a dinner party, with neither being required to be a webserver or programming language.

To add to that, IMHO self-hosting for VCSs is closer to the original meaning of the phrase than for compilers.
Post reply on HN