Re: Feature Enhancement Idea.

[Deon George <deon.george@gmail.com>]

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