Re: State of the repository conversion

[Eli Zaretskii]

> From: Steinar Bang <address@hidden>
> Date: Thu, 20 Mar 2014 22:10:01 +0100
> 
> >>>>> Eli Zaretskii <address@hidden>:
> 
> > Why is it more natural?  If the same bug exists on the trunk, you
> > could fix it in either of the two places first.
> 
> I live in the land of refactoring, and one thing that happens
> immediately after a branch for release, is that people tend to go wild
> with refactoring that has been delayed pending the release.
> 
> So it makes most sense to look for the bug where it has been reported.
> 
> As for merging the fix into master: the master may have changed so much
> that the fix doesn't make sense anymore.

In both of these cases, the fix should not be applied to the trunk
anyway.  So this is not the situation I was describing, where a fix is
applicable to both the trunk and the branch.

When a fix is only applicable to the branch, just apply it there, and
don't worry to merge or cherry-pick anywhere else.

> That said, a merge has a better change at finding the correct place to
> apply, in the refactoried code, than a cherry-pick does.  But the merge
> result needs to be inspected after the merge.

What bzrmerge.el does, when we merge a fix from the branch, is
effectively a cherry-pick, but it also records the branch commit as
being present on the trunk.  If the fix is not applicable to the
trunk, we end up with a commit that didn't bring any changes in terms
of diff (because the changes will be edited out before committing
after the merge).  I'm not sure this will work with git, btw.