freghar

I suggest you to read http://eagain.net/articles/git-for-computer-scientists/ so we'd know what exactly do you mean. I can't guess what you mean by "tree", if it's a tree object pointed to some commit, or just a "working tree", branch is nothing more than a "pointer" to a commit (in Git), so your expression doesn't make sense for me. btw .. try that thing with registering a new repo, there's a short step-by-step guide IIRC

You probably missed the fact that your fork on github is just your remote repository. All your commits goes to your local repo on your HDD. You probably need to push changes (commits<-trees<-blobs) to the remote .... Try creating a temporary repository on github, it should give you instructions after it's creation (those are the same as for fork).

There was such topic already ... git has some proxy support itself, see manpage of git-config for "proxy".

Hello everyone, as some of you may know, I set up a git-svned repository http://github.com/freghar/mangos-svn-archive/ --a mirror of the old SVN up to r6767 for archival purposes-- some week ago and I need a little help with it. There was a topic on the old forums saying which revision is for which client version, however those infos aren't accessible now. Has someone here some tips/infos on that? I'd also welcome an exact specification on which rev is the actual milestone, I can guess from commit messages, but such specification would be nice (old trac is down, so ...). Thanks, Freghar edit: yes, I can see some on http://mangos.svn.sourceforge.net/viewvc/mangos/tags/ , but I need those missing ones .. edit2: release tags made, adjusted them a little bit manually, so they should fit the release, now I need client versions

I use this "latest" thing for almost 2 years ... and Mercurial is even younger IIRC devs weren't too exited about it from the beginning and such step was made FOR the community. To allow patch contributors to "fork" mangos and develop their modifications on it, and more importantly - to share those changes further. ... and I agree on closing this topic, the decission was made ... and I see like 80% people "adapted" to it, others just don't want to read tutorials and docs.

Well ... that's a common thing, isn't it? How many "make install"s have you run without root privs?

You need to commit your changes, so you'll have clean working tree before merge.

git reset --hard <revspec> where <revspec> can be absolute "link" -- ie. the SHA1 of a commit or it can be relative, like HEAD~4 (4 revs back), HEAD^^2 (2 revs back to the second merge parent) ...

... and I said, try http://repo.or.cz/r/getmangos.git

Do you have those changes in your dirty working tree? Or in a commit? If you made a commit, you need to "diff" your current state and the state before your commit: git format-patch -1 --stdout > my_file.patch See it's manpage for help... git format-patch --help

See that bar under the "MaNGOS" logo? "Search" is in the middle. git format-patch --stdout > my_changes.patch

