Re: [RFC] Patches exchange is bad?

2005-08-18 Thread Catalin Marinas
Johannes Schindelin [EMAIL PROTECTED] wrote: maybe it is time for a quick run through the typical jobs you do with StGIT, much like what Jeff sent the other day? I hope I will find some time this weekend and write some tutorials on an StGIT wiki. -- Catalin - To unsubscribe from this list:

Re: [RFC] Patches exchange is bad?

2005-08-18 Thread Catalin Marinas
Marco Costalba [EMAIL PROTECTED] wrote: Catalin Marinas wrote: That's how you would normally do development on Linux using StGIT - clone the mainline kernel, create patches in your StGIT tree and submit them either via e-mail or ask the gatekeeper to pull directly from your tree (assuming that

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Marco Costalba
Daniel Barkalow wrote: 2) Practical: The round trip git-format-patch + git-applymbox is the logical and natural way to reach this goal or, also in this case, I intend to stretch some tools, designed for one thing, for something else? I'd guess that git-diff-tree + git-apply (without the rest

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Martin Langhoff
On 8/17/05, Marco Costalba [EMAIL PROTECTED] wrote: Of course I can feed proper subject and description to git-commit but I would like to find something less intrusive I don't know if it helps, but I think that StGIT is what you are looking for, not only because you have more tools to deal

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Catalin Marinas
Marco Costalba [EMAIL PROTECTED] 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

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Marco Costalba
Catalin Marinas wrote: 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

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Marco Costalba
Marco Costalba wrote: This way I found StGIT useful for maintainers as well, not only for contributors. Sorry if the answer is silly, but I still don't know well StGIT . 'question' not 'answer' I don't now if the question is silly, but the typo it is for sure! Sorry Marco

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Catalin Marinas
On Wed, 2005-08-17 at 10:35 -0700, Marco Costalba wrote: Sorry if the answer is silly, but I still don't know well StGIT . It's probably because there is no document really explaining the concepts. The Quilt documentation would be a good starting point since StGIT uses the same ideas but

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Johannes Schindelin
Hi Catalin, maybe it is time for a quick run through the typical jobs you do with StGIT, much like what Jeff sent the other day? Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [RFC] Patches exchange is bad?

2005-08-16 Thread Johannes Schindelin
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,

Re: [RFC] Patches exchange is bad?

2005-08-16 Thread Martin Langhoff
On 8/17/05, Marco Costalba [EMAIL PROTECTED] 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

Re: [RFC] Patches exchange is bad?

2005-08-16 Thread Marco Costalba
Junio C Hamano wrote: 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. As example, in the rev d5a63b99835017d2638e55a7e34a35a3c1e80f1f from git the original subject is: ' Alternate object pool mechanism updates.'