Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Kinsie

Gits, the Lot of 'Em!

Recommended Posts

I'm slightly disappointed (it's not a big deal) the commit dates don't match the original release dates, but at any rate, GitHub actually makes it rather easy for people to fork off of each other and interact among projects. It may be a bit late for most of the doom and quake scenes, but it's certainly nice nonetheless.

It's a bit too bad the original Wolfenstein 3D release isn't there, and under a more appropriate license than originally, though considering the iOS one is based on a source port of it itself, and that's all put under the GPLv2+, probably safe enough to assume GPLv2+ on the older one. Likewise, the git repo for classic Doom from id is simply the original non-commercial Doom License rather than the GPLv2 one.

Share this post


Link to post

Git would be cool if its revision system made sense to humans. It's also a hell of a lot harder to bugreport when your revision is "f0ed96" or some malarkey.

Anyway, good for them.

Share this post


Link to post
chungy said:

It's a bit too bad the original Wolfenstein 3D release isn't there, and under a more appropriate license than originally, though considering the iOS one is based on a source port of it itself, and that's all put under the GPLv2+, probably safe enough to assume GPLv2+ on the older one.

While I agree they should put the original wolf source up there, Carmack did make a statement that clearly states the original wolf source is GPL:

I released the original source for Wolfenstein 3D many years ago, originally under a not-for-commercial purposes license, then later under the GPL.

Because of this I got the author of Wolf4SDL to dual license and ECWolf will be dual licensed as well.

Share this post


Link to post

Speaking of which, you really should make a thread about ECWolf here or at the ZDoom forums.

Share this post


Link to post
Csonicgo said:

Git would be cool if its revision system made sense to humans. It's also a hell of a lot harder to bugreport when your revision is "f0ed96" or some malarkey.

How is it harder? I mean really, it's no different than reporting for "r429482"

if you really want to have a revision system that makes no sense, go try CVS. Every file has its own version numbers, that can be picked arbitrarily by committers. Have fun :)

Share this post


Link to post
Csonicgo said:

Git would be cool if its revision system made sense to humans. It's also a hell of a lot harder to bugreport when your revision is "f0ed96" or some malarkey.

Anyway, good for them.


That's the big issue I have with distibuted version control. You lose the one piece of info that's crucial when developing a 'linear' project.

@chungy:

Yes, it is an issue when discussing version numbers. I do not have a problem with hexadecimal but I have a problem when the order of revisions is not evidenced by the version number. I can't tell how Git handles it but with Mercurial it just seems some checksums that represent version number.

Not good if you ask me.

Share this post


Link to post

Heh, if the biggest issue with Git or Mercurial is the way commits are referenced, they must really be doing something right. Either that or this is bikeshedding at its finest.

It's simply a different model of representing them and any other way really doesn't work when you get beyond 1 person committing. Mercurial has local incrementing commit references, like Subversion, that go r1, r2, r3, etc, but these are not synchronized with other repository clones and thus should never be used to refer other people to specific commits; I can even easily think of situations were a single-developer project can have desynchronized revision numbers simply by having more than one computer.

Though, if incrementing numbers are really that important to you, this project fudges timestamps around until a specific sha1 hash is found: https://github.com/vog/beautify_git_hash/commits/master

Share this post


Link to post

That utility clearly shows that this is important.

If users had to refer to revisions by some random multi-digit number, decent bug reporting like on the ZDoom forum would not be possible.

I see this issue as a major shortcoming of these systems for projects that need some trackable revision number. The hashes sure don't work for that and this is the major reason why at work we stick to SVN although in all other areas Mercurial or Git would be better.

Share this post


Link to post
Graf Zahl said:

That utility clearly shows that this is important.

The author doesn't seem to think so; the project description includes the words "This is a little useless toy" (and just look at the code, it doesn't do anything remarkably unobvious; it was probably a quick hack for fun).

Graf Zahl said:

If users had to refer to revisions by some random multi-digit number, decent bug reporting like on the ZDoom forum would not be possible.

How exactly? They'd still be reporting against specific revisions, how they're named isn't exactly that important.

Share this post


Link to post

"Wait, there was a change to the relevant code in revision #fe783a7842. Does it still happen?"
"Dunno, I've got revision #ba954eef178. Is that before or after?"


Decentralized system makes sense for decentralized development (forks, branches, etc.) but for a project developed by a small team, a centralized system and incremental versioning is more intuitive to everybody.

Share this post


Link to post

Seems to be a rather contrived example. Why don't you just ask "Does it still happen in the latest code?"

Share this post


Link to post
chungy said:

Seems to be a rather contrived example. Why don't you just ask "Does it still happen in the latest code?"


From experience with working on incrementally developed project my answer to that is that this won't work.

"Wait a minute, is the version we compiled on Jan 13th revision #38643342bf5a5ea1 or #fe37a37d74346691?"

