ZDoom on GitHub

[randi]

For those interested in ZDoom's development, the source code repository has migrated to GitHub: http://github.com/rheit/zdoom

[Xaser]

For those worried about the move affecting their workflow, you shouldn't fear: Git's not nearly as intimidating as it's made out to be. While it's a bit more complex than SVN and other centralized systems, the most basic use case only adds an extra step to the process -- since you now have a local copy of the entire repository, you first commit to it and then issue a "push" command to sync the changes to the server. This slight increase in complexity brings tons of cool features with it, including local commits/history and branching that actually works, to name the most basic of the bunch.

If you're new to the process, Randy made a good post here outlining the basics. This guide on transitioning from SVN to Git might be worth a read, too.

[DaMan]

Goodbye intelligible SVN number.

[Graf Zahl]

A small loss. Don't get hung up on the only thing SVN had in its favor. For us developers git is like a breath of fresh air - finally the whole setup is in a state where working with it is as it should.

[Blzut3]

Because <tag>-<revision#>, or in Zandronum's case a timestamp, is soooo complicated.

[Fishytza]

Apologies in advance if this isn't the right thread.

Is the ChangeLog still going to be updated or am I forced to go to GitHub to view recent changes? Not that I mind, just curious is all.

[Graf Zahl]

Randi said it's a bit complicated to do a proper display for git's revision history with multiple branches. I hope it gets solved but it's clearly not as easy as for SVN.

[Xaser]

I'd like to say that for simplicity's sake, the changelog should just list commits in chronological order with a field somewhere in the post saying what branch it's for, then maybe have a dropdown box at the top of the page to filter by branch. I feel as if users of the changelog won't be interested (or, even more importantly, might be confused by) a tree-like view, so we can leave that to Github since that's where the actual developers will congregate.

[Graf Zahl]

saying what branch it's for,

Easier said than done. In Git, a branch is merely a label to a specific commit. Depending on what was merged a commit can belong to several branches.
As it is currently set up with the master and maint branch, lots of commits belong to both at the same time. It'll get even more confusing once a feature branch gets merged back. Then linearity is completely thrown out of the window.

If you want to have a bit of fun, take a graphical log viewer and have a look at the GZDoom repository. It's 4 branches all over the place (master/maint of ZDoom and master/maint of GZDoom) with countless merges between them.

[Xaser]

I still think that's overcomplicating it. I'm suggesting treating the changelog as a literal log -- when a commit is made (including merge commits), create a changelog entry with the commit message and the branch it was committed to and be done with it (i.e. never change the log entry again).

Of course, this would require some new infrastructure since this sort of thing can't be auto-generated by just looking at the git tree, so that route would involve getting one's hands a bit dirty or erecting a "code wanted" sign somewhere. It still seems like the most clear solution for replacing the SVN changelog page with something as easily readable by the layperson, though.

[EDIT] The more I think about it, though, the more I realize that it's probably better to just make the 'Changelog' link point here. Why re-invent the wheel?

[randi]

Why re-invent the wheel?

It's not exactly the most readable thing when you actually want to see everything that's been changed for one. It doesn't know anything about the SVN revision numbers for another.

As for which branches a commit belongs to, the solution is git branch --contains. This will list all the branches that contain a commit right now. There is no way to reliably determine which branch originally contained a commit. (Or at least, I don't think there is.) Especially since feature branches can disappear after they've been merged into master. There's even no guarantee that the master repository ever had the original branch a commit was made to.

Mostly, though, the main "problem" is that it's been a few years since I've done any web programming. I'm going to have to relearn some stuff to redo this. The current backed runs svn log every five minute and dumps any new changes into a SQL database that the web interface pulls from. With git, it would probably be better to use git log and other command-line facilities to retrieve this information on demand than try to store it in a separate database.

[AlexMax]

Why re-invent the wheel?

There is no way to reliably determine which branch originally contained a commit. (Or at least, I don't think there is.)

There isn't. You'd have to bake the branchname into the commit for it to work. The closest git comes to this is Annotated Tags, but these are tags, not branches.

[randi]

The Changelog page now tracks the git repository, more or less. I'll get to the details pages (which would handle the SVN->Git mapping) later.

[Gez]

The Changelog page now tracks the git repository, more or less. I'll get to the details pages (which would handle the SVN->Git mapping) later.

So, will all the links such as http://zdoom.org/Changelog/3374/files work again then, or will the wiki need to have all its [wiki=Special:WhatLinksHere/Template:Rev]rev links[/wiki] updated?

(Huh, wiki tag cannot handle slashes. rev links.)

[randi]

That is the plan.