Wyk3d

The error is not fatal and doesn't cause any problems .. just wait until github fixes it, it's not a big deal.

That looks like you had uncommitted changes ? Did you read the FAQ ?

Please don't post stupid hacks for crashes, they just make fixing the real problem behind the crash much harder. Instead post the crash logs and try to find ways to reproduce them. If you must use them, keep them for yourself at least and remove them from time to time to provide new information on the problem.

And here's a list of the "videos" from the book: http://www.gitcasts.com/episodes

Should be fixed in [6930] thanks to DasBlub.

Thanks, added in [6930]. Do you know how those invalid arenateams got in your DB though ? Normally a patch like this would be considered a hack without all the WHY and HOW parts answered, but in this case it's fine since we can't trust the validity of information taken from DB anyway.

Word......

How to use two working copies at the same time without downloading the changes twice ? On linux it's fairly simple. There is a tool called git-new-workdir. In effect, you can fetch from one directory and use it in the other, you can create a local branch in one directory and switch to it on the other, you can make local commits in one directory and they will appear in the other, you can work on two things at the same time without having to constantly rebuild when you switch to the other one, you save hard disk space and time by not downloading the same thing twice. On windows XP, this tool doesn't work because it uses symbolic links (which are only available in Vista, and even there ln -s may not work). The same effect can however be obtained on XP if you use NTFS. It doesn't have symlinks, but it does have hard links and junctions which combined work in almost the same way. To be able to use these you need some shell extensions. After you've installed those you get a "Copy-Paste like" interface in the context menu. By right clicking it, you can pick a file or a directory as a link source and then, in another location you can drop either a hardlink to that file or a junction point to that folder, by selecting it from the context menu (right click). With this tool we can basicly do the same thing that git-new-workdir does (if old_workdir is the folder where the repository we want to copy was cloned): - create the folders new_workdir, new_workdir/.git, new_workdir/.git/logs - copy the file old_workdir/.git/HEAD to new_workdir/.git/HEAD - make junctions in new_workdir/.git to the hooks, info, objects, refs folders from old_workdir/.git - make a junction in new_workdir/.git/logs to the refs folder from old_workdir/.git/logs - make hard links in new_workdir/.git to the config, packed-refs and (if they exist) the remotes, rr-cache, svn files from old_workdir/.git - in new_workdir run: git checkout -f master <- or any other local branch, preferably not the same branch you're using with the other workdir - done! Notes: - the only bug I've found so far is that sometimes the packed-refs file seems to revert to a normal file, not a hard link resulting in changes to local branches not being seen in the other repo, but at least fetched objects are still common. So far I've fixed this by deleting the file and making the hard link again, but it may not be the appropriate action if you want to preserve some changes done to those refs. - if you have the same local branch checked out in both workdirs, when you make a local commit, the branch on the other workdir will be affected and it will look like you reverted the changes on the other workdir.

It did indeed have something to do with pets. This particular form (by far the most common) of the crash should be fixed in [6928]. It's a complex problem that still needs more work though. Thank you the reports, they've been quite helpful.

You could just read the src/shared/revision_nr.h file ..

Closging the thread because discussing about illegal public servers is not welcome here. This does not affect MaNGOS in any way.

Update your git version.

I agree, but depending on how you look at it, it's the biggest problem, a showstopper if you will. Even if you work hard for many months and manage to reverse engineer 100% of the warden code, it will still be useless in an open source project. If the people writing the cheat programs would know how warden detects them, and more importantly, would know when detection support for their cheat is being added to it (on official they only know this after someone has been banned), they would easily be able to keep themselves undetected and it would be much harder to catch people using these tools.

The difference is, fixing the player problems would require a lot more changes to other systems. It should be easy to make a config option to do the updates either in Map::Update or ObjectAccessor::Update though so as long as it's done in ObjectAccessor by default it would be fine.

That is not an announcement. The release date is yet to be determined.

#0 Map::Update (this=0xb3d4fc30, t_diff=@0xad7ff1d8) at ../../../src/game/../framework/Utilities/LinkedList.h:442 LinkedListElement * next() { return hasNext() ? iNext : NULL; } Yeah it worked, thanks. Hopefully it won't crash anymore in [6850].

Yes, we're getting so many patches for 3.0.3 that we can hardly manage them :lol:. I think it would be fine to post 3.0.3 patches alongside others in the Under Review section, maybe mark them as [patch 3.0.3]. We did say that patches are welcome but I haven't seen much. That doesn't mean nobody else worked on it, just that they didn't share and/or try to work together.

