björn, 15.11.2008: > > 2008/11/15 Markus Heidelberg <[EMAIL PROTECTED]>: > > > > björn, 15.11.2008: > >> > >> Anyway, I still haven't seen any reasons to switch to vim_extended yet > >> (so far, nothing makes _my_ life simpler). > > > > If you don't want to use any of the features included in vim_extended, then > > no, it probably won't make _your_ life simpler. But the life of other MacVim > > users which want to use some features from it. > > ...and that is a good reason, but I was hoping for other benefits. ;)
Maybe some unexpected positive side effects arise :) > Another thought just came to me though: what happens when Vim changes > version (e.g. to 7.3) would I still keep pulling from the same branch > in vim_extended or would I need to do something? Good point. I think I haven't really thought about it, when searching for the branch with nice commit logs. I just did git svn from the 7.1 branch and yes, there are other commit ids. Merging the 7.2 branch into 7.1 caused a lot of merge conflicts. It seems I have to reorganize the repo and move to trunk. Avoiding these conflicts is more important than having nice commit logs. But there should be a way to get both. Edward, do you know why the trunk branch doesn't have nice commit logs and is there a way to get them in? Was this the lack of merge tracking before svn version 1.5? > I'm curious because > the change to 7.2 caused various merge problems (so this is an > instance where my life actually might get easier if I'm lucky). You fetch from the trunk branch, right? What kind of conflicts did arise? I suspect mostly from the runtime files!? > >> If Jason manages to make a > >> rebase that keeps the MacVim commit history intact and that I can > >> continue working from easily I'll take another look. However, I still > >> want to be able to build MacVim snapshots with the latest runtime > >> files as well as the latest Vim source code without having to jump > >> through hoops. (Jason, if there is anything I can do to help with > >> your endeavours, please let me know.) > > > > I'll try to create a runtime branch that is mergeable without real > > conflicts. > > Then you could merge from vim_extended/vim and vim_extended/runtime into > > your > > macvim branch. Do you like this idea? > > Would the "runtime" branch only contain runtime files then, or what? Yes, I haven't tried it yet. I hope this works and merging is easy. > All in all, I think it would benefit many users if there was an easy > way to pull the latest runtime files. Using rsync has proven to be > somewhat hazardous (as was witnessed when I accidentally added all the > spell files and the repo grew 100 Mb...oops). Oh, dear! > Would I then be able to just "git-merge runtime", "git-merge vim" to > get the latest source+runtime files? If so, I'd be happy (only one > more command than what I need now), as long as it doesn't lead to more > merge conflicts or something otherwise unforseen. Yes, on these 2 commands I thought. Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
