Junio C Hamano wrote: > I think the primary scenario your itch comes from is (I am writing this > down to make sure I understand where you are trying to go): > > - you would want to build your changes on top of somebody else's code; Yes - more correctly, I want to enhance an application, where I am (or different person - it doesnt matter) is responsible for that code. Thus I want to source code manage my enhancement, and (for whatever reason), the other components of the application dont want my part in their "base". > - while doing so it is often more convenient if you do not have to think > about which pieces of changes should go to upstream, and which other > pieces of changes should stay local; Not strictly true, but yes - I am aware that my modules might be completely autonomous to the base code (thus I source control manage everything that my module requires), or I discover bugs in the base code, that I believe upstream should have. There may also be a case, where I want to modify some code in the base, but I know that it shouldnt never be included in the base code (and thus I would need my commit to be stored in my SCM, not the base's SCM) - eg: Modifying a Makefile... So while I would commit to a layer, I should make a conscious decision of where the commit should go (I own the commit work, or I want to send the commit upstream as a contribution enhancement/fix) - because the default assumption may be wrong. > > - git allows you to do this with topic branch workflow, with selective > adding with "add -p", stashing and branch switching. I dont know about topic branches "git add -p"? (I havent got that advanced yet, looks like I need to do some more research on the features of GIT :) > Am I following you Ok so far? Yes, but one more important criteria - my working tree is made up of files (or content) managed in more than once source control management repository - I use an SCM to manage and track changes, and I use multiple repository because any one owner of one repository may not want the code from another as part of their "base". IE: It could be I write a custom driver for a widget device, that Linus doesnt want that code in the base kernel (for whatever reason) and I maintain that part of the code, or (in my case), I want to maintain (and encourage others to contribute) to a module (or set of modules) for an existing web application framework. Additionally, each layer should be able to switch between its own branches (ie: My driver 1.0 works well with kernel "N", now Linus publishes "N+1", I want to switch that (base) layer to "N+1" and test/fix my module to work with that release - and then commit/tag it as such - ie: my driver (now 1.1) works with "N+1"). Further a bug is now found in my 1.0 driver, so I want to switch back the kernel layer to "N", and my driver layer to 1.0, make the fix, and release 1.0.1)... Kinda get the idea Im working towards...? Additionally, it should not necessarily be "one base" and "my layer", it may be multiple layers (and hence multiple repositories), but all layers make up an application with multiple features, each individually source control managed. Each layer would have a dependency to another (otherwise they could be developed in their own repository entirely - and the dependency may be needed to be know for merge conflict resolution (where do the conflicts need to be commited), when pulling from the upstream owners of that layer) Thus, when I package up my module - it shouldnt include the base (since the base may already be installed), and the base developers want to keep their application more like a framework - so they are responsible for the core workings of the code, and the module developers are responsible for their components. To achieve what I want today, I think I would need to have: master master-mycontribs (branched from master, and merged from master) mymodule (branched from master-mycontribs and merge from there - this is pushed to my SCM repository) mymodule-working (where I test and commit - and merge back to my module) (this comes stuck, when I want to switch master to a previous version...) And thus, the diff between "master" and "master-mycontribs", are my contributions to go upstream. The diff between "master" and "mymodule" is what I would package to make my module as an enhancement to anyone already using "master" (at release "N"). If upstream accepts my enhancements, then "master" = "master-mycontribs" (and master is now release "N+1"), and the next release of my module (1.2) would still be the diff between "master-mycontribs" and "mymodule" (but would be excluding my code that I added to master-mycontribs (since master now equals that), because the end user who is already running N+1 has those enhancements. I'll research git "topics" and see if that does what I am dreaming of :) ...deon -- 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