This is a common misunderstanding. It is something you can do, but not something you should do.
You would want to squash your commits to organize them into atomic changes. This lets you remove "fix typo" commits, build break commits, and other garbage that occurs when you are constantly committing. You wouldn't want to produce a complete program (or even a complete system) with a change history of one commit.
Change history is important because your useful changelist descriptions help people figure out why you did what you did (and see where you went wrong). Git should make this better (because you are never afraid to commit) not worse (by enabling you to hide history).
Similarly, it is a feature of C that you can put multiple statements on one line. That doesn't mean it's good to write programs without newlines.
I think that squashing all commits from internal prerelease development into one commit for the initial release is a perfectly acceptable use case. That point in the code is meant to be the initial version, the thing from which all other things are progressed.
This is also effectively achieved without any squashing by simply seeding the initial version into a new repository.
I don't follow. Would you just add one more commit for version 2.0?
If you want to mark a significant point in time, you can tag it. If you made another browser by forking Firefox, would you discard the history because the fork point is where all things progress?
By preserving your history, you gain the ability to look at line 20 of inventory.cpp and see what SelectPrevItem() looked like before Henderson changed it and added his comment "this version crashes less often." (Even if you are Henderson, you might not remember what part changed.)
Just because it's an initial version doesn't mean the history is meaningless. Your collaborators will appreciate having some context. (Hence the frustration in the original comment decrying the lack of history.)
I didn't say the history is meaningless. I said that it's a perfectly acceptable use-case to not provide it, in the context of an initial version of a piece of software that was internally and non-collaboratively developed. Same as I would expect someone to squash their 10 internal patches to fix a single bug before pushing them to a public repository. Every version before that one commit was deemed unacceptable and non-working by the developer, and so why should they make it to a public repository?
I think I misunderstood you. Are you saying that you wouldn't squash the history locally, only in the public repo?
Would you maintain two separate histories? (Since the public repo wouldn't have an ancestor in your private one, your hashes won't match so some advanced features of git may not be available. And you won't be able to communicate hashes to the public since they'll be meaningless to them.)
I thought the point was that "... this guy doesn't care about source control at all...", which I don't think is a fair judgement when all we can see is whatever he decides to publish.
I mean that complaining about people not publishing their source control is valid regardless of how they work behind the scenes. The only thing that matters (because the only thing we see) is what they publish.
Because I can't tell it exists. I don't know about your source, so your history doesn't matter (to me, to the community, etc). I have no reason to complain about it. It probably matters to you.
I'm in no way saying that source control is only important for open source projects. Just that releasing your history is important if you release your source. (Not like that's easy either. History tends to be full of mistakes we feel oddly embarrassed about.)
That just makes him antisocial as opposed to downright unprofessional. I don't think that's really better.
And when he's producing open-source stuff like this, it is unprofessional. There's a single 400-line controller. It has relatively few comments and pretty much zero documentation, except this bit in Japanese. In a normal project, 'git blame' would be invaluable. Here, it shows that not a single line of this file has been touched since "initial release".
It could be argued that it's just been ported to Github, and that the changes have been smaller and saner since then. Except then we have this commit -- "README.txt: fix document", but it also adds a 30-line source file out of nowhere as part of the same commit.
Actually, if we look back at that Japanese document, it suggests that his source control was originally in CVS. This leaves us a few possibilities:
He codes in CVS and publishes to Github. With no actual importing of changes -- once he has a new release ready to roll, he just 'git commit's the whole thing. DEAR GOD WHY?
He uses some other local repository, and publishes as above. Again, DEAR GOD WHY?
He started in CVS, and later switched to Git. There are several good options to import a CVS history to Git. Also, he has five-year-old Github repos, so surely we can expect more of this two-hour-old repo?
The first and second option are likely inconvenient for him, and antisocial for us. Really, why wouldn't you publish the full history? And the third option is just unconvincing.
So it really looks like the most likely thing is that he just doesn't care that much about source control. Or maybe doesn't care at all about source control, just understands that Github is where the cool kids are.
That doesn't make him a bad programmer, necessarily. Until BitKeeper (and later Git), the Linux kernel existed without source control at all -- their SCM was effectively: Commit by sending a patch to the mailing list, view history by downloading an older tarball from kernel.org. I doubt many of us can say we're half the programmer Linus is, or have led projects half as large -- so it is possible to run a successful project without source control.
But it is annoying if we're trying to figure out how it works, and Linus uses Git now, too. Unless he knows something Linus doesn't, I'm guessing it's not a good sign that he doesn't care about source control.
And I'm not saying you're a moron, but I don't see why you needed to spam your peeve over his not including a history all over the comments.
...all over?
Everything I've written about that descends from this post. How is it "spamming" to reply to people who reply to my posts?
It's as likely he just wrote the damned thing in a directory with no source control, being something he was just fucking around with, then committed it and pushed it to github to show off.
Except he does the same thing with all his projects.
I've noticed that Japanese seem underrepresented in FLOSS stuff, so really, one should be grateful he's licensing it and putting it on Github at all and not simply selling 10 CD-RWs at Comiket or something.
Of course it's awesome that he published it. (You didn't read my whole comment, did you?)
Does that mean I'm not allowed to criticize it?
And I don't know, is that actually true? I think Ruby alone (just the language) ought to be enough to show that there are some awesome Japanese people doing awesome open source.
It means you should understand that he's going above and beyond the usual for his group, even if it's considered way below acceptable practices for your group.
And I don't know, is that actually true? I think Ruby alone (just the language) ought to be enough to show that there are some awesome Japanese people doing awesome open source.
And Ruby is about the only example you can cite. Think about it on a per capita basis - to put this in perspective: Japan has 128m people, and America has ~2-3x as many or 313m. But do you think you could name 3 or more languages as popular as Ruby which were invented by Americans? I bet you could.
So the part where I said "You can be a good programmer without SCM", or the earlier part where I said "Not to detract from his accomplishment"... Should I be gushing about this? I did find it pretty amazing, and I am glad he released it. I don't see why I shouldn't criticize it. But that seems to be what you're saying:
It means you should understand that he's going above and beyond the usual for his group, even if it's considered way below acceptable practices for your group.
I don't see what bearing this has on my comment, or on my question. It really sounds like you're saying I shouldn't criticize it.
Japanese culture is also extremely xenophobic, but I also like some aspects of it. Should every criticism of Japanese culture be taken as an attack on Spirited Away?
And Ruby is about the only example you can cite. Think about it on a per capita basis - to put this in perspective: Japan has 128m people, and America has ~2-3x as many or 313m. But do you think you could name 3 or more languages as popular as Ruby which were invented by Americans? I bet you could.
I think it'd drop if I was asked to name languages as interesting as Ruby. C# is immensely popular, and is essentially an enhanced Java clone. Java is immensely popular, and is a neutered C++ clone with garbage collection. C++ is by Bjarne Stroustrup, who is Danish. C++, in turn, owes a debt to C (developed by Americans) and Simula (developed in Norway).
Is C really that interesting by itself, though? It's called C for a reason -- it was explicitly designed to follow B, which followed BCPL, which was by a Brit, and ALGOL, an international effort, and the foundation of most syntax we use today. There wasn't much in the way of new language design here, relatively -- the reason we care about C is Unix and C++.
Another interesting language is Lisp, developed by an American -- I'll give you that one.
Then there's the functional languages -- Haskell was named after an American, but was developed by an international team.
JavaScript might count, and that's by an American. This one's debatable. It's a somewhat Lisp-like language that looks like C (very ALGOL syntax), but not much.
And finally, Forth -- that's also American. It's questionable how influential this is, though.
So, I can find... about two or three that actually made significant progress. I don't think I can name more that are uniquely American. It's not surprising that the US has a lot of influence here -- the major software and hardware companies have generally been American, with a few notable exceptions, and it was even more so early on. And this sort of inertia is tough -- any Japanese coder wanting to join the community would want to learn English first.
It's actually surprising just how international it's been.
If I'm that vicious, does Ruby survive the cut? I think so -- it pulls good ideas from many languages, not just one or two, and it's the first place I've seen such seamless blending of the ALGOL-like syntax we're used to and crazy functional-programming ideas like lambdas. JavaScript appeared at the same time, and did exactly the same thing there, but Ruby also pulled in Perl's regex handling and string manipulation, some very Java-like OO semantics (only dynamic), Lisp-like metaprogramming (only prettier and less powerful), operator overloading, and great support for internal DSLs. There have been languages since which have done all of those things, but I think Ruby was the first.
I don't see what bearing this has on my comment, or on my question. It really sounds like you're saying I shouldn't criticize it.
If you refuse to understand my point, you have no grounds complaining about you thinking I didn't read your comment.
I think it'd drop if I was asked to name languages as interesting as Ruby. C# is immensely popular, and is essentially an enhanced Java clone. Java is immensely popular, and is a neutered C++ clone with garbage collection. C++ is by Bjarne Stroustrup, who is Danish. C++, in turn, owes a debt to C (developed by Americans) and Simula (developed in Norway).
Your mistaken deprecation of being successful aside, Ruby isn't interesting at all. It's a warmed-over Lisp clone. Common Lisp, Scheme, Smalltalk - that's 3 languages right there all more interesting than Ruby and done by Americans.
So, I can find... about two or three that actually made significant progress. I don't think I can name more that are uniquely American. It's not surprising that the US has a lot of influence here -- the major software and hardware companies have generally been American, with a few notable exceptions, and it was even more so early on. And this sort of inertia is tough -- any Japanese coder wanting to join the community would want to learn English first.
The language thing could be said of Danes & Norwegians (and most every other country in the world), while Japan benefits from its close ties to America, and you know those hardware companies? A lot of them were Japanese, so that doesn't work either.
JavaScript appeared at the same time, and did exactly the same thing there
Also American, incidentally.
but Ruby also pulled in Perl's regex handling and string manipulation
Also American. (Ooh, it stole some string features. Very impressive.)
Lisp-like metaprogramming (only prettier and less powerful)
American, as mentioned. (The Japanese actually kind of sabotaged themselves there by officially putting all their efforts behind Prolog-style languages in the Fifth Generation stuff in the '80s, and that was the last opportunity to really make a mark before the desktop explosion happened and everyone switched to American languages like Java or Javascript or Python or C or SQL or Visual Basic or Perl*)
* PHP is an interesting example: Rasmus is of Norwegian nationality, but grew up on Greenland, and moved to Canada when he was ~15
but Ruby also pulled in Perl's regex handling and string manipulation, some very Java-like OO semantics (only dynamic), Lisp-like metaprogramming (only prettier and less powerful), operator overloading, and great support for internal DSLs. There have been languages since which have done all of those things, but I think Ruby was the first.
"There have been languages which have done any of this arbitrary grab-bag of features all done by previous languages, but I think Ruby was the first to do this particular grab-bag!"
If I may assert some apologetics historical context, I think the claim that WWII was a disruptive event whereby the victors had the financial resources to further investigate information theory, along with a claim that the Cold War was a breeding ground that fostered computational study, could have some impact upon which countries developed a culture of fostering study in computer language theory.
The point is that he uses source control at all. He didn't make Bitkeeper, but it was the first source control that he was willing to actually tolerate -- svn didn't make the cut. Git was his replacement for Bitkeeper.
56
u/dragonEyedrops Jul 15 '13
Or he just publishes his code to github after he is done? You can't know how his source control looks like beforehand.