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).

I use git on windows and I always have to browse net thru a proxy server. I installed a Git GUI for windows but it dosent provide me the option to specify a proxy. I tried making it work with software called proxifier( equivalent to proxy chains of linux) but was strangely unsuccessful. If there is a Git software for windows which lets you work with proxy please let me know. Any other solution is also helpful.

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

@Kray - I think you raise some good points. It feels to me that the move to Git was because it's the "latest" thing. Once something else shows up I worry that the Devs will decide to move yet again. There are how many Paste Bin type sites out there now? People always seem to be driven by "trends".

I use this "latest" thing for almost 2 years ... and Mercurial is even younger

I agree with the person who said that the Dev's should have been talking about this move and asking for community input before making the decision. Frankly...without the community providing feedback (positive or negative) then the Dev's have nothing. A decision can NOT be simply made on what's best for the Dev's. The decision SHOULD have been made with EVERYONE in consideration. It's VERY clear that the majority of people were not thought of when the Git move was decided.

It does NOT matter if the Dev's use Git on Windows....Bravo...I applaud you. This does NOT mean that those of us who do NOT want to take the time to learn a new system have to like the change. There are many of us who wish to have a KISS process when working with testing Mangos. I do NOT care how good Git is for the Dev's. If it is that great for the Dev's then THEY should use. If the community feels that SVN is best for US then the Dev's need to listen to that as well.

The solution here should be Git for those that want to use it and SVN for those that want to use it. How hard would it be for the Dev's to do a nightly commit to SVN with the latest main branch of Git???? Come on...those of us who don't want to change to Git are being told WE are the lazy ones for not attempting to learn a new system. The Dev's are lazy themselves if they can't accomodate the community.

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.

Nevermind my above posts. My original build must have failed due to me not doing something right. I nuked all of the directories involved and restarted the process... It compiled without a problem.

I would add that when you do the make install on Ubuntu you may need to do a sudo make install if you want to use the /opt folder to install to.

And with that, Thanks for the guide!

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

Come on guys, 42 views and noone has an answer?

EDIT: My doubt is whether it is telling me that I customised such files 10 branches ago or whether thare is an issue which eventually I will pay for,

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

How in the world to you revert back to a revision? Or does Git not even have that?

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

thx, but this not work ....

Patch file have 0 byte :-(

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

I have many changes on my Source code, but how do I create a patch?

Where can help me to create a howto to create a Patch?

With TortoiseSVN its very easy, but not with GIT :-(

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

Isn't that the point though? That way if you revert then try to make the same commit it won't let you? I'm still learning git so I'm in no way arguing just working on understanding it a little better.

Regards,

JDG

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

No git works on a different principle than svn. Basically when you make changes to code it makes a hash of all the files in your local git repo. From what i've read this eliminates the chances of duplicate commits as any commit that has the exact same source will have the same hash. At any rate that was too much info, the short answer is no there is not any way to get git to give you linear revision numbers as svn does.

Regards,

JDG

sorry, but THIS is more as a joke, or isn't it!? it must be a joke...

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

If you search the forum you will find that in order to use a patch that was formated for svn IS IN FACT usable in git however minor modifications have to be made. Read throught the quick and dirty git guide thread and you will see that vladimir posted these modifications.

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

hmm oke

git-apply impconfig_git.patch

gives me : cant open patch impconfig_git.patch .no such file or directory but i have downloaded source and i have added that patch to source folder

git apply impconfig_git.patch

cant open patch impconfig_git.patch .no such file or directory but i have downloaded source

im dumb i know but whats im doing wrong?

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

1.

git reset --hard MUH

MUH= sha1-hash

=HEAD^ (last commit)

=HEAD^^(commit before last)

or maybe you're satisfied with "git checkout MUH"

2. no idea (:

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

Ah, okay. In the guide I read somewhere they said 5, but 7 is probably better. Anyway, I usually copy the whole 40-hexdigit, it doesn't take much longer I don't really see the reason to shorten it, but I guess it's better when you have to memorize it.

It's better when you want 2-3 hashes to fit on a 80char line.

Like git-diff 4bcd3f6...564dda8

You will see them here http://github.com/mangos/mangos/commits/master to the right of every commit.

Or if you use the "git log" command you will see the commit id on the top of every commit

Instead of copying the whole 40-hexdigit id you can copy only the first 5 digits too if you want so instead of doing this:

git checkout 964f7bc31fcade7e42a419c34e91dba2fb005e0c

you can do

git checkout 964f7

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

How to use git through SQUID proxy from windows? Any idea?

man git-config

core.gitProxy

A "proxy command" to execute (as command host port) instead of establishing direct connection to the remote server when using the git protocol for fetching. If the variable value is in the "COMMAND for DOMAIN" format, the command is applied only on hostnames ending with the specified domain string. This variable may be set multiple times and is matched in the given order; the first match wins.

Can be overridden by the GIT_PROXY_COMMAND environment variable (which always applies universally, without the special "for" handling).

http.proxy

Override the HTTP proxy, normally configured using the http_proxy environment variable (see curl(1)). This can be overridden on a per-remote basis; see remote.<name>.proxy

remote.<name>.proxy

For remotes that require curl (http, https and ftp), the URL to the proxy to use for that remote. Set to the empty string to disable proxying for that remote.

... or use some wrapper.

This project was never in danger because of Ascent or Trinity, i have watched this project slowly kill itself within the last few months, what i don't understand is, when there are volunteers willing to do the work, the project should mold itself around them, i know how hard leadership is Theluda and i understand that sometimes you have to make a decision for somebody because they can't make the right one on thier own, that's what being a lider is all about, but what is a lider without his crew, this is the 2nd time the mangos team has spit leaving less and less resources behind, yes i understand that there had to be a change to git for personal prefference or efficiency, but have the dev team split in two again just because of the working tools, people can adapt to them but shouldn't this project adapt to it's users and volunteers.

About documentation yes i am aware that it is monumental work, maybe that's why it should have started long ago when people were a bit more exited about this whole thing, you yourself said that you payed a lot of money to make this project legal and help people around the world learn what a MMORPG server is all about, and if that wasn't your goal the i don't know what this project was about in the first place, i have to admit this has been a both educational and fun project for me and my goal was to see this project reach 1.0, but what's so bad about that, even after 1.0 is here the project can still continue ever stronger then before.

I really tought this was the one, the project that could withstand all this egocentrism and immaturity, and of course it's still standing but it's not the same anymore the whole revamp has made a lot of users that were willing to stay with the slow advancement, alienate themselves and make threads such as this one, all of this change is a little to late into the project and i can see the community crumble down.

Again i'm sorry for the doom's day approch of my post, but i really hate to see such a great project turn out the way it has.

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".