pouët.net

huh? never seen it before :)

that's the v1.00 code (not including 1.01 changes), so yeah, not very up to date either :)

kkapture lives in a git repository, i can push to a public repository if there's demand, but since i got a total of 5 patches to kkapture in as many years, i didn't think anyone cared :)


cookie cube to be precise.

http://gitorious.org/kkapture <- this one's official now :)

nosfe: mother mother my ears bleed problem found & fixed. will be in the next release.

Lol, thanks ryg. I thought I remember you saying somewhere that it wouldn't be able to capture games? Or were you referring to higher end games, because that i'd understand.

It's quite able to capture games, the only problem is PLAYING them in non-realtime. Remember, kkapture works by presenting programs a manipulated clock that doesn't count actual time but rendered frames. So the actual running speed of the game is only dependent on "how fast does one frame get rendered" and the kkapture settings. So good luck trying to be good at a game that runs at a completely wrong speed. :) And most online games will probably die horribly because they simply can't cope when one client's internal clock runs at a different speed than the others'.

But eg. recording a demo run in a game and then using kkapture for making a video out of it works quite well.

http://www.youtube.com/watch?v=iRWEr3hwoq0

This is how it turned out anyway. Playing it wasn't too bad as it's very light on resources, only every now and again the frame rate would stutter a little but didn't make it un-playable. :)

Thanks for making it possible. :)

ryg: Nice! It also warms my heart that you made the correct choice of SCM ;)

Not too happy with git actually. The error messages and docs are plain bad (too much focus on details and too little explanation) and the Win32 port has annoying bugs - one thing I ran into recently: it reported a file as "changed but not updated" and refused to do a fast-forward/merge, even after I did a reset --hard HEAD. Turned out this was due to "core.autocrlf" being on, which I sure as hell never enabled. WTF? If you don't implement it properly, leave it out completely. In fact, yeah, LEAVE IT OUT, period. It's a complete non-issue - all programs dealing with text files that I'd use accept both types of line endings on both platforms.

I very much like the idea of distributed SCM (and I love lightweight branching/merging as a workflow to manage half-complete changes) but Git is way overengineered for what I want it to do. Today I'd probably use Mercurial since it puts more emphasis on ease of use (suits me), but that wasn't mature when I started migrating my private projects from SVN. And Git doesn't annoy me enough to migrate the DB over to Mercurial. Yet. :)

That's not a bug, it's a user-error. First of all, you were prompted in the Git for Windows installer if core.autocrlf should be enabled by default or not. Second, what has most likely happened, is you've somehow checked in a file with CRLF line-endings. This can happen if you check in a file with Windows line-endings on a unix-machine, or a Windows machine where core.autocrlf were turned off. The canonical line-ending format in Git is LF, and if you manage to check in a file with CRLF you'll run into such problems. This is a field in Git that has recently been improved, though. Now you should be able work with files that have CRLF in the repo with core.autocrlf turned on.

I can't comment much on the documentation/errors, other than that they've worked fine for me. Did you read documents like gittutorial and everyday git?

I agree that being distributed is an important factor for an SCM, but I do think that the complexity of Git is well worth it because of the power you get back. The staging area (interactive add etc), interactive rebase, rerere, bisect, you name it. These are tools that make my life easier everyday, because I spent a couple of days learning how they work.

The situation of newline-handling in Mercurial isn't the slightest bit better in Mercurial - they simply haven't implemented any yet (but their plan is the exact same mechanism that Git has, so switching to Mercurial doesn't help you much for this issue). The branching model in Mercurial is also quite annoying once you've gotten used to topic-branches in other SCMs.

If you want Git to be easy to use on Windows, use something like TortoiseGit.

While that might be the case for you, that's certainly not the case for me. Sure, most text-editors handle both new-lines, but the default text editor on Windows, notepad does not. Visual Studio is a bit bitchy about .sln-files not being CRLF; the Visual Studio version selector completely fails to figure out which version of Visual Studio to open a .sln-file with if it doesn't contain CRLF. A lot of text-editors on unix does not support CRLF and end up displaying the CR as "^M", vi being the most famous one. Some unix tools fail to report the correct line-numbers for error-messages (I think asciidoc and some other). So thank you for yelling out bad advice, but we'll leave that feature in.

If you start saying things like that, then basically everything that is weirdly or badly designed and is not working correctly because of that may be considered "a user error" instead of a bug.

Usability is a feature!

Now you're just extrapolating, badly.

Well, sure. This is not a balanced argument by a long shot :)

I quite like git, its philosophy and the github/gitorious community, but you need to be a GNU Rocketscientist to use the command-line tools.

If you took this show on the road, you guys would sooo get laid!

Why must everything be about sex with you? :(

He must be lacking it. ;)

"Did you read documents like gittutorial and everyday git?"
Yep, and that's exactly what I mean by bad docs. A crib sheet of commands to enter isn't documentation - it's just enough information to dig yourself into a hole, but not enough to get you out of it. What I want is actual explanation of e.g. what state the program is actually in when certain error messages appear so I can fix it properly.

"Sure, most text-editors handle both new-lines, but the default text editor on Windows, notepad does not."
Which is completely retarded, by the way :)

