Moving to Git

[krugar]

Git also isn't a new fad; it's been available now for five years -- enough time for many software developers to evaluate it and decide if it works better for them than SVN or not. The general consensus is that it does. SVN isn't broken, but Git can do things that it can't -- or at least, that it can't do easily. So our main developers are more efficient on Git, not to mention happier.

There's really nothing that Git offers that I could consider essential to the point of suggesting changing the revision control system already in place for an existing project. Under most situations (although I could accept some extraordinary ones as not applying) all this is essentially about advantages of one system over another being wrongly dubbed essential, and a lack of actual analysis of the disadvantages; i.e. everything is marvelous, except for the things that will soon show up as not being so good and that no one thought about before.

In the end you replace one set of problems for another different set of problems.

But this is really way off-topic here (and useless since the decision was already made). I'm willing to discuss it on another place if you so wish.

[takkaria]

There's really nothing that Git offers that I could consider essential to the point of suggesting changing the revision control system already in place for an existing project. Under most situations (although I could accept some extraordinary ones as not applying) all this is essentially about advantages of one system over another being wrongly dubbed essential, and a lack of actual analysis of the disadvantages; i.e. everything is marvelous, except for the things that will soon show up as not being so good and that no one thought about before.

I don't think anyone in the devteam has called git essential... we do, however, want the features of a distributed VCS. I'd also appreciate it if you'd stop building strawmen around this decision and then attacking them; we're pretty competent developers and we know what we're doing and what we want... at least most of the time.

If this is a serious issue for you, I can do some limited things to help you out (like keeping the svn branch around and synced with git for a while), but if your main use of SVN for Angband was checking it out and making local changes (which it was, since you're not committer), the differences are minimal. It's just a different set of commands (clone, pull vs checkout, update).

[krugar]

Whoa! I'm not attacking anyone. And the only reason I'm not getting into more details is explained above. Do not accuse me of constructing strawman arguments when in fact I'm trying to not steer too much off-topic. It's completely unfair. A discussion of revision control systems is definitely something you don't want to happen on this thread. But if that is the only way to avoid being accused of constructing strawman arguments, I'm more than happy to do it.

But attacking you folks, or suggesting you aren't competent? Not only that would be the most ridiculous thing for me to say about the development team of a long-standing project, but it would also be missing the point entirely.

I think my participation on this thread is over. You heard a dissonant voice and I have nothing more to add to what has been said. Neither it matters anyway.

[Magnate]

From your perspective, you can think of Git as being like having two SVN repositories: one master copy on the remote server, and one local copy on your computer. You can check in changes on your computer without affecting the master, so you can make minor checkins without worrying about breaking things for everyone else. When all of your changes are ready, you can push them to the master.

Wow. I wish someone had given me that description when I first started grappling with git. It's a superb analogy.

[Magnate]

Nice. With luck we'll be able to do something smart with keeping V and AngbandBase synchronised; all we need is (a) at least one person with a clue and (b) something to actually happen with AngbandBase.

As I mentioned on the AngbandBase thread, www.github.com/elly/angband is the key branch for this. (It's not technically a branch as it was begun before the official move, but to all intents and purposes it is, as it will eventually be merged back into the main repo.) It's coming on in leaps and bounds thanks to an insane burst of energy on elly's part, but I'm not sure how near merging back it is. I'm 100% confident that elly would appreciate feedback from anyone interested in AngbandBase that the refactoring is going in the right direction.

[ewert]

Okay I'm intriqued by the "branching" stuff. If, for example, I'd code a version that has an option for unlimited home, option for no-buying except staples, and an option for no-selling (with concomitant cash drop increases), etc... does this git thing mean something for me? Could I have somehow get it "posted" as a development branch on the git-site side-by-side with the vanilla? Have a choice for people to download a compiled version of it so they can test it?

[Hajo]

Most version control system help you in so far that they support automatic merging of changes to the main development line into your branch.

[d_m]

Okay I'm intriqued by the "branching" stuff. If, for example, I'd code a version that has an option for unlimited home, option for no-buying except staples, and an option for no-selling (with concomitant cash drop increases), etc... does this git thing mean something for me? Could I have somehow get it "posted" as a development branch on the git-site side-by-side with the vanilla? Have a choice for people to download a compiled version of it so they can test it?

The way this works is that you would clone the main Angband repo to create your own repo (ewert-repo). Then you could make changes, commit them with log messages and push them to your own repo. Other people could check out ewert-repo and try out your changes. Eventually either you could request that certain patches (collections of commits) be pulled back into the main repo (or we could just decide to do that after trying out your repo).

Your branch wouldn't be "official" in any real sense (it wouldn't get a nightly build unless someone set that up manually); the big difference is that instead of saying "I think you should build feature XYZ" or even "here's a giant patch with XYZ" you can just make that change in your own repo.

The problem with just having patches is that as Angband changes it becomes harder and harder to keep these patches in sync (and it can be confusing, especially when there are multiple versions with bugfixes and such). Git solves this problem by making every checkout it's own repository that can be added to, modified, etc.

Anyway, we'll see how it works in practice.

P.S. Setting up a site which tracks a bunch of people's git repo's, tries to autobuild a nightly, and reports whether the build works or not, could be pretty useful.

[takkaria]

Okay I'm intriqued by the "branching" stuff. If, for example, I'd code a version that has an option for unlimited home, option for no-buying except staples, and an option for no-selling (with concomitant cash drop increases), etc... does this git thing mean something for me? Could I have somehow get it "posted" as a development branch on the git-site side-by-side with the vanilla? Have a choice for people to download a compiled version of it so they can test it?

Well, you can sign up to GitHub and go to http://github.com/takkaria/angband and click 'Fork', and then you'll have your very own branch of vanilla. You can then check it out locally, work on it and push the changes back to github.com/ewert/angband (or whatever your username is). You can also pull changes in from the official branch and keep up-to-date with changes in V.

GitHub doesn't provide for compiled versions, unless you upload them yourself, nor will it link to your repository from the Angband one, except if someone goes and looks at its forks page.

[ewert]

Sounds good enough. Now too bad am bit worn out by work, but sounds definitely something I'll do ...

[ewert]

Is the current master branch in tak/angband github broken?

Forked it to myself, used gitgui to get it, compiled it and commands do no get parsed through at startup. I did change some files, but for the life of me can not see how it could break anything at starting char creation ... Will try a brank spanking clear git version compile ...

[ewert]

Confirmed on git master copy, compiling it and cmd parsing is broken, can't proceed past first screen of male/female choice nor options at creation.

[ewert]

Okay spamming, noticed it on the previous change comments that they aren't working. =)

... now to figure how to get those earlier working versions from git next.

[takkaria]

Okay spamming, noticed it on the previous change comments that they aren't working. =)

... now to figure how to get those earlier working versions from git next.

oh, stupid me, I didn't test the birth screen. i'll get on that next week when I have some spare time.

[fizzix]

I'm trying to figure out how to use git and I feel like I'm doing it wrong.

I have a successful fork but I don't know how to put my changes in. I feel like I did this wrong, as I downloaded a copy of the source, and played around with the code locally. I probably should have done things differently...right?

I have no experience with web or collaborative development, so I apologize for the stupid questions.