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: > > > > > > * Every time the patch stack is modified (that is, any time an > > > StGit command modifies anything at all), a new commit is made > > > to a log branch. Each StGit branch has one such log branch. > > > > We already have another commit for the patch history. If we add > > this, we end up with 3 commit for each patch command. People already > > complained that StGIT is slow, I wouldn't go this route. > > > 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. > As for the speed: we'll have to write one blob and one tree per > modified patch, plus one top-level tree and a small constant number of > blobs. (Caveat: my current implementation is too stupid to realize > that not all patches were modified all the time.) 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. > I'd like to try my scheme out first, however. It's potentially more > powerful, since it can be pulled between repositories and maybe even > merged. That's interesting indeed (though I don't fully understand all of this). > > > 2. The merged stack base is created with a normal recursive > > > merge. > > > > 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. And, after this merge, how do you merge common patches (but maybe slightly modified)? > > > 3. When a conflicting patch is pushed, we do the following: > > > > > > 1. For each of .ours, .theirs, .base0, ..., create a new > > > "b" tree just like we do when we normally push a patch. > > > If there are conflicts, autoresolve them like > > > merge-recursive does internally. > > > > > > 2. Create the single new "b" tree by making a recursive > > > merge of all these updated "b" trees. Represent any > > > conflicts like we usually do when pushing patches. > > > > 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. 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). > > I find this workflow pretty difficult to implement since the StGIT > > patches are pretty volatile. It might be better to use topic > > branches instead. > > > I agree that it's far from certain that this will be a very useful > workflow. But I'm willing to bet a couple of day's work that it is, so > I'll build a prototype and see. 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. -- Catalin - 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