"Visual Studio is a bit bitchy about .sln-files not being CRLF; the Visual Studio version selector completely fails to figure out which version of Visual Studio to open a .sln-file with if it doesn't contain CRLF."
How would this ever be a problem if your SCM just didn't do CRLF conversion? How often do you edit and check in .sln files on Unix?

The only way you'd actually run into this problem is between two Windows machines, one with autocrlf on and one with autocrlf off (for example, it might be off because you had to switch it off at some point to get a merge to work).

"A lot of text-editors on unix does not support CRLF and end up displaying the CR as "^M", vi being the most famous one."
That may be visually annoying, but it's not actually a problem. It's not more of a problem than tabs vs. spaces in source files, anyway. Which is something that no SCM tries to fix on commit, which is the right thing to do, because they shouldn't care.

"Some unix tools fail to report the correct line-numbers for error-messages (I think asciidoc and some other)."
I'd call this sort of behavior a bug. Unix or Windows, the presence (or lack of) CRs shouldn't influence line number counting :)

This thing just has tentacles all over the place. Ultimately, it boils down to whether my SCM should know (or care) about the interpretation of the data I hand it, and I think it shouldn't. There's the fun problems caused by mismatches between people with CRLF->LF conversion on and those with it off (and those on Unix where it's always off...), the fact that it needs to guess whether a file is binary or not (which fails sometimes, and it's easy to miss it when that happens if everyone is on the same platform), the fun problem of "hey, I intentionally checked this file in with just LFs and it came out with CRLFs" (mbox-style text file with index in separate file - and suddenly the offsets don't match. Oops). At least for me, this kind of shit is way more annoying than seeing "^M" at line endings in vi should I choose to open a Windows text file with it. YMMV.

"It's not more of a problem than tabs vs. spaces in source files, anyway. Which is something that no SCM tries to fix on commit, which is the right thing to do, because they shouldn't care." <- that's about the worst straw-man argument I've ever seen

Since this might perhaps be my first or second ever sex-related joke on Pouet, I'm going to go with "sagacity can't remember who said what". :)

Anyho, I'm glad to see kkapture on Github.

gloom: Well I kinda got that, I was just trying to sound like a spouse. Never mind :)

Anywho, good work on gittin' it on git, ryg! I think all coders should basically dump their sources on a place like git, but for some reason I think a lot of people still think they're doing something "very top secret" (or, its counterpart, "very shitty and messy") so it cannot POSSIBLY be shared.

I'd put up some of our old sources but I think I lost most of it 3 hd crashes ago. Incidentally, that's another good reason for putting your sources up somewhere. :)

"that's about the worst straw-man argument I've ever seen"
Interesting statement, considering you answer to exactly one of my points, which happens to be the one that's least consequential - excuse me if I don't consider "but vi displays ^M at the end of the line!!!11" a serious problem :)

"Anywho, good work on gittin' it on git, ryg! I think all coders should basically dump their sources on a place like git, but for some reason I think a lot of people still think they're doing something "very top secret" (or, its counterpart, "very shitty and messy") so it cannot POSSIBLY be shared."
Well kkapture has been completely open since the very first version, but usually in the form of source .zips.

ryg: Yes sure, I was just talking in general. But the step of moving towards git is good :)

ryg: Your other points were simply garbage, and only showed that you weren't interested in discussing it, only stating your point of view. But sure since you asked for it, let's assume I bit the flame:


Yes, but it's THE REAL WORLD. That you think it's retarded doesn't change the fact.


You have no idea how often I've seen sln-files with LF-endings, due to it not being produced by visual studio on Windows (hello cmake), or having gone through some translation process before being put in the repo.


If you think my coworkers who work with the Linux-port would accept that, you're crazy. It is a problem, because they end up calling dos2unix to get rid of it, and if they check that in again, we loose all blame-history, making it close to impossible to find if a bug is in a customer-release or not.


While it certainly is a violation of the robustness-principle, I don't think the whole world sees it as a bug. And even if it were, there's lots of tools out there that you don't have the source code to (or where it's very time-consuming to figure out the workings of the source code), so just fixing your new-lines is a much better approach.


And I think it should. Git is a source code manager, and making sure that new-lines are in the platform-native format is IMO a vital part of that. In fact, in a source code manager, a binary file should be the exception, and in Git it is.


You can easily do something like "*.png +binary" in your .gitattributes to reduce the risk (though I've never actually seen the git heuristics fail on real data). Or even better, "data/* +binary". There's also the "core.safecrlf"-config option that can be used to make git add error out if the result of normalization can't reproduce the exact same output. If you're afraid of corrupting precious files, you might want to enable it.

You said that "all programs dealing with text files that I'd use accept both types of line endings on both platforms", and I made the point that this is not the case for everyone. How the lacks of new-line robustness in different tools manifests itself, especially when it's combinatorial, is not trivial to see at first. I could write pages up and down about the pains I've encountered i.e with merge-tools barfing on files with mixed line-endings as a result of some developers use Visual Studio to edit some source files (copy-paste in VS copies the new-lines verbatim when you copy across source files) and some developers use unix-editors, when there's no EOL-normalization. But I'll spare you the noise.

Thread successfully derailed \o/

But wouldn't this break down once you have text-files in your build-process that are different from the platform-native format (i.e. when using cygwin in your build process or sth like that)?

(Disclaimer: Not trolling, genuinely curious)