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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
