On 02/03/09 13:48, Milan Vancura wrote: >> Tony Mechelynck, 28.02.2009: >>> On 28/02/09 12:06, Markus Heidelberg wrote: >>>> Tony Mechelynck, 28.02.2009: >>>>> On 28/02/09 11:34, Markus Heidelberg wrote: >>>>> [...] >>>>> >>>>> This debate is going nowhere. You won't change your mind, and neither >>>>> shall I, so I'm shutting up. >>>> OK, do so, without having responded to the main argument a single time, >>>> although I've reminded you. It seems you are running out of arguments. >>>> Please put down your anti-git attitude and accept its usefulness, >>>> at least in the case of the runtime updates. >>>> >>>> Markus >>> What main argument? >> I didn't want to repeat it for the third time, but since you don't >> understand, here it is, copied from a former mail: >> >> It doesn't work for runtime changes, which you HAVE to put into existing >> files. > > I think everything is clear: StarWing has a problem and Markus suggested a > solution. The suggested solution not only works for StarWing but doesn't harm > anyone in his/her workflow. It allows the others to get a better patch from > StarWing on the vim_dev list (as the patch will be tested better) so it will > be > a clear benefit for everyone. > > Users of vim_extended repository have a little advantage more: they can work > with the patch(set) more interactively, merge it with their patches, select > patches/branches to merge and test conflicts or a cooperation of several > features at once etc. All this can be done localy and, after the first tree > clone, offline. More about git advantages (and not only git, Mercurial is an > example of other VCS offering a similar level of usability; and there may be > others) was already said on this list some time ago. Just check the archive. > There you will see, Tony, that this is not any exception: James Vega maintains > a repository for Debian purposes, MacVim is maintained in a similar way as > well... There must be something good behind it :-) > > But even people using ftp+rsync method can achieve the same just using > different method (in a more complicated way, my opinion, but this is a > different story and not my decision) as everyone still gets a patch through > the > vim_dev mailing list.
Any such unofficial patch to runtime files will have to be reapplied after each and every rsync run. Possible, but not practical, and it could readily be avoided by avoiding placing any unofficial runtime files or runtime file changes in the $VIMRUNTIME tree. Wasn't I clear? > > This all is possible not only because of git but because of Markus's great > work > on vim_extended repository which combines vim and runtime files together and > allows feature branches for testing. > > Similarly, if I need to check something in the vim history, another > repository, > made by Christian Michon, is very helpful (http://github.com/cmichon/vim). I > know how hard was to work without its help, when, one time, I needed look to > vim 5.4 which is not included in Christian's repo and I did have to find > patches myself... > > So I want to thank Markus and Christian for their work here. Thank you, guys, > as you made my life easier! > > Milan Regards, Tony. -- We ARE as gods and might as well get good at it. -- Whole Earth Catalog --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
