Hello, I'm sorry I am still not on Inet as often as usual (as I'm still ill), so my response is a bit late.
> > 4. putting more git trees together: you can either pull from my git tree > > instead of me pushing to your one. This has an advantage that you have your > > git > > tree under control. > > Just because of the current DVCS hype, it doesn't mean that we cannot > work in centralized fashion. Given the low traffic of vim_extended > (among others not being an upstream project also is a reason for it) and > the few people contributing, pulling from other repos doesn't seem to be > necessary. So I think there shouldn't arise problems in keeping the repo > clean with more than one person having push access. We just have to set > some rules for clean commit logs, who is allowed to push to which branch > and so on. > > You asked me for push access, but if you prefer having your own tree, > then I'd be fine with that as well. While using git, both ways are so similar... Firstly, with git, everyone has at least one git tree by definition (you can't do just checkout like with CVS, you always have a complete tree including the history). Secondly, the patches appear in a tree of their author at first, of course. As anyone (but you) can't work in the vim_extended tree directly. This is the similar point as the first one, just in different words. So, thirdly, we want to agree on some way of _synchronization_ of our trees. This is a term not known in CVS/SVN world. And it's not a problem to agree on either push or pull system of synchronization for me. One possibility is tat I'll push my patches to a separate branch in your tree, second one is that you'll pull patches from my tree. The direction (and result) is same in the basic case. The only difference is that you have more options in the second case: to refuse some patches of mine etc. However, I agree that benefits are probably small in such small project. BTW: the fact everyone has his/her own git tree not dependent on Internet connection for the work, saved my work on fast_join patch set during Christmas days. This is a big benefit of git. > > 5. what about a cooperation with Christian and pul his git tree as > > vim_upstream? There is no dependency on svn, nice tags for vim versions > > are > > there... Would it be possible? > > No, it wouldn't. > It looks nice at first sight, but it isn't really useful for > development. Look at the branches, they each have their own root, they > don't have any relation to each other. With Vim 7.3, the master branch > will be rewritten from scratch. You can't merge and forward-port the > feature branches to the next minor release. In fact you'd end up with a > rebase of all your branches as well. It would be nice if you two agreed on some simple system good for everyone. I think that the development of vim is, from its definition (just one committer) linear. So if there were tags for each versio of vim and patches named by their number and subject, one can find everything in history easily. We don't probably need no branches for upstream vim, we need them for paralel development like patch sets of other authors etc. And with patches named with their number (and subject), we will not need so many tags... What do you think about that? Did I miss anything? Milan --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
