Subject: Re: [vserver] vserver git server and misc. thoughts
From: Ed W <lists@wildgooses.com>
Date: Tue, 12 Aug 2008 17:18:50 +0100

Adam Majer wrote:
> I've used all sort of different revision control systems, from CVS to
> SVN to Arch to GIT. And I have to say GIT is by far the best. You can
> change your current checked out version in-tree without changing
> directories like with others. It is a very nice system. Basic GIT
> operation like pull, checkout, push, commit, diff, are all *very*
> simple. And I did not jump on the GIT bandwagon until almost forced
> recently - I will I was forced earlier :)
>   

I do agree with you (having just joined the bandwagon myself).  However, 
if anyone has got their back up about this then lets not start a VCS 
debate - they all have their benefits and certainly whilst git is at the 
cutting edge you also have several very similar and powerful systems in 
mercurial and the like which are apparently equally powerful (or more so 
depending on your stand point...)

> Anyway, I'll maintain the GIT version of the patches. This means
> essentially vs. Linus' kernel from
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
>   

I would be quite interested to track this.  I should think github is a 
very nice place to start with it?  They have a bunch of features around 
it which makes it fairly easy to track and contribute.

I would be interested to see the tools and scripts in git also? 

Can you try and keep the vserver patches in a branch separate to the 
mainline though please?  A lot of folks seem to just create a master 
branch with EVERYTHING in it and it's a nightmare trying to follow 
development.  I find a workflow where I keep my master tracking upstream 
project, then a branch of patches, which I then pull from both to create 
my dev branch where I work.  When I get something which is worth pushing 
upstream I can "cherrypick" it back into the patch branch (which causes 
no circular commit issues downstream when you repull in the dev branch)

Why bother?  Well, personally I find the code history quite instructive 
in learning how the code actually works.  I hope you might actually try 
and get as much vserver history as possible (without spending forever) 
into the git repo.  I know this is theoretically possible on SVN and the 
like, but I have ot be honest I find even neat tools like tortoise svn 
so slow and such a faf that I never really found that I would peruse 
project history with svn projects.  However, with a git based project I 
often cruise the recent history and can quickly examine commits and use 
those to help learn my way around the code tree...

Anyway, just my 2p...



So does anyone have enough interest and capacity to try and take some 
small bits of the vserver project and push it upstream?  Are there any 
reasonably uncontroversial bits to get some momentum?

Ed W