On 2008-02-20 23:06:07 +0000, Catalin Marinas wrote:
> On 13/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>
> > On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:
> >
> > > On 13/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
> >
> > I intend to get rid of the current per-patch log. It doesn't save
> > enough information to be useful anyway.
>
> I use it from time to time. The commit message gives you the commit
> id of the patch at that time and the commit diff gives you the
> changes made by a refresh. It's mainly useful if you ran refresh and
> don't remember what changes you've added.
Ah, OK. Well, the per-branch log will be able to give you all of that.
> > These simple create-an-object-from-data-on-stdin commands should
> > be fast enough that this won't be a problem (and if a dozen extra
> > calls to git is too expensive, we'll just have to build a git
> > command that can take them all in one go).
>
> As I said in the other e-mail, it needs a run through stg-prof to
> see what the impact is with large number of patches.
Agreed.
> > > A recursive merge with the HEAD of another stack containing
> > > similar patches? If yes, when pushing it is likely that the
> > > patches already in the base will be emptied during a three-way
> > > merge.
> >
> > No, a merge of the stack _bases_, with all patches popped off. And
> > this would be a regular git merge, so no emptying of patches.
>
> OK, but we would need the StGIT information about stack bases to be
> passed between repositories.
Yes.
> > > My idea is to merge each patch with the corresponding commit in
> > > the other branch and leave the base unchanged (like "stg sync").
> > > The difficulty is in identifying which commit from the other
> > > branch has to be used. We could try guessing by the number of
> > > changes or just using the subject line, assuming that it won't
> > > change (or an extra id field in the commit text).
> >
> > I was thinking about the same thing: just match up the patches
> > with the same name. If the user has renamed a patch, she can
> > coalesce the two manually.
>
> Ah, OK. But how do we pass the patch name information? I think the
> commit log wouldn't be enough as it can be easily modified.
The per-branch log will contain this information.
> There is also a situation when patches on the remote stack were
> reordered and with some conflicts fixed. In this case, merging gets
> even more complicated (I think darcs solves this by making all the
> patches immutable but the base feature of StGIT is that patches are
> easily modifiable).
The scheme I described should be able to handle this. When a patch is
pushed, its base is set, and we can just make a normal 3-way merge.
Consider a stack with two patches, a:A->B and b:B->C (A, B, and C are
commits). In one branch, this is modified to a:A->B1 and b:B1->C1; and
in the other, the patch order is changed so we get b:A->X and a:X->C.
When we merge these, the base is unchanged (so still A), and the patch
order is b, a (since it was changed in one branch but not the other).
1. First we push b. The A->X variant applies trivially, but the
B1->C1 variant needs the standard 3-way merge. The merge is
force-resolved (that is, any conflicts are ignored, and just
stored in the result tree); call the result Y. Then we make a
3-way merge with C as ancestor and X and Y as ours and theirs;
the result (possibly fixed up manually by the user) is stored as
the new patch top -- call it Z. So now we have pushed b:A->Z.
2. Then we push a. Both the A->B1 and the X->C variants need 3-way
merging, since we apply the patch on top of Z; call the resulting
(possibly force-resolved) trees P and Q. Then we make a 3-way
merge with B as ancestor and P and Q as ours and theirs; the
result (possibly fixed up manually by the user) is stored as the
new patch top -- call it R. So now we have pushed a:Z->R.
> It would be nice to allow an easy workflow for people trying to
> share the same repository and benefit from StGIT. There was a recent
> thread on the Linux kernel lists about a new branch, linux-next,
> which included some discussions on GIT, patch management, rebasing
> etc. Some people mentioned that they ended up using classic patch
> management (quilt) and storing the patches in a repository which can
> be shared between developers.
Yes, absolutely. And this is precisely what we'll get out of this if
it pans out. But if it doesn't, the _same_ per-branch log format can
be used with a different conflict resolution scheme -- for example, we
could compute the diff text for each of the patches and just merge
those, which gives the same result as if the user had stored patches
in the repository.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
-
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
