On Sat, Jan 24, 2009 at 4:05 PM, Markus Heidelberg <markus.heidelb...@web.de> wrote: >> it's not a bug, it's a feature (tm). > > I can't find a feature. At least if there is one, then I don't like it. > But I can see the problems when creating a repo for Vim and your layout > with unrelated branches is the easiest solution and will work with every > minor release branch in the same manner.
ever tried git-cvsimport on the official vim repo ? you'll see it's linear, and vim7 and vim<7 are actually different CVS repositories. >> I can change that if needed: how would you like my repo to look like >> in terms of branches ? > > As said, there should be only 1 root. But I want to try some things with > git, so I will definietly create a new repo as well. no pb: there's a lot to learn from git workflows :) > There are different methods in the layout of branches, three come to my > mind, each with an example around specific versions where I think it > makes sense. For simplicity I took the time from the timestamp on the > server. Only the relevant commits are included in this demo, the branch > 'name' is written after the latest commit: > > (1) Don't branch off, but base the next minor release on the last minor > release with the latest patch. > > 7.0---7.0.243---7.1---7.1.330---7.2---7.2.088 'master' > > or with the beta versions: > > 7.1---7.1.330---7.2a---7.2a.019---7.2b--- > > ---7.2b.030---7.2c---7.2c.003---7.2---7.2.088 'master' > > We could still create branches for each minor release to point to > the latest patch. Branch 'vim-7.1' points to 7.1.330 and so on. This > way for example would work for the current layout of your repo, > without losing merge ability. > > Of course this sequence has to reflect the timeline, so it only > works, when there aren't any stable patches published in parallel > with some betat versions/patches. this is what is happening in the CVS official repository. what is also present there is a heavy use of tags (too many). > > (2) If there is some parallel publishing, then we have to create "real" > branches. The most obvious solution is to branch off, when > parallelism starts. > > 5.7.029---5.7.030---5.8---5.8.009 'vim-5.8' > / > 5.7---5.7.028---6.0aa---6.0ax---6.0ax.020---6.0---6.0.270 'master' > > There we could also create a branch 'vim-5.7' to point to 5.7.030. unless I'm wrong, we only have had parallel development between betas and the official last vim release. I personally discarded the alpha/beta releases because it was clouding the overall picture. > (3) Another solution is to branch off immediately at each release. This > is the easiest solution that will always work, but we'd get the > problem, that the 'master' branch will stay on the current minor > release and the features have to be rebased against the next minor > release one time. So this isn't really a solution, I shouln't even > have mentioned it. > > 7.0.001---7.0.243 'vim-7.0' > / > | 7.1.001---7.1.330 'vim-7.1' > | / > | | 7.2.001---7.2.088 'vim-7.2' > | | / > 7.0---7.1---7.2 'master' I like this solution, but we should have master='vim-7.2' instead. > > > I will also adjust the commit message somewhat, e.g.: > - extract a first single line summary as described by the git > conventions > - convert tabs to spaces (that's the reason, why the messages aren't > aligned properly in your github repo) > - remove the "Files:" section, it's not necessary within a VCS, --stat > is much nicer I tried to do that, and maybe forgot to change tabs into spaces. I wanted to keep as much info from Bram original patches. After some thoughts, maybe this need rework: I'll look into it. What do you mean by --stat ? >> About your last point (not being able to backport), > > forward-port > >> it's not true: you >> can still cherry-pick :) > > Hooray! > he he -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
