{"thread":{"id":"1648","subject":"Merges without bases","startedAt":"2005-08-25T21:10:28Z","lastAt":"2005-09-09T12:02:52Z","messageCount":12,"participants":["Darrin Thompson","Daniel Barkalow","Junio C Hamano","Martin Langhoff","Tim Ottinger","Eric W. Biederman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7760","messageId":"1125004228.4110.20.camel@localhost.localdomain","threadId":"1648","inReplyTo":null,"subject":"Merges without bases","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-08-25T21:10:28Z","receivedAt":"2005-08-25T21:10:28Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"I have a weird situation I want to support. I want to be able to merge a\nforeign-tree repeatedly.\n\nWhat makes the foreign tree foreign is that it may not yet share any\nhistory with this branch.\n\nWhat I tried to do was fetch foreign tree material and run octopus.\nOctopus understandably barfed when it could not find a merge base for\nthe foreign tree.\n\nWhat I think is newsworthy is that I figured out a sick way to get it\ndone. I created an empty tree object and used it as the merge base for\ngit-read-tree -m.\n\nCould git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1\nas an implicit empty tree?\n\nOnce that is done, git octopus will be able to handle the no merge base\ncase.\n\n--\nDarrin\n"},{"id":"7763","messageId":"1125005378.4110.25.camel@localhost.localdomain","threadId":"1648","inReplyTo":"1125004228.4110.20.camel@localhost.localdomain","subject":"Re: Merges without bases","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-08-25T21:29:38Z","receivedAt":"2005-08-25T21:29:38Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"That didn't come out clearly. Restating:\n\nOn Thu, 2005-08-25 at 16:10 -0500, Darrin Thompson wrote:\n> Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1\n> as an implicit empty tree?\n> \n\nCould git-read-tree -m treat an argument of \"0\" as an implicit empty\ntree? It mainly seems useful as the first arg in the three arg -m form.\n\n> Once that is done, git octopus will be able to handle the no merge base\n> case.\n> \n\nOnce that is done, git octopus could _optionally_ handle the \"I can't\nfind a merge base\" case by passing 0 as the merge base to git-read-tree.\n\n--\nDarrin\n"},{"id":"7769","messageId":"7vvf1tps9v.fsf@assigned-by-dhcp.cox.net","threadId":"1648","inReplyTo":"1125004228.4110.20.camel@localhost.localdomain","subject":"Re: Merges without bases","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-25T22:26:36Z","receivedAt":"2005-08-25T22:26:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Darrin Thompson <darrint@progeny.com> writes:\n\n> I have a weird situation I want to support. I want to be able to merge a\n> foreign-tree repeatedly.\n>\n> What makes the foreign tree foreign is that it may not yet share any\n> history with this branch.\n\nI believe that's exactly what Linus did when he merged gitk into\ngit.  As you discovered, the initial one could easily be\nscripted, if you wanted to, with something like this:\n\n        #!/bin/sh\n        #\n        # git-merge-projects-script\n        #\n        . git-sh-setup-script || die \"Not a git archive.\"\n\n        foreign_project=\"$1\"\n        head=`git-rev-parse --verify HEAD` &&\n        foreign=`git-rev-parse --verify $foreign_project^0` || exit\n\n        rm -f .no-such-file\n        empty=`GIT_INDEX_FILE=.no-such-file git-write-tree`\n        git-read-tree -m -u $empty $head $foreign ||\n        git-merge-cache -o git-merge-one-file-script -a || exit\n\n        tree=`git-write-tree` &&\n        echo Merge $foreign_project in. |\n                git-commit-tree $tree -p $head -p $foreign \\\n                >\"$GIT_DIR/HEAD\" &&\n\tgit show-branch --more=10 HEAD $foreign_project\n\nUnlike my other \"scripts written in e-mail buffer\", I\nactually tested this one ;-).\n\n\t$ cd /var/tmp && rm -fr junk && mkdir junk\n\t$ cd /var/tmp/junk\n\t$ git init-db\n        $ cat >./git-merge-projects-script\n        : type the above and end with ^D\n\t$ chmod +x git-merge-projects-script\n        $ git add git-merge-projects-script\n\t$ git commit -m 'My Project'\n\t$ git fetch http://www.kernel.org/pub/scm/git/git.git master:git\n\t$ ./git-merge-projects-script git\n\t$ git diff git..HEAD\n\nThe \"weird\" situation to cause \"git resolve\" barf happens only\nfor the first time and once they are merged you can repeatedly\npull from that subset foreign branch without any \"weirdo\"\nsupport.  Since even the oddball initial case can easily be\nscripted like above, and that initial case should happen very\nvery rarely anyway, I do not think this deserves any core-level\nchange, such as changes to read-tree you suggest.\n\nThe above merge-projects-script _may_ deserve a \"contrib\"\nstatus to be in the source tree, though.\n\nOne thing that makes me reluctant to recommend this \"merging\nunrelated projects\" business is that I suspect that it makes\nthings _much_ harder for the upstream project that is being\nmerged, and should not be done without prior arrangement; Linus\nmerged gitk after talking with paulus, so that was OK.\n\nSuppose the above \"My Project\" is published, people send patches\nfor core GIT part to it, and you as the maintainer of that \"My\nProject\" accept those patches.  The users of \"My Project\" would\nbe happy with the new features and wouldn't care less where\ntheir core GIT tools come from.  But how would _I_ pull from\nthat \"My Project\", if I did not want to pull unrelated stuff in?\n\nIn this particular example, it only has git-merge-projects\nscript which _is_ related to core GIT so this objection would\nnot apply, but if I were paulus (gitk maintainer whose project\nhas only one file, the great gitk script) and if the git.git\nrepository had a lot of changes to gitk, I would like to pick up\nupdates from there without pulling the rest of core GIT.  That\nis not something the current set of tools support, and offhand I\ndo not think of a good way to implement it cleanly.  That is the\nreason why I never pick up any patch for gitk myself --- I\nalways slurp changes to gitk via paulus tree, or feed patches\nto him and then slurp the changes from him.\n\nWhat I think _might_ deserve a bit more support would be a merge\nof a foreign project as a subdirectory of a project.  Linus\ncould have made gitk/ subdirectory in the core git project, and\nmade that subtree in sync with the toplevel of paulus gitk\nproject.  But even this could be done without the core-level\nchange.  You would run ls-tree of the main project to figure out\nthe tree object name of that subdirectory, and 3-way merge that\nwith the top of the paulus project tree, and replace the tree\nentry with the resulting tree.\n\nOnce that kind of \"merging an unrelated project as a\nsubdirectory of a superproject\" workflow is established, pulling\nfrom a subdirectory that corresponds to my project after my\nproject gets merged this way into the superproject would become\neasier to manage and would even become a useful workflow\nelement.\n"},{"id":"7772","messageId":"1125010764.4110.35.camel@localhost.localdomain","threadId":"1648","inReplyTo":"7vvf1tps9v.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merges without bases","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-08-25T22:59:24Z","receivedAt":"2005-08-25T22:59:24Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"On Thu, 2005-08-25 at 15:26 -0700, Junio C Hamano wrote:\n>         empty=`GIT_INDEX_FILE=.no-such-file git-write-tree`\n>         git-read-tree -m -u $empty $head $foreign ||\n\nooooo. Tricky.\n\nThanks for the script. That's a bad, bad hack. :-)\n\n> One thing that makes me reluctant to recommend this \"merging\n> unrelated projects\" business is that I suspect that it makes\n> things _much_ harder for the upstream project that is being\n> merged, and should not be done without prior arrangement; Linus\n> merged gitk after talking with paulus, so that was OK.\n> \n\nWhat I'm going to do is actually an inversion of that. Publishing a\nrepository with the _intent_ of being merged into existing history, and\nobserving obvious naming conventions as the \"prior arrangement\".\n\nI thought once I got the initial baseless merges done and committed that\nI do fetch-octopus from that point on. But octopus was still complaining\nabout not finding a merge base. I'm going to verify that I didn't just\nmess something up in the process.\n\nIf I can get octopus working as the tool for doing merges _after_ the\nbaseless merges then I can live with the current situation. \n\n--\nDarrin\n"},{"id":"7766","messageId":"Pine.LNX.4.63.0508252333550.23242@iabervon.org","threadId":"1648","inReplyTo":"7vvf1tps9v.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merges without bases","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-26T04:09:04Z","receivedAt":"2005-08-26T04:09:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 25 Aug 2005, Junio C Hamano wrote:\n\n> One thing that makes me reluctant to recommend this \"merging\n> unrelated projects\" business is that I suspect that it makes\n> things _much_ harder for the upstream project that is being\n> merged, and should not be done without prior arrangement; Linus\n> merged gitk after talking with paulus, so that was OK.\n\nI'd still like to revive my idea of having projects overlaid on each\nother, where the commits in the project that absorbed the other project\nsay, essentially, \"also include this other commit, but any changes to\nthose files belong to that branch, not this one\". That way, Linus could\nhave included gitk in git, but changes to it, even when done in a git\nworking tree, would show up in commits that only include gitk. (git\nactually can handle this with the alternative index file mechanism that\nLinus mentioned in a different thread.)\n\nDefinitely post-1.0, of course.\n\n> Suppose the above \"My Project\" is published, people send patches\n> for core GIT part to it, and you as the maintainer of that \"My\n> Project\" accept those patches.  The users of \"My Project\" would\n> be happy with the new features and wouldn't care less where\n> their core GIT tools come from.  But how would _I_ pull from\n> that \"My Project\", if I did not want to pull unrelated stuff in?\n\nWith the right info, the tools could be made to automatically generate\nsuitable commits, because those files would be tracked by a separate index\nfile and committed into a separate branch, which would then be reincluded\n(by reference) in the containing project.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7780","messageId":"7vzmr5gmb4.fsf@assigned-by-dhcp.cox.net","threadId":"1648","inReplyTo":"Pine.LNX.4.63.0508252333550.23242@iabervon.org","subject":"Re: Merges without bases","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T08:00:15Z","receivedAt":"2005-08-26T08:00:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> I'd still like to revive my idea of having projects overlaid on each\n> other, where the commits in the project that absorbed the other project\n> say, essentially, \"also include this other commit, but any changes to\n> those files belong to that branch, not this one\". That way, Linus could\n> have included gitk in git, but changes to it, even when done in a git\n> working tree, would show up in commits that only include gitk. (git\n> actually can handle this with the alternative index file mechanism that\n> Linus mentioned in a different thread.)\n\nYes, I would love to see that cleanly done in a way that does not\nconfuse uninitiated (not being sarcastic at all.  Just cheering\nup somebody with a better idea than I have --- I would be lost\nif I were to be tasked to do it by Emperor Penguin himself or\nsomebody else ;-)).\n\nTonight I added another root in the git.git repository, but I\ncheated.\n\n> Definitely post-1.0, of course.\n\nAgreed.\n"},{"id":"7791","messageId":"46a038f905082602176f9eef5d@mail.gmail.com","threadId":"1648","inReplyTo":"7vvf1tps9v.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merges without bases","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T09:17:03Z","receivedAt":"2005-08-26T09:17:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/26/05, Junio C Hamano <junkio@cox.net> wrote:\n> their core GIT tools come from.  But how would _I_ pull from\n> that \"My Project\", if I did not want to pull unrelated stuff in?\n\nand then... \n\n> What I think _might_ deserve a bit more support would be a merge\n> of a foreign project as a subdirectory of a project.  Linus\n\ntla has an interesting implementation (and horrible name) for\nsomething like this. In Arch-speak, they are called 'configurations',\na versioned control file that describes that in subdirectory foo we\nimport from this other repo#branch.\n\nIn cvs, you just do nested checkouts, and trust a `cvs update` done at\nthe top will do the right thing;  and in fact recent cvs versions do.\n\nAfter using cvs and arch for a while, my opinion is that all this\nstuff is _bad_, and you want a makefile that pulls the projects\ntogether when you build them. Different projects are going to use\ndifferent SCMs anyway, and you'll have to live with how to tag a\nrelease across repositories/scms, and I haven't seen any answer I\nlike.\n\ncheers,\n\n\nmartin\n"},{"id":"7812","messageId":"Pine.LNX.4.63.0508261150320.23242@iabervon.org","threadId":"1648","inReplyTo":"46a038f905082602176f9eef5d@mail.gmail.com","subject":"Re: Merges without bases","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-26T16:37:56Z","receivedAt":"2005-08-26T16:37:56Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 26 Aug 2005, Martin Langhoff wrote:\n\n> On 8/26/05, Junio C Hamano <junkio@cox.net> wrote:\n> > their core GIT tools come from.  But how would _I_ pull from\n> > that \"My Project\", if I did not want to pull unrelated stuff in?\n>\n> and then...\n>\n> > What I think _might_ deserve a bit more support would be a merge\n> > of a foreign project as a subdirectory of a project.  Linus\n>\n> tla has an interesting implementation (and horrible name) for\n> something like this. In Arch-speak, they are called 'configurations',\n> a versioned control file that describes that in subdirectory foo we\n> import from this other repo#branch.\n>\n> In cvs, you just do nested checkouts, and trust a `cvs update` done at\n> the top will do the right thing;  and in fact recent cvs versions do.\n\nThe problem with both of these (and doing it in the build system) is that,\nwhen a project includes another project, you generally don't want whatever\nrevision of the included project happens to be the latest; you want the\nrevision of the included project that the revision of the including\nproject you're looking at matches. That is, if App includes Lib, and\nyou're looking at an App commit, you want to have the version of Lib that\nthe commit was made with, not the latest version of Lib, which may not be\nbackwards compatible across non-release commits, or, in any case, won't\nhelp in reconstructing a earlier state. I think a primary function of a\nSCM is to be able to say, \"It worked last Friday, and it's broken now.\nWhat's different?\" If the answer is, \"On Saturday, we updated the\nincluded Lib to their version from Thursday, which is broken\", it'll be\nreally hard to track down without special tracking.\n\nI think it's the lack of the special tracking, therefore, that makes this\nnot a good feature in most SCMs, and makes them not better than having the\nbuild system do it (and potentially worse, if you've got your build system\nchecking out a version specified in a version-controlled file). But I\nthink that git can do better, including support for the required version\nsometimes being a locally modified one and sometimes being the official\none when the local modifications have been accepted upstream.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7838","messageId":"46a038f90508262348b25d1c8@mail.gmail.com","threadId":"1648","inReplyTo":"Pine.LNX.4.63.0508261150320.23242@iabervon.org","subject":"Re: Merges without bases","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-27T06:48:53Z","receivedAt":"2005-08-27T06:48:53Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/27/05, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> The problem with both of these (and doing it in the build system) is that,\n> when a project includes another project, you generally don't want whatever\n> revision of the included project happens to be the latest; you want the\n> revision of the included project that the revision of the including\n> project you're looking at matches. That is, if App includes Lib, and\n\nExactly - so you do it on a tag, or a commit date with cvs. With Arch,\nGIT and others that have a stable id for each commit, you can use that\nor the more user-friendly tags.\n\nThe project pulling the libs has the makefile, and the makefile says\n'pull library-foo revision xxx'. If a later revision yyy is known to\nwork well, you update the makefile and commit it. Perfectly version\ncontrolled, no need for special purpose machinery ;)\n\nThe good thing here is that a makefile will know how to handle the\nsituation if the external lib is hosted in Arch, in SVN, or Visual\nSourceSafe. If your external lib is only available as a tarball in a\nurl, you can fetch that and uncompress it too. Arch configurations are\n_cute_ but useless in any but the most narrow cases.\n\nI want my SCM to be a good SCM, but this kind of interop is better\nleft to general purpose languages. Letting the build system do it\nseems to be 'best-practice' and the right thing to do.\n\ncheers,\n\n\nmartin\n"},{"id":"7848","messageId":"Pine.LNX.4.63.0508271544100.23242@iabervon.org","threadId":"1648","inReplyTo":"46a038f90508262348b25d1c8@mail.gmail.com","subject":"Re: Merges without bases","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-27T20:49:43Z","receivedAt":"2005-08-27T20:49:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 27 Aug 2005, Martin Langhoff wrote:\n\n> On 8/27/05, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> > The problem with both of these (and doing it in the build system) is that,\n> > when a project includes another project, you generally don't want whatever\n> > revision of the included project happens to be the latest; you want the\n> > revision of the included project that the revision of the including\n> > project you're looking at matches. That is, if App includes Lib, and\n>\n> Exactly - so you do it on a tag, or a commit date with cvs. With Arch,\n> GIT and others that have a stable id for each commit, you can use that\n> or the more user-friendly tags.\n\nI'm thinking of cases like openssl, openssh, and libcrypto. Openssl and\nopenssh both use libcrypto but not each other (looking at the ldd output,\nrather than packaging). However, it would be too much of a pain to work\ndirectly on libcrypto without working through some other package, because\nthe library doesn't have its own applications. Furthermore, if you're\ndoing much to libcrypto, you're likely doing it in the context of a\nparticular application (say, for example, ssh needs a new cipher that\nisn't supported for SSL at the time). You'd want to make simultaneous\nchanges to libcrypto to implement the new feature and to openssh to use\nit; neither can be validated until the other is written, which means that\nyou'll have both projects checked out and dirty (in the cache sense) at\nthe same time, and be building the using project.\n\nIt would also be good to be able to check in this whole thing through the\nversion control system, rather than partially through a change to the\nbuild system. That is, if I change the included libcrypto, commit it, and\ncommit the including openssh, the system as a whole should understand that\nI want to change which commit of libcrypto gets used. Similarly, it would\nbe good to merge changes into the libcrypto used by openssh with the same\nprocedure used to merge changes to openssh itself, including supporting\nnon-fast-forward when there's a local version in use.\n\n(Of course, currently, libcrypto is strictly part of openssl, because it\nwould be too much of a pain with the present version control to make it\nindependant, and openssh depends on openssl, despite not even linking\nagainst -lssl, because openssl got libcrypto first.)\n\n> The good thing here is that a makefile will know how to handle the\n> situation if the external lib is hosted in Arch, in SVN, or Visual\n> SourceSafe. If your external lib is only available as a tarball in a\n> url, you can fetch that and uncompress it too. Arch configurations are\n> _cute_ but useless in any but the most narrow cases.\n\nCertainly, if it's sufficiently external to be in a different SCM it\nshould be handled by the build system. Actually, if it's even nearly that\nexternal, it's probably going to be handled best by requiring people to go\nget it themselves.\n\nI find it odd that you say that the standard approach is to have the build\nsystem fetch a version of the included package; my experience is that\nprojects either just report (or fail to report) a dependancy on having the\nother package or they copy the project into their project. The former\nmeans they can't change it (which is generally good, unless it becomes\nnecessary), while the latter causes update problems (c.f. zlib).\n\nI think that Arch configurations and the CVS equivalent are, in fact,\nuseless, but that this is only due to implementation being insufficiently\nclever, not due to the concept being inherently bad; I feel the same way\nabout distributed development under Arch, which is really nice under git,\nso I have hope that something better could be done.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8202","messageId":"43207C92.4040103@progeny.com","threadId":"1648","inReplyTo":"1125010764.4110.35.camel@localhost.localdomain","subject":"Re: Merges without bases","fromName":"Tim Ottinger","fromEmail":"tottinge@progeny.com","sentAt":"2005-09-08T18:01:54Z","receivedAt":"2005-09-08T18:01:54Z","isPatch":false,"sender":{"key":"tottinge@progeny.com","avatar":null},"body":"Darrin Thompson wrote:\n\n>What I'm going to do is actually an inversion of that. Publishing a\n>repository with the _intent_ of being merged into existing history, and\n>observing obvious naming conventions as the \"prior arrangement\".\n>\n>I thought once I got the initial baseless merges done and committed that\n>I do fetch-octopus from that point on. But octopus was still complaining\n>about not finding a merge base. I'm going to verify that I didn't just\n>mess something up in the process.\n>\n>If I can get octopus working as the tool for doing merges _after_ the\n>baseless merges then I can live with the current situation. \n>  \n>\n\nHeh.  Git repositories as components.\n\n-- \n                             ><>\n... either 'way ahead of the game, or 'way out in left field.\n"},{"id":"8232","messageId":"m1hdcuo3df.fsf@ebiederm.dsl.xmission.com","threadId":"1648","inReplyTo":"7vzmr5gmb4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merges without bases","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-09-09T12:02:52Z","receivedAt":"2005-09-09T12:02:52Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n>\n>> I'd still like to revive my idea of having projects overlaid on each\n>> other, where the commits in the project that absorbed the other project\n>> say, essentially, \"also include this other commit, but any changes to\n>> those files belong to that branch, not this one\". That way, Linus could\n>> have included gitk in git, but changes to it, even when done in a git\n>> working tree, would show up in commits that only include gitk. (git\n>> actually can handle this with the alternative index file mechanism that\n>> Linus mentioned in a different thread.)\n>\n> Yes, I would love to see that cleanly done in a way that does not\n> confuse uninitiated (not being sarcastic at all.  Just cheering\n> up somebody with a better idea than I have --- I would be lost\n> if I were to be tasked to do it by Emperor Penguin himself or\n> somebody else ;-)).\n\nI think when it comes to simplicity it would be better to have \nsomething that would filter all of the changes on a branch\nby pathname and create a branch against the original project\nwith just those changes.\n\nThen we can do the noop merge of that branch into the larger\nproject, and we can merge that branch into the original project.\n\nThe nice part of doing it after the fact by just filtering changes\nis you don't have to plan ahead to handle that case, which\nshould be a lot easier to handle.\n\nThe set of pathnames to filter could be easily stored in the .git\nmetadata so doing repeatedly is straight forward.\n\nEric\n"}]}