> If you see how Bram is handling (well) vim, it has a linear
> development. No branches, No merge.
> When he moves on to the next release, the previous one does not get
> updated patches (it seldom happens).
>
> So actually Bram could do the whole maintainance of vim by just using
> git-gui (graphical interface tcl/tk based).
>
> At this stage, it is so much easier than any of the competing tools.
> It is a fact.
I think you are right. Vim is a project with needs covered by git 100% and with
low maintenance work. And the other will profit as well: no more anything like
"which version is your patch against? .435? Sorry, the latest is .465, I can't
test your patch. Rewrite it first.". Or the saga with the floating point patch:
everyone had to reverse the previous floating patch, then upgrade vim to
current version and apply new version of floating patch. Everything manually.
Argh! This is not what I can call 'easy to use'.
Git can save all of this. You can:
1. checkout to any version and patchlevel you want, at any time
2. still see patches separately, including their metadata like authors, date
etc. (How can I see all patches between .289 and .301 using CVS? As one big
diff with no sense?)
3. develop your own patch for longer time easily:
3.1. you have a branch for the patch local at home, no need to ask any
administrator about rights to create anything on the server
3.2. this branch is "sticked" to your favorite vim version and patchlevel as
long as you need
3.3. you can "rebase" this branch to another (typically current) patchlevel of
"upstream" vim and see conflicts easily (good to do before publishing the
new version of the patch to vim-dev mailing list)
4. you can publish this branch to other people for collaborative work on the
patch, for testers etc. All they need to do is to add your branch to their
tree. No manual reversing, applying, looking for patches at mailing lists.
5. you still can apply patch coming from the mailing list, and easily: you
simply checkout to the state the patch requires and apply it. And to
the new branch, if you want. For example to not loose your own version of
the patch. Merging both branches in the future is easy with git.
6. get graphical frontend showing all branches, merges etc. (git-gui or gitk)
7. maintain the branch of your favorite distro's patches to be able to update
vim and not to loose the advantages of your distro
> I intend to re-build a clean git tree for vim (don't expect it sooner
> than next week). I will be able to show graphically why it would be
> easy to maintain vim with git.
Sure. It will be the best how to show all of the advantages. Great idea,
Christian!
Milan
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
