http://blog.gmane.org/gmane.comp.package-management.vcs-pkg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/126 martin f krafft 2008-08-27T22:12:36 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/125 Ok, after reading the documentation again this seems to be the case. So my integration (or debian) branch should be a TopGit branch which depends on all the applied feature branches + upstream, and I should do the conflict resolution when the base for it is merged? When I'm trying to an octopus merge, git fails on the .top* files. When merging in one branch at a time the ours strategy works fine. But maybe I'm using an old version of git. Teemu Teemu Ikonen 2008-08-27T19:09:29 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/124 martin f krafft 2008-08-27T13:42:25 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/123 I already have, but TopGit does not really solve the same problem, namely serializing a set of possibly conflicting heads with the end result being identical to the state of an integration branch. At least it does not do this automatically without the need to create extra merged bases. TopGit is nice though, but it still needs some work. A 'tg clone' command which would pull also the bases automatically would be nice to have. Also, is there a trick to get the "ours" merge strategy used in .top* -files to work with octopus merge? Teemu Teemu Ikonen 2008-08-21T15:10:28 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/122 martin f krafft 2008-08-21T14:31:32 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/121 martin f krafft 2008-08-20T03:03:03 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/120 I think this would be great! Asheesh Laroia 2008-08-19T20:05:51 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/119 Oh, and on a personal note, I'm an INTP personality type, and can tend to be a real bastard at times (just google for kergoth and see the various IRC logs for example...).. just as a warning :) Chris Larson 2008-08-19T19:42:26 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/118 Greetings, I subscribed to the list a while back, but I don't believe I ever got around to introducing myself. My name is Chris Larson, but am most well known as Kergoth. I work in the embedded Linux field. I've done work on bootloaders, kernel, userland, distro, build tools, etc. I founded the OpenZaurus Linux distro for the Sharp Zaurus line of PDAs, and created the OpenEmbedded project, which was originally a portage fork. It exists because I got tired of gmake's limitations, and all of the existing distribution tools were limited, either lacking crosscompilation support, or expected to run the tools only -on- that distribution. I wanted a tool that would run anywhere, and could target any platform, and support multiple target packaging formats and distributions. The metadata repository is shared by multiple embedded distributions and projects, so in that aspect, the goal was quite similar to that of vcs-pkg.. collaboration. I've hacked on debian packages and tools, redhat packages and tools, and gentoo packages and tools, but never got around to pursuing actually becoming a developer for any (I know just how much time a distro can suck up..). Most of the OE target distros are debian based, as I found most debian distributionisms (I say that's a word, dangit) to be superior to redhat ones, and more stable than gentoo ones (i.e. interfaces(5)), though there are obvious exceptions. OE can output ipk, deb, or rpm files. Originally it could take either our metadata format or a source rpm as input (with a metadata conversion layer), but I doubt that's been maintained in my absence from the project (got burned out). I went a couple years without messing with distribution or build tools, but am finding my interest rekindled. On the source control front, I've experience using and maintaining CVS, svn, monotone, git, bk, svk, and a couple other types or repositories. Don't really know mercurial or bazaar, yet. I was the buildmeister / configuration management guy and a core developer of the Opie project (fork of Qtopia), also. Recently, I've been really enjoying messing with topgit and pristine-tar.. there's definate potential there, and I'm debating writing a new tool to better support that methodology for us crazy embedded folk :) I have a quick hack of a tg-rename here, by the way. It just updates the head & top-bases refs and zips through the branches, updating .topdeps for each, in case anyone wants such a thing. Sorry for the disorganization of that intro, I tend to wander at times ;) Chris Larson 2008-08-19T19:39:05 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/117 But we _REALLY_ want to do this only for stage branches! Yes, and it should certainly warn you about this at any rate, and give you a chance to resolve this manually - possibly taking advantage of rerere. So, my idea: tg export --quilt should set up and maintain a private working branch where it merges all the exported branches, one-by-one (possibly doing the sling as described above first). In case there is a conflict, it either aborts or gives you a chance to resolve it and go on with the export. It could also offer you to save your resolution in a new tie branch for future auto-slinging, but it would be tricky to figure out exactly what patches does it depend on. Overally, I'd start simply with implementing the sequential merge and forget about slinging resolutions from tie branches. The former should be very simple and solve most of the cases, especially when using rerere. For the hairy cases, you can just add a dependency for now - sort of preliminary serialization. :-) The slinging might be feasible, but would be much more complicated to implement. I think this can simply wait. But to be clear, I don't plean to do any of this myself in the near future anyway, since this case is not that important for me - I now need TopGit to support remote topic branches instead. So if this is a priority for you, you need to implement this on your own. But the sequential merge part should be really easy, just something like git checkout -b tmp foreach patch_branch git merge patch_branch cat .topmsg >output/patch.diff git diff HEAD^..HEAD >>output/patch.diff with all the frills. ;-) (Maybe make a special "show diff between X and Y instead of base and head" flag for tg patch so that we can rely on it for the frills.) Petr Baudis 2008-08-13T00:18:09 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/116 martin f krafft 2008-08-12T23:10:37 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/115 martin f krafft 2008-08-12T23:07:27 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/114 This seems to be in principle the same as the tie branches. It might make sense to have a way to _optionally_ make a tie branch. How should that work? Maybe there needs to be even an explicit support for this - should TopGit just check the dependency tree when sequencing the topic branches and have a step that says: "I'm going to sequence branch A. If there is branch T that has only already sequenced branches + branch A as dependencies, use T's content instead of A." Would that be satisfactory? Finding out this information would be very expensive, of course. But for other reasons, we might want to keep a cache of branch dependencies. Of course, in the case of A1--A2--A3--A4--C / B1--B2--B3--B4. the sequenced branches would still be like A1--A2--A3--A4--B1--B2--B3--C unless you create the T1..T4 branches manually. Petr Baudis 2008-08-12T22:59:16 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/113 martin f krafft 2008-08-12T22:41:55 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/112 I don´t know if it fits topgit, but this is what Junio uses: http://article.gmane.org/gmane.comp.version-control.git/24498 Basically he creates a new feature branch that is the merge of the conflicting branches (it works for both semantically and explicit conficts), and there he resolves the conficts. Then if one of the branches are merged in master (in you case a patch is created) then the other branch fast-forward to the merge. HTH, Santi Santi Béjar 2008-08-12T21:28:42 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/111 I thought about this too, but have no experience with rerere. Bert Bert Wesarg 2008-08-12T18:54:00 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/110 Bruno Cornec 2008-08-12T18:09:40 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/109 martin f krafft 2008-08-12T17:52:06 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/108 martin f krafft 2008-08-12T17:48:46 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/107 Hi, On Tue, Aug 12, 2008 at 01:18:54PM -0300, martin f krafft wrote: yes, that is good point. Well, at least we're not _worse_ off than when using a classical patch series instead of TopGit, since all the downsides would be the same as if we had this "fake dependency", right? Though of course, it would be nice if we could do better here. I'm sorry, I don't follow you here. If there is a dependency, TopGit will always serialize A first, if there is no dependency, reordering won't help you since B's base won't accomodate A. First, let's consider the simplest situation: A--C / B. (These are branches, not commits!) In this case, we _CAN_ actually serialize A,B by doing a "resolution sling" operation - simply take diff(A,C) instead of diff(B^,B)! The trouble is that we will have: A1--A2--A3--A4--C / B1--B2--B3--B4. Here, we would have to squash B1..B4 to B in order to be able to do this, which is of course undesirable. We want to sling the C resolution in front of B1, and there seems to be no simple way to do this - or can anyone see any? So we would have to ask the user to propagate it instead. Let's call these "tie branches": A1--A2--A3--A4------------------C \ / T1--T2--T3--T4 /tree(T4) == tree(C) / / / / / B1--B2--B3--B4--' I guess this is just a more formalized way of rewording your other proposal. Then, TopGit, instead of directly setting up C_base by merging A4+B4, would create the tie branches T1..T4 and use T4 as C_base. I'm not really happy about this idea, though. It would complicate TopGit even much more than it is now, and I'm not sure if this is worth it instead of just requiring you to maintain your dependencies more carefully when you intend to serialize your series later. Petr Baudis 2008-08-12T17:32:57 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/106 Isn't this what git-rerere is for? If TopGit doesn't use rerere, maybe it would be easy to add... Have fun, Avery Avery Pennarun 2008-08-12T16:25:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.package-management.vcs-pkg