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