_sc_, 13.02.2009:
>
> On Thursday 12 February 2009 5:09 pm, Nazri Ramliy wrote:
> >
> > On Fri, Feb 13, 2009 at 5:04 AM, _sc_ <[email protected]> wrote:
> > > - merge the repository feature.h with my modified one?
> >
> > Yes if you have 'git add'ed your modification to feature.h and that
> > changes happens to be exactly the same as the new change coming
> > in from the 'reposition end'. If it's not the same then the merge will not
> > happen.
>
> this sounds complicated and iffy -- doesn't get a lot of
> points for likability either
I think the description was expressed a bit unlucky. What he wanted to
say is that you should just commit your changes. Of course the change
from the repository will surely never be the same. But a merge will
happen anyway.
> > 2. Commit it into your own branch, and rebase that branch against
> > its 'parallel' remote branch every now and then when the
> > 'repository end' is updated.
>
> sounds doable, however complicated -- the downside i see to
> this is the "every now and then" part -- i'd be back to my
> old "svn ways", watching the update log and hopefully
> catching any updates to feature.h
As stated in my previous post, I don't recommend a rebase. That's easy
to do, if you have only ONE remote upstream branch. But in this case you
have TWO or more: 'vim-with-runtime' and one or more features.
> > 3. Manually keep it as separate patches.
>
> this sounds like something i can do with my current state of
> knowledge -- in fact, has none of the downsides i've been
> moaning about concerning all the other options -- i'll be
> reading the patch and diff man pages in the next few days,
> but i envision my update script doing something along the
> lines of:
A patch solution should not be necessary with a DVCS.
> patch -R -p0 src/feature.h < myfeat.patch
> git pull
> patch -p0 src/feature.h < myfeat.patch
Note that if the feature branch is getting updates, you have to do an
additional "git merge origin/feat/xyz". You should add it into your
update script, even if in the normal case it's necessary. And the
updates can be one of two kinds:
1) enhancements or bugfixes of the feature
2) merge commits with solved conflicts
The first one is obvious. The second means, that a new Vim patch
conflicts with the feature and I manually solved the conflict. So
instead you having to solve the conflict yourself, you can just merge my
conflict resolution.
If you at first do "git pull" which means you firstly merge the
'vim-with-runtime' branch, then the conflict arises. So you should
rather firstly merge the feature branches, which leads to an update like
this instead of merely doing "git pull":
git fetch
git merge origin/feat/a
git merge origin/feat/b
git merge origin/vim-with-runtime
Or you could add your feature branches to your [branch "custom"]
section, so that it looks like this:
[branch "custom"]
remote = origin
merge = refs/heads/vim-with-runtime
merge = refs/heads/feat/a
merge = refs/heads/feat/b
Which will use the octopus merge strategy (merging multiple branches at
the same time), which I currently don't recommend in the README, because
once I did it and got merge conflicts, the part with the conflict
markers was not enough to resolve the conflict properly.
I have to investigate some more for the README, it indeed gets a bit
more complicated, if you have more then one corresponding remote
upstream branch.
Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
