{"thread":{"id":"21030","subject":"Feature Enhancement Idea.","startedAt":"2009-09-23T06:17:58Z","lastAt":"2009-09-24T16:45:26Z","messageCount":11,"participants":["Deon George","Christian Couder","Johan Herland","Ciprian Dorin, Craciun","Junio C Hamano","Jakub Narebski","Eric Raible"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"123661","messageId":"5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com","threadId":"21030","inReplyTo":null,"subject":"Feature Enhancement Idea.","fromName":"Deon George","fromEmail":"deon.george@gmail.com","sentAt":"2009-09-23T06:17:58Z","receivedAt":"2009-09-23T06:17:58Z","isPatch":false,"sender":{"key":"deon.george@gmail.com","avatar":null},"body":"Hi,\n\nI'm not sure if this is the right place, but I thought I'd post my\nidea and maybe somebody will either redirect me to the right place, or\ngive me that \"that wont happen\".\n\nIm fairly new to GIT (wish I had discovered it long ago), and I really\nlike using it - great work guys/garls :)\n\nMy idea is to enhance GIT to support (I'll call it) development\n\"layers\". The current design of GIT is that the working repository and\nworking directory assume that all files belong together in the same\nproject. I would like to see GIT go 3D and support layers, so that\nfiles (and/or file content) can belong to multiple repositories (or\nconsidered unique projects), even though the working tree presents all\nfiles as if they were one.\n\nTo explain further...\n\nLets say, I am not the primary developer of a project, however I am a\n\"module\"/\"plugin\"/\"addon\" contributor to a project - ie: my primary\ninvolvement is to write additions to existing projects. (EG: I\nwrite/support a driver in the kernel (that is not included in the base\ntree), or I write an \"addon\" to an existing application, using that\nexisting applications \"module\" capability).\n\nAs part of me developing my \"module\" (or modules if I develop more\nthan one), I need the working tree to have the \"base\" and \"my bits\". I\nwant to manage both the changes I make to \"my bits\", and also record\nany changes that need to be made to the \"base\" (so that \"my module(s)\"\nwill work). Normally, the changes to the \"base\" would be submitted\nupstream (and hopefully accepted), while I would normally be\nresponsible for the packaging and change control of \"my bits\".\n\nIf the upstream chooses not to accept my contributions (ie: my changes\nnever appear in base), then whenever I package \"my bits\", GIT would\nalso include the base components as well.\n\nI know I can achieve some of this by using GIT branches (I've been\ndoing that so far), however, GIT branches has a few limitations that I\nam sure that GIT \"layers\" would overcome... Ultimately, I believe GIT\ncan handle my layers idea - and it should be possible to have multiple\nlayers (where multiple components could come from different GIT\nrepositories), however, they are all \"checked out\" into the one\nworking tree.\n\nThinking about this further, there would be two possible layer\nscenarios (I think GIT can handle both).\n* File autonomy (most cases)\nThis is where files (by filename) belong to different projects. EG: If\nmy working tree had files \"a, b & c\", \"1, 2 & 3\", and \"X Y & Z\". Files\n\"abc\" could be layer one (the base), files \"123\" could be layer two\n(dependant on base) and files XYZ could be layer three (which could be\ndependant on base OR dependant on layer two).\n\nWhenever modifications were done to any file, GIT would know which\nlayer owns the file and GIT processing is done as normal. Upstream\npulls from any layer should not normally generated any conflicts,\nunless there are filename clashes between layers (and in this\nsituation the layer hierarchy should be considered authoritative, with\nthe conflict needed to be resolved in a lower layer.)\n\n* Content autonomy\nThis is were some content in files belongs to \"my work\" (eg: Modifying\na Makefile to compile my work when the base is compiled). In this\nsituation, I may have two outcomes - I either want the changes to\nflagged for upstream (to hopefully be included), or I may want to keep\nthe changes with my work, because I know it upstream would never\naccept them (or it isnt appropriate).\n\nIn either cases, upstream pulls should be considered authoritative and\nany conflicts I would need to resolve as normal commit (either wanting\nthem to be resubmittable for upstream, or commiting them as part of my\nwork.)\n\nLike I mentioned, I can achieve some of this by the use of branches\nalready, however, where it comes complicated, is when:\n* I commit a change to the wrong branch (and thus upstream will never\nsee my enhancements),\n* I want to identify changes to one layer (that I went to send to\nupstream for review), without including the other layers (because it\nprobably isnt relevant)\n* I want to work on more than one layer (I need to be diligent about\npulling and merging)\n\nAn example of usage might be:\n* git clone ... (or git init) -layer \"A\"\n* git checkout -b mywork -layer \"A\"\n* git clone ... (or git init) -layer \"B\" -dependson \"A\"\n* git checkout -b mymodule -layer \"B\"\n* add/remove/edit files\n* git add file x -layer \"A\"\n* git add file y -layer \"B\"\n* git rm file z -layer \"A\"\n* git commit (as usual)\n* git tag \"V2.8\" -layer \"A\"\n* git tag \"mymodule V1.0\" -layer \"B\"\n\ngit diff -layer \"A\" mywork.. would show my changes that I would want\nsent upstream (without mymodule commits)\ngit archive -layer \"B\" would package up my module for distribution\n(without layer \"A\")\ngit archive -layer \"A\" would package up my version of layer A (without\nlayer \"B\")\n\nCould this be included as part of GITs functionality (or is it\npossible already) ?\n\n...deon\n"},{"id":"123665","messageId":"c07716ae0909230126w36b3309fqe9ae8ccec0db49c3@mail.gmail.com","threadId":"21030","inReplyTo":"5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2009-09-23T08:26:49Z","receivedAt":"2009-09-23T08:26:49Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Sep 23, 2009 at 8:17 AM, Deon George <deon.george@gmail.com> wrote:\n> Hi,\n>\n> I'm not sure if this is the right place, but I thought I'd post my\n> idea and maybe somebody will either redirect me to the right place, or\n> give me that \"that wont happen\".\n>\n> Im fairly new to GIT (wish I had discovered it long ago), and I really\n> like using it - great work guys/garls :)\n>\n> My idea is to enhance GIT to support (I'll call it) development\n> \"layers\". The current design of GIT is that the working repository and\n> working directory assume that all files belong together in the same\n> project. I would like to see GIT go 3D and support layers, so that\n> files (and/or file content) can belong to multiple repositories (or\n> considered unique projects), even though the working tree presents all\n> files as if they were one.\n\nPerhaps you could have a look at \"git replace\" that is now in the master branch.\nIt could be improved to provide different \"views\" of a single repository.\nI don't think that alone it would provide everything you want though.\n\nBest regards,\nChristian.\n"},{"id":"123667","messageId":"200909231106.03305.johan@herland.net","threadId":"21030","inReplyTo":"5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-09-23T09:06:03Z","receivedAt":"2009-09-23T09:06:03Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 23 September 2009, Deon George wrote:\n> Could this be included as part of GITs functionality (or is it\n> possible already) ?\n\nHave a look at git submodules ('git help submodule'), or the git-subtree \nscript that has been discussed on this list a couple of times [1].\n\n[1] http://alumnit.ca/~apenwarr/log/?m=200904#30 and \nhttp://github.com/apenwarr/git-subtree\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"123671","messageId":"5b5e291e0909230412r3ce143abgd990c36e27736bae@mail.gmail.com","threadId":"21030","inReplyTo":"200909231106.03305.johan@herland.net","subject":"Re: Feature Enhancement Idea.","fromName":"Deon George","fromEmail":"deon.george@gmail.com","sentAt":"2009-09-23T11:12:47Z","receivedAt":"2009-09-23T11:12:47Z","isPatch":false,"sender":{"key":"deon.george@gmail.com","avatar":null},"body":"2009/9/23 Johan Herland <johan@herland.net>:\n> Have a look at git submodules ('git help submodule'), or the git-subtree\n> script that has been discussed on this list a couple of times [1].\n\ngit submodule looks like it will do a little of what I want - I'll do\nsome more reading on it to see exactly how it works. Thanks for the\ntip.\n\nMy initial look at it seems to miss an important feature that my layer\nidea would provide. It looks like git submodule assumes that\neverything in a subdirectory belongs to a repository - with my layer\nidea, I would want any layer to share the same directory structure and\nfiles (or content) belonging to a distinct layer's repository.\n\nIE:\nthe base might provide\nplugins\nplugins/README\nmodules\nmodules/README\nlib/common.php\n\nand a layer might provide\nplugins/a.php\nmodules/a.php\nlib/a.php\n\nanother layer might provide\nplugins/b.php\nmodules/b.php\nlib/b.php\n\nIf I was a C developer, I'd have a go at creating it - but I'm just a\nphp developer :)\n...deon\n"},{"id":"123679","messageId":"8e04b5820909231117k401e7500h822a61cb41db5c0@mail.gmail.com","threadId":"21030","inReplyTo":"5b5e291e0909230412r3ce143abgd990c36e27736bae@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Ciprian Dorin, Craciun","fromEmail":"ciprian.craciun@gmail.com","sentAt":"2009-09-23T18:17:28Z","receivedAt":"2009-09-23T18:17:28Z","isPatch":false,"sender":{"key":"ciprian.craciun@gmail.com","avatar":"https://gravatar.com/avatar/9685eb13288a2c28bdde10acdcda9f15d495efad7b12bf49e3525eb7b8acf944?d=mp&s=160"},"body":"On Wed, Sep 23, 2009 at 2:12 PM, Deon George <deon.george@gmail.com> wrote:\n> 2009/9/23 Johan Herland <johan@herland.net>:\n>> Have a look at git submodules ('git help submodule'), or the git-subtree\n>> script that has been discussed on this list a couple of times [1].\n>\n> git submodule looks like it will do a little of what I want - I'll do\n> some more reading on it to see exactly how it works. Thanks for the\n> tip.\n>\n> My initial look at it seems to miss an important feature that my layer\n> idea would provide. It looks like git submodule assumes that\n> everything in a subdirectory belongs to a repository - with my layer\n> idea, I would want any layer to share the same directory structure and\n> files (or content) belonging to a distinct layer's repository.\n>\n> IE:\n> the base might provide\n> plugins\n> plugins/README\n> modules\n> modules/README\n> lib/common.php\n>\n> and a layer might provide\n> plugins/a.php\n> modules/a.php\n> lib/a.php\n>\n> another layer might provide\n> plugins/b.php\n> modules/b.php\n> lib/b.php\n>\n> If I was a C developer, I'd have a go at creating it - but I'm just a\n> php developer :)\n> ...deon\n\n\n    Practically you want something like unionfs [1] but for git. Right?\n\n    But probably you could settle for something like Hg Queues [2]. Is\nthere similar for Git?\n\n    Ciprian Craciun.\n\n    [1] http://en.wikipedia.org/wiki/UnionFS\n    [2] http://mercurial.selenic.com/wiki/MqExtension\n"},{"id":"123685","messageId":"7vab0lh1an.fsf@alter.siamese.dyndns.org","threadId":"21030","inReplyTo":"5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-23T20:08:16Z","receivedAt":"2009-09-23T20:08:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Deon George <deon.george@gmail.com> writes:\n\n> Like I mentioned, I can achieve some of this by the use of branches\n> already, however, where it comes complicated, is when:\n> * I commit a change to the wrong branch (and thus upstream will never\n> see my enhancements),\n> * I want to identify changes to one layer (that I went to send to\n> upstream for review), without including the other layers (because it\n> probably isnt relevant)\n> * I want to work on more than one layer (I need to be diligent about\n> pulling and merging)\n\nI think you are getting ahead of yourself by coming up with \"layers\" as a\nsolution, without really spelling out and then thinking through what\nproblem you are trying to solve.\n\nI think the primary scenario your itch comes from is (I am writing this\ndown to make sure I understand where you are trying to go):\n\n - you would want to build your changes on top of somebody else's code;\n\n - while doing so it is often more convenient if you do not have to think\n   about which pieces of changes should go to upstream, and which other\n   pieces of changes should stay local;\n\n - git allows you to do this with topic branch workflow, with selective\n   adding with \"add -p\", stashing and branch switching.\n\n - You can however misidentify which bits should go to upstream and commit\n   to a wrong branch.  You want to reduce the chance of this mistake.\n\nAm I following you Ok so far?\n\nNow, how does \"layers\" (I understand by this word you mean the concept of\n\"layering a worktree from one branch on top of layering a worktree from\nanother\") solve that problem?  If you come up with a nice way to identify,\nand have the tool help you identify, \"these bits belong to that layer\",\nwouldn't that approach also apply to existing topic branch workflow by\nhaving the same logic of that magic tool to help you say \"these bits\nshould go to that topic branch\"?\n\nWhen the granularity of the change is per-file (your \"autonomous\" case),\n\"git checkout\" to switch back to your topic would already solve half of\nthat issue.\n\nSuppose you have mainline (origin/master) and your customization topic\n(custom), and file F is something that does not and will never exist in\nthe mainline.  You use your master branch as your integration testing\nbranch.  With traditional topic branch workflow, you would\n\n    $ git checkout custom\n    ... work on F and other files, test the changes to your satisfaction\n    $ git commit -m 'I am satisfied on my custom work'\n    $ git checkout master\n    $ git rebase origin/master ;# keep up with the upstream\n    $ git cherry-pick ... ;# some commits in custom that should go to upstream\n    $ git merge custom ;# test merge to be thrown away!\n\n    ... now you are on the integrated result in 'master'.\n    ... test, notice breakages in F, and edit it to improve it\n    ... the changes to F belongs to 'custom', not for upstream!\n    $ git checkout custom ;# this will take the changes to F with you\n    $ git commit -m 'I should have done this to F instead' F\n\n    ... go back to do more work\n    $ git checkout master\n    ... loop forever ;-)\n\nand after you are satisfied, you would reset the merge from custom away\nand offer the master that is combination of what was in the origin/master\nplus the \"upstream worthy\" bits you cherry-picked ones from your custom\nbranch.\n\nWhen the granularity is sub-file, \"checkout -m custom\" or \"stash, checkout\ncustom, then unstash\" would help carrying the changes across branches.\nYou would need to identify which changes you would want to commit to\n\"custom\" and which changes you would want to give to upstream by making a\ncommit on \"master\" when you go back there again.  The middle part of the\nabove workflow will be slightly modified for a file G that is shared\nbetween origin/master and custom branches, perhaps something like:\n\n    ... now you are on the integrated result in 'master'.\n    ... test, notice breakages in G, and edit it to improve it\n    ... the changes to G belongs to 'custom', not for upstream!\n    $ git checkout -m custom ;# this will take the changes to G with you\n    $ git add -p G ;# pick changes that only belong to custom\n    $ git commit -m 'I should have done this to G instead'\n\nIf the \"layers\" logic somehow can help you automate the process of sifting\nyour changes into these two categories (perhaps it may scan the file and\nknows which function belongs to \"custom\" alone, I dunno and care about the\ndetails at this level of discussion), wouldn't that same logic help you\nthe same way?\n\nPast attempts that made into the toolchest are \"add -p\" (and \"stash -p\"\nthat uses the same mechanism) which is interactive and not automated.\nMaybe you can build some logic to automate it further (e.g. \"changes to\nthis function should automatically be excluded from \"git add\" while on\n'master', but should automatically be included in \"git add\" while on\n'custom'), and it may turn out be a good addition to the toolchest.\n\nIt also may make a good addition to the toolchest to have a tool to\nfurther simplify the branch switching explicitly initiated by the end user\nin the above illustrations.  In some cases, such as the \"autonomous\" case\nabove, you do not _have_ to go back to custom branch from the work-flow\npoint of view (you would be committing a totally untested work to custom\nbranch, but as long as you will revisit and retest the changes in its\ncontext, it is not a major crime at all).  It would be useful if you can\nsay, while still on 'master' branch, \"I just made this fix to file F that\nbelongs to 'custom'; commit that change alone to 'custom' branch\".\nWritten as a shell script, roughly, it would look something like:\n\n    #!/bin/sh\n    target_branch=\"$1\"\n    base=$(git rev-parse --verify \"$target_branch\") || exit\n    shift ;# all others are paths\n    GIT_INDEX_FILE=.git/temp\n    export GIT_INDEX_FILE\n    git read-tree -m \"$1\"\n    git add \"$@\"\n    c=$(echo \"side commit\" | git commit-tree $(git write-tree) -p \"$base\")\n    git update-ref \"refs/heads/$target_branch\" \"$c\"\n\nBut I do not see how the concept of \"layering a worktree from one branch\non top of layering a worktree from another\", which is the implication I\nget from the word \"git layers\", helps any of that.  It seems an orthogonal\nconcept that we can do without to solve the problem you are describing.\n"},{"id":"123704","messageId":"200909240119.52706.johan@herland.net","threadId":"21030","inReplyTo":"8e04b5820909231117k401e7500h822a61cb41db5c0@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-09-23T23:19:52Z","receivedAt":"2009-09-23T23:19:52Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 23 September 2009, Ciprian Dorin, Craciun wrote:\n>     Practically you want something like unionfs [1] but for git. Right?\n> \n>     But probably you could settle for something like Hg Queues [2]. Is\n> there similar for Git?\n\nTopGit, StGit, Guilt?\n\nNot sure they (or Hg Queues) solve Deon's problem though...\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"123709","messageId":"5b5e291e0909232252q3231afe4t95d01339ee531964@mail.gmail.com","threadId":"21030","inReplyTo":"7vab0lh1an.fsf@alter.siamese.dyndns.org","subject":"Re: Feature Enhancement Idea.","fromName":"Deon George","fromEmail":"deon.george@gmail.com","sentAt":"2009-09-24T05:52:05Z","receivedAt":"2009-09-24T05:52:05Z","isPatch":false,"sender":{"key":"deon.george@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n\n> I think the primary scenario your itch comes from is (I am writing this\n> down to make sure I understand where you are trying to go):\n>\n>  - you would want to build your changes on top of somebody else's code;\n\nYes - more correctly, I want to enhance an application, where I am (or\ndifferent person - it doesnt matter) is responsible for that code.\nThus I want to source code manage my enhancement, and (for whatever\nreason), the other components of the application dont want my part in\ntheir \"base\".\n\n>  - while doing so it is often more convenient if you do not have to think\n>    about which pieces of changes should go to upstream, and which other\n>    pieces of changes should stay local;\n\nNot strictly true, but yes - I am aware that my modules might be\ncompletely autonomous to the base code (thus I source control manage\neverything that my module requires), or I discover bugs in the base\ncode, that I believe upstream should have. There may also be a case,\nwhere I want to modify some code in the base, but I know that it\nshouldnt never be included in the base code (and thus I would need my\ncommit to be stored in my SCM, not the base's SCM) - eg: Modifying a\nMakefile...\n\nSo while I would commit to a layer, I should make a conscious decision\nof where the commit should go (I own the commit work, or I want to\nsend the commit upstream as a contribution enhancement/fix) - because\nthe default assumption may be wrong.\n\n>\n>  - git allows you to do this with topic branch workflow, with selective\n>    adding with \"add -p\", stashing and branch switching.\n\nI dont know about topic branches \"git add -p\"? (I havent got that\nadvanced yet, looks like I need to do some more research on the\nfeatures of GIT :)\n\n> Am I following you Ok so far?\n\nYes, but one more important criteria - my working tree is made up of\nfiles (or content) managed in more than once source control management\nrepository - I use an SCM to manage and track changes, and I use\nmultiple repository because any one owner of one repository may not\nwant the code from another as part of their \"base\". IE: It could be I\nwrite a custom driver for a widget device, that Linus doesnt want that\ncode in the base kernel (for whatever reason) and I maintain that part\nof the code, or (in my case), I want to maintain (and encourage others\nto contribute) to a module (or set of modules) for an existing web\napplication framework.\n\nAdditionally, each layer should be able to switch between its own\nbranches (ie: My driver 1.0 works well with kernel \"N\", now Linus\npublishes \"N+1\", I want to switch that (base) layer to \"N+1\" and\ntest/fix my module to work with that release - and then commit/tag it\nas such - ie: my driver (now 1.1) works with \"N+1\"). Further a bug is\nnow found in my 1.0 driver, so I want to switch back the kernel layer\nto \"N\", and my driver layer to 1.0, make the fix, and release\n1.0.1)... Kinda get the idea Im working towards...?\n\nAdditionally, it should not necessarily be \"one base\" and \"my layer\",\nit may be multiple layers (and hence multiple repositories), but all\nlayers make up an application with multiple features, each\nindividually source control managed. Each layer would have a\ndependency to another (otherwise they could be developed in their own\nrepository entirely - and the dependency may be needed to be know for\nmerge conflict resolution (where do the conflicts need to be\ncommited), when pulling from the upstream owners of that layer)\n\nThus, when I package up my module - it shouldnt include the base\n(since the base may already be installed), and the base developers\nwant to keep their application more like a framework - so they are\nresponsible for the core workings of the code, and the module\ndevelopers are responsible for their components.\n\nTo achieve what I want today, I think I would need to have:\n\nmaster\nmaster-mycontribs (branched from master, and merged from master)\nmymodule (branched from master-mycontribs and merge from there - this\nis pushed to my SCM repository)\nmymodule-working (where I test and commit - and merge back to my module)\n\n(this comes stuck, when I want to switch master to a previous version...)\n\nAnd thus, the diff between \"master\" and \"master-mycontribs\", are my\ncontributions to go upstream. The diff between \"master\" and \"mymodule\"\nis what I would package to make my module as an enhancement to anyone\nalready using \"master\" (at release \"N\").\n\nIf upstream accepts my enhancements, then \"master\" =\n\"master-mycontribs\" (and master is now release \"N+1\"), and the next\nrelease of my module (1.2) would still be the diff between\n\"master-mycontribs\" and \"mymodule\" (but would be excluding my code\nthat I added to master-mycontribs (since master now equals that),\nbecause the end user who is already running N+1 has those\nenhancements.\n\nI'll research git \"topics\" and see if that does what I am dreaming of :)\n\n...deon\n"},{"id":"123711","messageId":"m3bpl0c2cf.fsf@localhost.localdomain","threadId":"21030","inReplyTo":"5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-09-24T05:56:52Z","receivedAt":"2009-09-24T05:56:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Deon George <deon.george@gmail.com> writes:\n\n> I'm not sure if this is the right place, but I thought I'd post my\n> idea and maybe somebody will either redirect me to the right place, or\n> give me that \"that won't happen\".\n> \n> Im fairly new to GIT (wish I had discovered it long ago), and I really\n> like using it - great work guys/garls :)\n> \n> My idea is to enhance GIT to support (I'll call it) development\n> \"layers\". The current design of GIT is that the working repository and\n> working directory assume that all files belong together in the same\n> project. I would like to see GIT go 3D and support layers, so that\n> files (and/or file content) can belong to multiple repositories (or\n> considered unique projects), even though the working tree presents all\n> files as if they were one.\n\n[cut very long description]\n\n> Could this be included as part of GITs functionality (or is it\n> possible already) ?\n\nFirst, I assume there that you do not allow for the same file to\nbelong to different repositories.\n\nSecond, if all parts that you want to belong to other repository are\nin separate subdirectories, and all files in those subdirectories\nbelong to this other repository, you can try either submodules \n(git-submodule), or subtree (subtree merge, or third-party git-subtree\nhelper).  Note also that this assume that you want to have 'master'\nrepository which indirectly or directly has al the files.\n\n\nThird, if the above isn't what you want, then you can manually\nintermingle working directories of different git repositories\n(probably requiring decouplig of bare git repository (git-dir)\nfrom working area (work-tree)).  Git repository know what files\nit tracks, so you would only need to take care to ignore files\nthat belong to other repositories.\n\nIf it is to manual for you, and to error prone, you are welcome\nto come up with set of scripts implementing \"layers\" feature you\nwant.  That is how initial version of submodule feature was done...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"123726","messageId":"5b5e291e0909240225q49a202abk7cf1a0c8f715ad5f@mail.gmail.com","threadId":"21030","inReplyTo":"m3bpl0c2cf.fsf@localhost.localdomain","subject":"Re: Feature Enhancement Idea.","fromName":"Deon George","fromEmail":"deon.george@gmail.com","sentAt":"2009-09-24T09:25:34Z","receivedAt":"2009-09-24T09:25:34Z","isPatch":false,"sender":{"key":"deon.george@gmail.com","avatar":null},"body":"Jakub Narebski wrote:\n\n> First, I assume there that you do not allow for the same file to\n> belong to different repositories.\n\nWell, no, I cant see why a file cannot belong to both repositories.\nI'm sure it would be easier if a file did belong to a unique\nrepository, but given that GIT operates at a content layer (from what\nI've read anyway), I cant see why it couldnt belong to more than one.\n\n> you can try either submodules\n> (git-submodule), or subtree (subtree merge, or third-party git-subtree\n> helper).\n\nI had a quick look at submodule - I dont think it helps me anyway,\nsince I want the flexibility for files to belong to many\nsub-directories - not all under 1 sub directory hierarchy.\n\n> Third, if the above isn't what you want, then you can manually\n> intermingle working directories of different git repositories\n> (probably requiring decouplig of bare git repository (git-dir)\n> from working area (work-tree)).\n\nAhh, now this sounds like it might be what I want to do - I think I'll\nexplore this. I can see that it would provide file level autonomy\nonly, but as a starting point I think it will help heaps...\n\nI'll work on it as time permits and come up with some scripts to\nprovide what I am after (need to learn more on the workings of GIT\nfirst - everyday I learn a new feature :)\n\nThanks for your idea...\n\n...deon\n"},{"id":"123740","messageId":"loom.20090924T184504-686@post.gmane.org","threadId":"21030","inReplyTo":"5b5e291e0909240225q49a202abk7cf1a0c8f715ad5f@mail.gmail.com","subject":"Re: Feature Enhancement Idea.","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-09-24T16:45:26Z","receivedAt":"2009-09-24T16:45:26Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Deon George <deon.george <at> gmail.com> writes:\n\n> > Third, if the above isn't what you want, then you can manually\n> > intermingle working directories of different git repositories\n> > (probably requiring decouplig of bare git repository (git-dir)\n> > from working area (work-tree)).\n> \n> Ahh, now this sounds like it might be what I want to do - I think I'll\n> explore this. I can see that it would provide file level autonomy\n> only, but as a starting point I think it will help heaps...\n\nProof of concept:\n\nexport GIT_WORK_TREE=.\n\ngit --git-dir=.git1 init\ngit --git-dir=.git1 add view1-file\ngit --git-dir=.git1 commit -m\"view1 initial\"\n\ngit --git-dir=.git2 init\ngit --git-dir=.git2 add view1-file\ngit --git-dir=.git2 commit -m\"view2 initial\"\n\ngit --git-dir=.git1 log\ngit --git-dir=.git2 log\n"}]}