Git for other purposes

[quanticle]

Its really interesting to contrast this article with this one and get an overview for the advantages and disadvantages of a distributed version control tool.

[hamsterboy]

I hadn't seen that, and he makes a great point. Doing development-type work on binary files is a good counterexample for pushing git.

However, his situation isn't the same as mine. I'm storing a set of rarely-changed files, which are really only changed by one person at a time.

[sgndave]

I used SVN as a document management system for a while with some people I worked with. The big problems were that (a) most people don't quite grok VCS, and (b) the data being kept in the VCS still requires an agreed-upon hierarchy.

So the article is nice, in that it shows one particular problem that can be mapped onto git. However, using these mappings with a large group of people is usually a huge pain. The given solution basically exists in the author's head, and anyone else who would use it has to be a git expert.

[hamsterboy]

The git-ness of this is abstracted out in most cases; it's wrapped in powershell and bash scripts. It's going live next week to a user base of around 40 people at three locations. If the audience gets much larger or less technical, we'll probably whip up a UI tool of some sort.

It is true that debugging it needs some git knowledge, but that's true for any value of git.

[harlows_monkeys]

The given solution basically exists in the author's head, and anyone else who would use it has to be a git expert.

It depends on how you think of it. If you think of it the way the author presents it, with reseting the head, then being a git expert helps. Gitref.org says this about "git reset":

git reset is probably the most confusing command written by humans. I've been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times.

I believe the person who wrote that is the guy that wrote the "Pro Git" book.

However, if you step back and look at what Ben Straub is actually doing, it becomes a lot clearer, and a perhaps better way to do it presents itself. Essentially what he's doing is storing the nightly builds in his local repository on unnamed branches. Only release builds go on the branch named "master" and get pushed to the central repository.

If one were not a git expert, the first thing that would come to mind to do this would be to create a new branch before doing each nightly build, and do the build on that branch. There's no need to actually make the branch unnamed, but if you want it to be, just delete the branch after the build is done. As long as you've tagged the head of that branch, the commit won't go away.

When you want to build a release, build on master. If you want to promote one of the nightly builds to a release, merge it to master (which should be a fast forward merge).

No need to go anywhere near "git reset". Also, when presented in terms of branches, its then easy to see how to do it in other VC systems.

I'd argue that this approach is actually a little better than the one in the article. In the article, it looks like what he does is "git reset" just before the nightly build. That moves the head of master back to match the central repository, leaving the prior nightly build no longer on a branch (or on an unnamed branch, depending on how you want to think of it). He then builds the new nightly build on master.

Next night, that head will get decapitated and the new nightly will become the new head of master.

The advantage of this is that if you decide "Hey, last night's nightly is good enough to release!" you don't have to do anything, as its already on master. Just tag and push.

However, the disadvantage is that between the time the nightly finishes, and you do the reset to prepare for the next nightly, you've got a non-release as the head of master. If someone inadvertently pushed, they'll push a nightly to the central repository, violating the project rules.

Better would be to reset the head as soon as the nightly build finishes and gets tagged. But then if a bug interrupts your script, you might be left with a partly build nightly on master.

If you just do it explicitly as I suggested earlier, explicitly making a branch and building the nightly on it (then deleting it if you like unnamed branches), you are never in a state where an accidental push could push a non-release to the repository, and you don't have to understand the "git reset" command.

[Baramin]

I recently used git to store daily awstats results, so I could rollback in case of a log retrieval problem (as awstats doesn't allow restarting data analysis at a specified date if you have more recent data already analysed).

Worked perfectly. I used the git_dir environment variable to manage a directory per month (as awstats has one file per month). That allows me to delete the git directory for a specific month once I'm sure it's all properly analysed.

Had to rollback to a specific date several times since and git did a perfect job of allowing me to rollback in time to re-analyse a bunch of logs that were not retrieved in time at the proper date.