Haven't tried this myself but I think it might work according to the manual http://www.kernel.org/pub/software/scm/git/docs/git-revert.html. If you look at the gitk history, where you merged with that branch you should see the merge commit for the pull (sha A) having two parents, one from mangos/mangos (sha B ) and one from blaymoira/mangos (sha C). Try the command:git revert -m B A

1. all your commits are local and don't affect what other people see until you push those changes to some remote repo2. you can "extract them in a patch" by just doing git diff origin/master > file.patch 3. if you apply or write multiple patches you can commit each one in a separate commit and you can extract a patch for just those changes anytime. 4. you can revert individual patches with git revert

Yes .. from the git manual, "This operation can fail with conflicts; you need to resolve them by hand in the working tree.". So maybe it's better if you just learn to commit your local changes and then you can use mergetools to resolve the conflicts.

How to resolve merge conflicts ? You can do it with git diff by searching for the conflicts and editing them but there are easier ways to do it. If the "git mergetool" command is called after a failed merge, based on how it's configured it will start one of many tools to resolve the conflicts. I'll present some of the available tools, how to install, configure and use them. You can try one of the following and see which one works best for you: 1. KDiff3 (not kdiff or kdiff2) - http://kdiff3.sourceforge.net/doc/merging.html - has a fairly good visual interface and works on both windows and linux - you can get it from http://sourceforge.net/project/showf...ease_id=501369 - to make sure git can find it, for example on windows if you installed it to "c:/Program Files/KDiff3" git config mergetool.kdiff3.path "c:/Program Files/KDiff3/kdiff3.exe" <- either that or you could add c:/Program Files/KDiff3 to your path - make it the default mergetool git config merge.tool kdiff3 2. vimdiff - opens a text mode GUI with a three way split - haven't tried it on windows, but should be availabe on most linuxes - this is the default merge tool if it's installed 3. Perforce Merge http://www.perforce.com/perforce/products/merge.html - good visual interface, has both windows and linux versions - download the perforce visual client from http://www.perforce.com/perforce/downloads/index.html - install it - add it as custom merge tool (if you installed it to c:/Program Files/Perforce/) git config mergetool.p4.cmd ' "c:/Program Files/Perforce/p4merge" "$BASE" "$REMOTE" "$LOCAL" "$MERGED" ' - make it the default mergetool git config merge.tool p4 4. Tortoise Merge http://tortoisesvn.tigris.org/TortoiseMerge.html - good visual interface, only works on windows - download and install TortoiseSVN from http://tortoisesvn.net/downloads - in "C:\\Program Files\\TortoiseSVN\\bin" create a file named TortMer.bat and add the following: @ECHO OFF TortoiseMerge.exe /base:"%PWD%/%1" /theirs:"%PWD%/%2" /mine:"%PWD%/%3" /merged:"%PWD%/%4" - add a custom merge tool to git that runs this batch file git config mergetool.tortoise.cmd ' "cmd.exe" "/CTortMer.bat" "$BASE" "$REMOTE" "$LOCAL" "$MERGED" ' - make it the default mergetool git config merge.tool tortoise 5. Beyond Compare 3 http://www.scootersoftware.com/moreinfo.php?zz=moreinfo_merge - good visual interface, has both windows and linux versions, costs money if you want more than a trial version - download and install BC3 from http://www.scootersoftware.com/download.php - add it as custom merge tool (if you installed it to c:/Program Files/Beyond Compare 3/) git config mergetool.bcomp.cmd ' "c:/Program Files/Beyond Compare 3/bcomp.exe" "$LOCAL" "$REMOTE" "$BASE" "$MERGED" ' - make it the default mergetool git config merge.tool bcomp

And you should do something about that attitude if you want to learn anything by the way. Just assume every time you have a problem it's your fault even if it's not. Read everything again, do it again from scratch, maybe find the stuff that aren't obvious and change them a little, see what happens. If all else fails you can always ask ..

If you didn't have any uncommitted changes before the merge, the only ones you should have after are the conflicted files if any. Just run gitk to see them or git diff.

Just pull them one after the other ? If there are merge conflicts you have to solve them though ..

The problem is that development is a complicated process that people don't really understand so they try to fill in the gaps with whatever they think fits. This is an entirely normal phenomenon but by the time they figure out what they added was incorrect, they forget where they got that information from. So they end up making rants about things that are indeed bad, but have nothing to do with the real world. I already wrote a lot of details on why things were done this way. Several times even. You can look them up if you're interested. The arena patch is working but still not ready to be included, it had a short review and after that it could have been added but problems were found in it that are being worked on (and by problems I mean mostly things the end user doesn't know or care about in the short term, but could be bad in the long term). A short TODO list is included so you can go ahead and help if you want to get it done faster .. we can even give contributor access on that branch to people who want to help.