Christian MICHON, 23.01.2009:
>
> On Fri, Jan 23, 2009 at 12:29 AM, Markus Heidelberg
> <markus.heidelb...@web.de> wrote:
> >> 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'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.
> As you mentioned later in this
> thread, you're not familiar with vim development from the start
> (neither am I: I missed the pre-3.0 days, as I did not have an atari).
> Maybe Bram should comment on this.
>
> seriously, each branch having its own root was my way of representing
> that each vim main release usually has too many changes with the
> previous one.
Of course the diff between 7.1.330 and 7.2 is not usable at all. It's a
big chunk of code changes without any history, but we can't do anything
against it.
> 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.
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.
(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.
(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 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 just got a patch from the git mailing list which will make the
> maintenance of my vim repo much easier :)
I saw it.
> About your last point (not being able to backport),
forward-port
> it's not true: you
> can still cherry-pick :)
Hooray!
Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
