On 09-Oct-10, Bert Wesarg wrote:
> On Sat, Oct 9, 2010 at 03:43, Olaf Dabrunz <odabrunz@xxxxxxx> wrote:
> > When dependencies can be removed as well as added, tg depend add
> > needs to make sure that the new dependency can bring in changes
> > from a branch that has previously been removed as a dependency
> > from the current TopGit branch.
> >
> > This implementation uses an exported branch set up by tg export,
> > and merges the new dependency into the commit that corresponds to
> > the current base. Using the exported branch in the merge has the
> > advantage that removed dependencies do not appear as parents, and
> > the merge base selected by git merge does not include changes from
> > a removed dependency. As a result, these changes can be merged in
> > again if the new dependency brings in these changes.
> >
> > The tree of the merge commit is then used to create the next
> > commit on the TopGit base branch.
>
> I'm really not an expert, but history comes from the commits not from
> the trees. Just using an hand made tree and commit this to the base
> doesn't change anything, because somewhere in the parent commits is
> still the information, that we merged in a branch that we just tried
> to remove (i'm speaking for tg depend remove). But maybe I don't
When the hand made tree is committed (as a hand made merge) on top of
the base, we have a correct merge on top of the base.
This actually should change everything. After such a "tg depend add", we
have either brought in some removed dependency as well, or we did not.
If we didn't, the removed deps in the base's history do not matter for
subsequent merges done by "tg update". But if we did bring in a
previously removed dep, the removed deps in the base's history _would_
matter. But since we already made a successful merge on top of the
base's history with a correct tree, and this merge also brings in the
removed dep through the history from the new dep's side, subsequent "tg
update" merges will use this hand made merge as the merge base, which is
fine for future merges.
> understand what this patch changes. The only idea is, that we don't
> use merge commits for the base any more! Is this what this patch does?
Maybe I addressed this above already. But just to clarify, I left the
following description of the patch in this mail, because it describes
the patch with different words.
What the patch does is the following: it still creates a merge commit on
the base to bring in a new dependency, but this merge commit is crafted
to contain the "correctly" merged tree. So there are three steps:
- use tg export to create a completely separate history (the "temp
export branch") which _does not_ reference removed dependencies as
parents
- use git merge to merge in the new dependency on top of this
temp export branch -- as none of the removed dependencies are
referenced by the temp export branch, this merge is not influenced
by them and will do the right thing
- then take the tree (!) from that merge and hand-craft a new merge
commit with that tree and use the old base and the new dependency
as parents of this hand-crafted merge commit
Olaf
--
Olaf Dabrunz (Olaf.Dabrunz <at> gmx.net)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html