[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 

Hi,

On Tue, 16 Aug 2005, Marco Costalba wrote:

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.

This looks like a good description of cherry picking. See StGIT (and to a 
certain extent, git-cherry) for that.

Ciao,
Dscho

On 8/17/05, Marco Costalba [off-list ref] wrote:

What do you think?

From what I understand, you'll want the StGIT infrastructure. If you

use git/cogito, there is an underlying  assumption that you'll want
all the patches merged across, and a simple cg-update will bring in
all the pending stuff.

cheers,


martin