Don't get me wrong. I like distributed version control systems but their inability to designate a master repository with an incremental version number makes them ill suited for certain types of development

Share this post


Link to post
Graf Zahl said:

"Wait a minute, is the version we compiled on Jan 13th revision #38643342bf5a5ea1 or #fe37a37d74346691?"

And when you have more than one commit per day...? That whole logic breaks down.

For what it's worth, a VCS-neutral reference style makes more sense IMO, and they won't break whenever version controls are switched out for the new and shiny (happens quite often actually); here's a proposed standad for such. It'd definitely get rid of the question of when fe37a37 or r1384 was commited on what day.

Share this post


Link to post

Well, it all depends on the project. This is all nice and well for large decentralized projects with an extended development time but for smaller stuff developed by a more compact team it's still complicating a trivial matter.

The stuff I am working on rarely uses development branches (development time is measured in months, not years and if a project is done, it's done.) so the need to communicate revisions does not extend past the incremented revision number.

It all has its advantages and disadvantages but in the end it boils down to 'use the best tool for the job'. And since the DVCS systems lack this one particular property they are unsuitable for the job at hand where I work.

Share this post


Link to post
Graf Zahl said:

Don't get me wrong. I like distributed version control systems but their inability to designate a master repository with an incremental version number makes them ill suited for certain types of development

Install Mercurial?

Share this post


Link to post

If I can fetch that revision number for release builds, yes, that would do. But if I remember correctly, the local copy would have its own sequential list of revision numbers, or am I missing something?

Share this post


Link to post
Graf Zahl said:

That utility clearly shows that this is important.

I've never seen anyone actually use this utility.

If users had to refer to revisions by some random multi-digit number, decent bug reporting like on the ZDoom forum would not be possible.

The hash might be long, but users only need to tell you the first couple of letters and numbers. If you pair that with a date, it's a solved problem.

Well, it all depends on the project. This is all nice and well for large decentralized projects

Git projects are not chaos. There is still usually one canonical 'master repository', it's just that individuals can commit to their own local work machine and still have sane merging capabilities once they're ready to merge their stuff in with everybody else.

The stuff I am working on rarely uses development branches (development time is measured in months, not years and if a project is done, it's done.) so the need to communicate revisions does not extend past the incremented revision number.

One of the big epiphanies that you discover using Git branches or Hg bookmarks is that branches are not sacred, you can have as many as you like for many different trains of thought. Workflows like "Hrm, this approach might be bad, let me start at square one and try a different tack" and "Hrm, that approach turned out to be a dead end, let me go back to the way I was doing it originally." are easy. And nobody else has to know they exist, everyone else only sees what you push.

If I can fetch that revision number for release builds, yes, that would do. But if I remember correctly, the local copy would have its own sequential list of revision numbers, or am I missing something?

Correct. The revision numbers in Mercurial are meaningless to anyone except your own local repository. If you're looking for something to put in the lower right hand corner of the GZDoom console, just use the date and a partial hash (r2012.02.13-ccc8780c), and just ask for the date and first few letters of the hash when you take bug reports. Done. Solved problem. Next stop, world hunger.

Share this post


Link to post
AlexMax said:

One of the big epiphanies that you discover using Git branches or Hg bookmarks is that branches are not sacred, you can have as many as you like for many different trains of thought. Workflows like "Hrm, this approach might be bad, let me start at square one and try a different tack" and "Hrm, that approach turned out to be a dead end, let me go back to the way I was doing it originally." are easy. And nobody else has to know they exist, everyone else only sees what you push.


In theory all nice and well - but that doesn't help if it's against company policy not to commit each and every change you make to the master repository.

As I said, it depends on the work environment a lot - and the typical advantages of DVCS simply do not apply in my case - but linear version numbers are very much important.

And no often how often you refer to the hashes, no, they are not sufficient in any way here. Maybe for you, definitely not for the people I work with.

Share this post


Link to post
AlexMax said:

Correct. The revision numbers in Mercurial are meaningless to anyone except your own local repository. If you're looking for something to put in the lower right hand corner of the GZDoom console, just use the date and a partial hash (r2012.02.13-ccc8780c), and just ask for the date and first few letters of the hash when you take bug reports. Done. Solved problem. Next stop, world hunger.

Freedoom does something like this in its build process, see: http://git.savannah.gnu.org/cgit/freedoom.git/tree/graphics/titlepic/create_caption

"git describe" even produces something somewhat more understandable than otherwise, since it bases the string it outputs on the last tag compared to the point in history the commit refers to, along with the number of commits since then. It's also perfectly usable as a identifier for a commit to git itself, so you can just as well use "git show v0.7-93-ga1608b3" to see the latest commit as of this post.

Share this post


Link to post
Sign in to follow this  
×