[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:

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

Ciao, Dscho

Marco Costalba <mcostalba@yahoo.it> writes:

All good. The existing tools are designed to work well in the following workflow:

    $ git format-patch --mbox master..pu
    $ cat 000[234]-*.txt >to-apply
    $ git checkout master
    $ git applymbox to-apply
    $ mv .git/refs/heads/pu .git/refs/heads/old-pu
    $ git checkout -b pu master
    $ git applymbox 0001-*.txt

to advance "master" with selected commits, possibly reordered, from the "pu" branch, and rebase the "pu" branch using the remaining commits.

I would like to know a bit about "git format-patch" adding extra info that you needed to get rid of. It shouldn't be necessary.

On 8/17/05, Marco Costalba <mcostalba@yahoo.it> wrote:

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

Marco Costalba <mcostalba@yahoo.it> wrote:

As others already recommended StGIT, I will just add a simple usage scenario (I do this with my StGIT repository).

The MAIN/stable repository (or branch) is only managed with GIT, not StGIT. The HEAD one is managed with StGIT (only, you can use 'stg clone'). You can create patches, modify them etc. (I updated the README in the latest snapshot and it contains some kind of tutorial).

Once you want a subset of these patches merged into MAIN, just pop everything from the stack and only push those you want merged, in the order you want (if there are some dependencies, the push will fail and you can correct them or the order). When you are happy with the patches pushed on the stack, just do a 'git pull <HEAD>' in the MAIN repository. After this, doing a 'stg pull <MAIN>' in the HEAD one will mark the patches already integrated into MAIN as empty and you can safely remove them ('stg clean' does this automatically).

This way I found StGIT useful for maintainers as well, not only for contributors.