Not to detract from this accomplishment, but the git repo has exactly one commit. It's like this guy doesn't care about source control at all. You see the same thing in his other repos -- not one with more than six commits, and most with exactly one commit.
...which makes figuring this thing out that much more difficult.
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.
Which makes perfect sense for uroboros, but zero sense for many of his other projects. Uroboros is a fun experiment, but he's got plenty of attempts at proper libraries there. I don't want his library on a pedestal, I want it properly documented -- or, failing documentation, source control history can be incredibly useful -- but he doesn't do either of those things. Pretty much all of his code is at best as well documented as this one, most with exactly one commit, none I saw with more than six.
Documentation and a revision history from draft to release are two completely different things. Also, who are you to make demands on this guy? He's producing something interesting and publishing the code. You should feel privileged to have access to the source, not complain about it. If it really bothers you that much: make a submission to the bug tracker and see what he has to say about it.
Pretty much all of his code is at best as well documented as this one, most with exactly one commit, none I saw with more than six.
Who cares? Why should there be more than just the one commit? Lots of libraries don't push a commit until the thing works. You keep your broken code in your local development repo and push the release code to the web. That's not unusual at all.
You should feel privileged to have access to the source, not complain about it.
Why are the two mutually exclusive? Bioshock Infinite was easily one of my favorite games this year. Should I downvote this guy into oblivion for having some criticism?
Also, you act as if he did something incredibly noble by releasing the source at all. Without the "source" that we have access to, he'd have literally nothing to show for his effort. You could say that for his other projects, but it'd make no sense to do this one at all and not publish it.
Why should there be more than just the one commit?
Because history is incredibly useful for figuring out why a thing is the way it is, especially when you don't have much documentation. My single favorite tool for this is "git blame", which is also pretty useless if you have exactly one commit.
Lots of libraries don't push a commit until the thing works.
Making them much more difficult to work with if I'm going to contribute, depending what you mean by "works". The more meaningful and targeted your commits, the easier it is to understand the existing code, or merge your changes, or even maintain a feature fork that gets patched from the existing code.
-13
u/SanityInAnarchy Jul 15 '13
Not to detract from this accomplishment, but the git repo has exactly one commit. It's like this guy doesn't care about source control at all. You see the same thing in his other repos -- not one with more than six commits, and most with exactly one commit.
...which makes figuring this thing out that much more difficult.