freghar

man git-revert

Well, do as you like. I personally don't really like those people, but you can't possibly control the community at this level. It's their freedom to do whatever they want and whatever the license allows them to (and your freedom to ban them). I agree on ignoring those people, ignoring their help requests. However you might as well end with the same person posting different links to his repo / tons of bans and new users/proxies. Another thing is - how can you possibly classify a "not allowed repo link"? Will you go through all the commits to find missing infos about authors? What if somebody accidentaly paste such link? ... Or just the "obvious" ones? As I've said - I would simply ignore them. Copying work from others like this was rather common at one time (not only in ancient culture), today's courts about "intelectual properties" give it rather negative image. On the other side - they might not even realize it. Someone without project management experience can easily fall into this category. Almost everyone have tons of pulls and merges in their branches and such person just "wants to keep it clean" and forgets to mention the source in commit message. I would even go as far as saying "it's acceptable as long as the person doesn't claim the work as his/her own", though an author reference is nicer. edit: if it's about some "top 10" or list of *serious* forks, then I agree, some filter should be applied on those indeed

Aye, sir. Simply follow on-screen instructions after creating a github repo.

use "git pull", sir

negative, sir

Msysgit uses "less" pager from GNU coreutils (at least I believe so), which means man less: -xn,... or --tabs=n,... Sets tab stops. If only one n is specified, tab stops are set at multiples of n. If multiple values separated by commas are specified, tab stops are set at those positions, and then con- tinue with the same spacing as the last two. For example, -x9,17 will set tabs at positions 9, 17, 25, 33, etc. The default for n is 8. Git is able to detect available pagers in many ways. It first looks for --pager='...' cmdline option (or --no-pager). If it's not given, it uses PAGER env variable. If it's empty, it maybe does something else and falls to "less" by default (or no-pager if not even "less" is available). That means something like export PAGER="less --tabs=4" should help you. You can put it in your .bashrc (or .bash_profile) file, it might be in msysgit_installdir/etc/ or somewhere there.

