Milan Vancura, 26.01.2009: > > 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).
You don't have to explain DVCS basics. Of course you have your own tree on disk, with "your own tree" above I meant "your own public tree to pull from". > 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. If you have push access, I probably have less work with your branch. > 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. Should I? :) > > > 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. That won't work, as Christian already mentioned in his reply to your message. Though I don't understand his reasons, whereas I understand my reasons. > I > think that the development of vim is, from its definition (just one committer) > linear. This is not dependent on the number of committers. > 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. There we all agree. > We don't > probably need no branches for upstream vim, we need them for paralel > development like patch sets of other authors etc. I'll create the repo just the way it is necessary. As I already said, I think branching is perhaps only necessary at one place in the history. When there is linear development (nearly always), the repo will be built linear. It will just be built the natural way. > And with patches named with their number (and subject), we will not need so > many tags... Yes, I'll create tags for each minor release (... 6.4 7.0 7.1 ...). And to have easy access to the latest stable minor release (... 6.4.010 7.0.243 7.1.330 ...), branches are the preferred way. But again, these are convenient branches and mostly (or always) in the case of Vim don't really branch off. Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