With the recent "switch" to the Git source control management system, several other possibilities of development style are opening. Those can be in fact applied to CVS/SVN as well, but they can gain more in Git (easier backporting, etc.). Many people I asked about MaNGOS development style said, that the main problem is no stable releases, yes, there are milestones, but they're finished just by assigning new bugs to the next milestone and fixing current one. So I begun to think about new style(s) of the development process. -------------------------------------------------------------------------------- Since Git came from the Linux kernel project and it was originally developed the way to reflect the current needs, let me explain (in short) how it worked in the past and how it works now. "3" Well I wasn't there all the time so I can't say how it worked before 2.2, I just guess it worked the way I remember from times when BitKeeper wasn't in use - patches, tarballs and emails. The crucial thing was between 2.4 and 2.6, the 2.5 tree. People wanted the 2.4 to stay stable, so unstable stuff (new features mainly) went to 2.5 and only critical and security bugfixes were backported to 2.4 (this reminds me the "odd" and "even" kernel numbering, where even versions were stable and odd ones were for testing -- adopted also by other projects). After some time, 2.4 became too old with old drivers, some attempts were made to backport several things. Some of them worked (aargh, can't recall those famous names), but mostly, they didn't. So the 2.5 moved to 2.6 and continued it's stabilization. There were some "where's the 2.7?" mails in the mailing list, but that one never came out. Instead of that, developers merged the new things into the 2.6. This resulted in the way we can see Linux kernel development today and speeded up the development (and testing) a bit. However, as you may imagine, there was no stable version. Many people continued to use old 2.4 just because they didn't want to have "unstable" kernel (all fixes were put in the most unstable head, not much of backports to 2.4 were made). This was changed with the 2.6.8 version, which had really bad NFS (fcntl) bug, but there weren't just enough changes to release 2.6.9, so a 2.6.8.1 was made. It was used again some time later (can't remember exactly, it was few months before the Git came) and it's in common use since then (see 2.6.16.x called "stable", 2.4.x is also being slowly developed). So the current release cycle is basically using release candidates. Most (80%?) of the new stuff goes to the -rc1, this means a lot of new regressions, which are being fixed in other -rcs. The final release is (should be) without any known regressions. It's that "simple". The whole thing is a bit more complicated though, there are git "snapshots", generated every day at 7:00 and 19:00 (IIRC, not sure about that), patches for almost everything (so you don't need to download full versions), etc. New patches are "stored and tested" in the new linux-next tree (there are currently some problems with it, so, as you can see, not only "our" development model is changing).. This is just FYI, I don't want exactly the same model for the MaNGOS project (just because there aren't too many servers to host this stuff on, a lot less developers, etc.), it's just here because it has some good points that could be used. "3" So we're finally at the point of this topic. You might call it "the straight dope". "2" I guess I don't need to write much about this one, it should be similar as is in the Linux kernel, possibly with additional modifications. * Merge new and partially tested stuff * Resolve regressions, problems, crashes, etc. * Stabilize it * Make a release ... with testing all the time around release candidates. It's also good for bug reporting problems. Tester can say "I have this problem with 0.13-rc2" instead of saying "in r648318" or "around 21.12.2008 in 3fg8ac0". "2" However, some people want even more "agile" development style and "rolling releases", that simply means keeping current style as it is, with just speeding the process a bit. That's possible to do as well. One example would be to make another "testing" branch (or more of them) and test potentially unstable stuff. Like arena patch, AV patch, etc. The unstable branch could have it's own release candidates, but it could be hard to sync it with the "master" one. This approach is done also in kernel. Some people maintain 2.2.x trees, some 2.4.x, some other their own trees, like Alan Cox's "-ac", or Andrew Morton's unstable "-mm" tree, where new stuff is tested (not sure how it's done now, when linux-next exists) and others. However, this approach can be also done on the patch author repo's side (and merging it into the official branch), just like barlok's changes are maintained at the moment, so it would be probably only for authors without a public git repo (and those are pretty rare as you need to play with git-format-patch anyway). "2" I had other ideas, but those got lost over time, maybe some of them appear in the discussion below this article and I really hope there will be any (!). -------------------------------------------------------------------------------- So, there we have pretty unexpected "end" of this small article. It's purpose is NOT to declare a new way of development, but to start a discussion about this. And I don't mean discussion about "Git vs. SVN", that's another topic. Thanks for ideas, Freghar

By "revert" I mean another reverting commit, not just deleting the current one, which is called reset.

The hash is in fact generated from something little different (because if it would be only based on files, you'd got twice the same hash in a revert commit), but you've got the point

Well I think that for example balrok has less work to stay in sync with Mangos, as well as I ... and many others.

In fact, they're mostly usable without modifications. Read git-apply's manpage for "-p" option .. or use GNU patch utility ...

Google out some articles about shell usage ("console") .. listing a directory, moving around, etc.

Actually, I suggest you to read manpage of git-rev-parse, from SPECIFYING REVISIONS ... the "more correct way" in this example should be HEAD~3 (you can read there why).

Try entering the repository cd mangos/

All those are "svn ways" .. I say it again, again and again ... don't compare those two if you have no idea what is git capable of and if you just got f*cked up because it's not going to teach you itself

It's better when you want 2-3 hashes to fit on a 80char line. Like git-diff 4bcd3f6...564dda8

7 characters/digits is recommended minimum (and used by many apps) ..

man git-config ... or use some wrapper.

1) There was some documentation on the wiki few weeks ago, Doxygen can be useful as well. 2) Did you get the basic idea of Git? Why it differs so much from SVN, why TheLuda said that thing about thousands of users .... In fact, Git gives you a tons of freedom, source control management representation of open-source. You can actually see it even now -- http://github.com/mangos/mangos/network -- people are forking it and doing custom stuff, I believe this is the way TheLuda meant it. If you have an SVN, you can develop things, but you can either have them in dirty working trees or on your own SVN (which isn't much of a problem now, thanks to assembla & others), however you can never reach the distributed development style as it's possible to do with an decentralized SCM ... subhuman_bob: "mousists" can use keyboard-on-screen

It seems to me that you read it wrong, Kalash eventually agreed that git is "better" for him and probably used "patches" in meaning of "changes in a branch".