Well, you _can_ revert a merge. It's a bit problematic though. The "problem" lies in git's history tracking part of the merging algorithm - see http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt . Simply said, when you merge something and use a "recursive" merge algorithm (2 branches), git looks up the last "common ancestor" of both branches and start doing resolutions from that point (rather than using the project's whole history). Revert is a normal commit. It has no special flags, nor anything fancy, it's _just_ a normal plain commit with reverse changes applied. That means the second merge will think you want to merge only the changes made (on the second branch) from the first merge, not everything again. But you reverted them and since revert is a regular commit, you'll get a lot of conflicts, because you're missing the changes merged (and "silently" reverted) earlier. I'm not able to make an ascii art here, so http://paste2.org/p/591967 -- when you do the first merge (M), everything's okay (from the technical point of view). Say the developer did some fixing in G, H, I and he wants you to pull those changes (N). Git simply takes only those commits into consideration, none of the previous ones are merged. And if you revert the merge (_changes_ made by the merge) somewhere between M and N, ...

"suddenly stops working" is a poor definition of an error. I don't know any interactive merge tool as it would effectively eliminate the merging mechanisms with more than 2 branches, but if you just want to merge changes from those two, you can as well apply a diff of those branches and then "git add -p" it.

That will effectively screw things up on the repo level. --abort is the safest method.

git rebase --abort

Since you asked so nicely; As you may know, a pull is fetch+merge (ie. download objects + somewhat connect several branches). Merge connects two or more branches, so you can just hard-reset to previous state of any of them. Imagine you have your own branch (left) and just merged another one (via pull): | * | M | \\ * * | | * * | | git-reset accepts several referency specification formats, HEAD~1 (or branchname~1) refers to "one commit back" (or "the second topmost commit of branchname"). Thus, when you're at point "M" (ie. your last commit is the merge), you can simply git reset --hard HEAD~1 to get your clean state before any merge. A special syntax can be used for merges, HEAD^ or HEAD^1 means the first parent, HEAD^2 the second, ..., see "man git-rev-parse" (section SPECIFYING REVISIONS) for a complete manual. Another way is to use reflog, something like HEAD@{1} means "HEAD one step back". You can use HEAD@{10.minutes.ago} , which - surprisingly - works as well!

I believe it's the so-called "problem between keyboard and chair" on your side, not "something to implement". Rather big problem.

Different database layout based on a config option? Oh well. My suggestion would be to keep it there for another couple of months until next milestone and remove it afterwards. On the other hand - if somebody forgets a password, how can anyone change/reset it? Making a tool for it would be really good

Why don't you use SSH?

Actually, I'd bet they really do. Or is it really possible to waste 3GB of memory on .. 200 players? Memory page sharing would work with shared libraries (thanks to correct alignment), KSM might be the solution here. I'm not sure how agressively the daemon looks for pages (had no chance to benchmark it), but it's worth a try at least.

Resolved with Vlad on IRC - telnet specification (and most implementations) really doesn't specify and header or "garbage", thus most telnet clients (including MS telnet in winXP) should work with mangos RA. The problem is purely in Putty client. Putty v0.60 doesn't have configurable telnet port (well, it has, it just uses hardcoded 23 anyway, so I was unable to test anything with it), Puttytel allowed me to specify a custom port, but it added a 21-byte garbage before the first user-specified data (in a separate packet), thus effectively breaking any strict server-side data parsing mechanisms (based on raw TCP payload parsing). 0030 ff fb 1f ff fb 20 ff fb 18 ff .. ... .... 0040 fb 27 ff fd 01 ff fb 03 ff fd 03 .'...... ... This bunch of data was sent only once per connection. The garbage above contain telnet options. Putty's "telnet" mode assumes a running telnetd server and sends terminal info data and some other things to the telnet server. Nearly all other telnet clients allow to send those options "on live" via a control sequence, but none of them sends them automatically (unless specified in a config file), thus being able to send/receive raw TCP payload data. Putty's "raw" mode doesn't send anything automatically, so that one should be used, BSD/linux telnet implementations should work fine by default, MS winXP telnet works as well. Any other TCP client can be in fact used (netcat, ...).

What data? Telnet doesn't send any additional data. It uses a standard TCP 3-way-handshake and then simply sends data in TCP payload. Unlike HTTP, FTP, SSH, ..., it has absolutely no protocol header, just data. What can be more "raw"? No TCP header? No IP header? No link-layer (ethernet) header?

Use a classic FIFO (named) pipe and a listening app. When the other end closes (ie. server crash), you can write your buffer to a file. It's probably the most HDD-write-efficient solution.

Well, simply using my brain - all external apps used the "write user and password" mechanism before. Same applies to any application after this change, because a simple printf-like call won't change the whole world, nor make anything "wait" longer for the username/password. Oh, and about the interface - someone should really make a layer-4 communication protocol for mangos, I believe Derex was talking about something.

Well, what's your definition of "closed connection detection"? I don't know how java does it, but it should be similar. In C, we have this nice connect() function, which is able to establish a TCP connection. We have also send() and recv() to write and read data. As you may know, in TCP world, everything needs confirmation, ie. an ACK reply packet, so each time you send(), the kernel send a piece of data and waits for an TCP ACK reply before returning. If the remote side has no listening service bound to a specific port and address, the remote machine's kernel send a TCP RST packet, telling you to "go fish" with your connection requests. Thus, if I'm not mistaken about the return-after-ack thing, you should be able to check for something like ECONNRESET or ENOTCONN. If you detect such error, you can be sure the connection is no longer usable.

Are you sure about that? I guess mangos uses TCP as layer4 for RA, so you should get RST if you try to send something to a closed port.

Same here, more on that "a = 0" and "0 = a" -- it's like ++i versus i++ with typo protection instead of speed boost. Ie. if you make a typo and write (a = 0) instead of (a == 0), it will zero the variable (in some languages), which can lead to hidden bugs. On the other hand, a (0 = a) typo (instead of (0 == a)) would generate a compiler error. IMHO it isn't that useful here to be worth using (and rewriting current implementation), ...

0 in my benchmark is just "cat testfile.tar > tempfile", ie. simple copy without any compression. ... and bzip2 bench just for comparison: level 0 - time 0.032s - size 359342080 level 1 - time 136.705s - size 70803108 level 2 - time 149.345s - size 66297283 level 3 - time 161.906s - size 64188519 level 4 - time 176.707s - size 62853363 level 5 - time 186.112s - size 61895112 level 6 - time 190.964s - size 61174813 level 7 - time 196.208s - size 60686926 level 8 - time 204.045s - size 60246475 level 9 - time 208.749s - size 59798418

about the compression; it isn't a bottleneck (unless you have a PIII CPU). By reducing compression to 1, you actually reduce the raw time needed by a few microseconds, but it may take more time to deliver a larger packet (or larger amount of packets) via client's slow connection. My suggestion is to use ~4 compression level. It's very fast (about 20 times faster than level 9) and it helps a lot with traffic. edit: not sure what compression mangos uses, but those are bench results for linux-2.6.26 tarball using gzip: all times are "user" (ie. no disk read/write times, just userspace processing), size is in bytesTo be honest, I expected a better result.

clean and/or re-checkout your working tree; git clean -fdx git reset --hard if that doesn't help, delete everything except .git/ and do git checkout -qf HEAD