[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Smart merging [was: graphical merges]
From: |
Juliusz Chroboczek |
Subject: |
[Gnu-arch-users] Smart merging [was: graphical merges] |
Date: |
05 Apr 2004 19:12:28 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
>> Is there a detailed description of what star-merge does somewhere? I
>> sometimes find its behaviour confusing, and would like to know whether
>> it's my brain that's buggy.
MD> star-merge takes your revision and builds the "other" revision that
MD> you want to merge. It then looks through the patch logs to find the
MD> most recent revision shared by both in either's history and calls this
MD> "ancestor." If star-merge was called without -t (--three-way) then a
MD> changeset is computed from "ancestor" to "other," and then applied to
MD> "mine." Otherwise, just a tree-delta (renames, deletes, etc.) is
MD> applied to "mine" based on "ancestor" and "other," and then diff3 -m
MD> is used to merge the contents of files.
Does that mean that ``New-patches'' in a log is treated transitively?
In other words, ``New-patches: foo--devel--0--patch-3'' implies that
all of foo--devel--0--base-0 through --patch-2 have been integrated to
the current branch?
That would explain the star-merge behaviour I'm unhappy with.
I've got a branch foo--devel--0 and (possibly in a different
repository) a branch foo--debian--0, which contains the last stable
version from foo--devel--0 with a number of Debian-specific patches
(there's also a foo--release branch -- a tag of foo--devel --
involved, but that's irrelevant to the discussion). Now at some
point, there's a critical fix committed into foo--devel--0. The
Debian maintainer merges the fix into foo--debian (using replay), but
not the earlier changes made to foo--devel.
At some point in the future, a new stable version is tagged off
foo--devel. At which point the Debian maintainer merges foo--devel
into foo--debian. I might be wrong, but trying it out seems to show
that star-merge will omit all the changes made to foo--devel that are
older than the critical fix.
So I guess either I'm doing something wrong, or the data structures
are not suitable for that. For what it's worth, darcs deal with this
situation just like I would expect.
Juliusz
- Re: [Gnu-arch-users] graphical merges, (continued)
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Juliusz Chroboczek, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Matthew Dempsky, 2004/04/05
- [Gnu-arch-users] Smart merging [was: graphical merges],
Juliusz Chroboczek <=
- Re: [Gnu-arch-users] Fast commits, Robin Farine, 2004/04/03
- [Gnu-arch-users] Re: Fast commits, Stefan Monnier, 2004/04/03
- Re: [Gnu-arch-users] Re: Fast commits, Miles Bader, 2004/04/03
- Re: [Gnu-arch-users] Re: Fast commits, Tom Lord, 2004/04/04
- [Gnu-arch-users] Re: Fast commits, Stefan Monnier, 2004/04/04
- Re: [Gnu-arch-users] Re: Fast commits, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] Re: Fast commits, Robin Farine, 2004/04/04
- Re: [Gnu-arch-users] Fast commits, Colin Walters, 2004/04/03
- Re: [Gnu-arch-users] Fast commits, Miles Bader, 2004/04/03