[RFC] Patches exchange is bad?

Hi,

I would like to ask the list about something I'am thinking about, and I'am not sure it's a good idea.

Suppose a possible scenario involves using a couple of git archives, one for releases and stable code, say MAIN, and one for experimental stuff or new development, say HEAD.

Suppose there is stuff in HEAD you don't want merged in MAIN, more, you need to update MAIN with only a subset of patches in HEAD, peraphs in different order. Or simply, you are not interested to see the history of the HEAD tree when looking MAIN. All this points could keep you from merging.

I have mocked up a very simple and very stupid 'drag and drop' function. Basically you drag some selected revs in another instance of qgit, open on a different archive.

What happpens in the background is that git-format-patch-script is feeded with the selected revs and a bunch of temporary patch files are created, then git-applymbox (re)creates the corresponding commits in the destination archive.

It is just a very thin layer above the two git scripts, the only extra work is the cleaning up of some info that git-format-patch-script automatically adds, so that the new commits look like the originals (i.e. same header and description).

I've built-up this thing mainly because I found it useful for me, but I have some concerns that this is the correct way to go, the way git it's meant to be used.

If there is some interest for this I can push something on SF, after a due polishing, but if it is deeply broken I prefer discard and eventually switch to a more consistent workflow.

What do you think?

	Marco

__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com