Re: [RFC] Patches exchange is bad?
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: 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
Re: [RFC] Patches exchange is bad?
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 you only push those patches that need to be merged). Doing a 'stg pull' would retrieve the latest changes from the mainline kernel (including the changes made by your patches which were merged upstream). If I uderstand correctly you never commit patches from StGIT stack directly in your base git repository, in this example git HEAD, but you always round trip to MAIN. One usually doesn't maintain MAIN. That's an example for the Linux kernel development where you can't control what get merged into MAIN. There is a bit of confusion here since you said in a previous e-mail that more people can commit to the stable branch. In this case, you would need a separate repository for stable with a maintainer pulling changes from others. Then you don't have two git repository: HEAD and MAIN Infact there is only one git repository, MAIN, cloned on your box and called HEAD and with a StGIT stack added on top. The StGIT usage idea is that you only know what patches you have on top of a main repository. Since you expect your patches to be merged upstream or just updated every time the main repository changes, it might not make sense to commit the patches onto the base. If you want to keep a stable branch (and only you comitting to it), I would recommend having separate branches for stable and development in the same tree (and avoid having separate trees) rather than directly modifying the base. StGIT doesn't support this directly (didn't think anyone would ask) but you can do the following steps: 1. Use 'stg clone remote repository' to create the initial clone. The 'master' branch will be used for development. You can use 'git-init-db' and 'stg init' if you don't follow a remote repository 2. 'git checkout -b stable' will create the stable branch. This will initially be the same as the master one since there are not patches applied to the master stack 3. switch back to the devel branch with 'git checkout master' and do the normal StGIT development (create patches, commit them etc.). If you are tracking a remote respository, you could pull the latest changes with 'stg pull' 4. Once you have a set of patches applied and your stack is stable (some patches can be unapplied, they don't affect the head of the development branch), you can switch to the stable branch with 'stg checkout stable' and merge the changes in master with 'git-resolve-script'. I think it might make more sense to simply do a 'cp .git/refs/heads/master .git/refs/heads/stable' instead of the previous paragraph since the stable branch doesn't have additional data from what's in master. The remote repository tracking is done via master. 5. You can advance the base of the stack to what's in stable with an 'stg pull stable' but it's not clear for me whether this makes any sense since you lose the StGIT patches already added to stable and you will might later get conflicts when pulling the changes from the remote repository you are tracking. For the 2, 3 and 4 steps above I will add a 'snapshot' command to StGIT but I'm not sure why one would want step 5 since this would mean that the devel branch needs to track both the remote repository and the stable branch. Some questions: do you track a remote repository? Do you need a stable repository or branch where more people can update? If you track the remote repository, do you want the latest remote changes merged into the stable branch directly (i.e. is the stable branch tracking the remote repository)? I need a bit more clarification about your work flow. -- Catalin - 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
Re: [RFC] Patches exchange is bad?
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 of the scripting) would be more effective when you're not doing anything with the intermediate files, since it saves doing a bunch of formatting and parsing. It would be surely better, but I need to import also the original subject and description. I can use git-diff-tree --pretty -p for the patch creation, but this format is not compatible with git-apply* scripts, and the git command git-apply does not import subject + description info. Of course I can feed proper subject and description to git-commit but I would like to find something less intrusive as possible, ie. one command for patch export, one command for patch import. Thanks 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
Re: [RFC] Patches exchange is bad?
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 with patches, but also because patches that are in the 'stack' are actually really malleable. You can edit and reedit the patch w its commit msg and all, commit it to the stack, and reedit it again later. It only becomes immutable when you commit to the underlying git repo. cheers, martin - 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
Re: [RFC] Patches exchange is bad?
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 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.
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.
--
Catalin
-
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
Re: [RFC] Patches exchange is bad?
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
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.
Sorry if the answer is silly, but I still don't know well StGIT .
What you describe it's an asymmetrical or one way scenario, new code
goes always from HEAD to MAIN. But how is the workflow if:
1) There is more then one contributor feeding MAIN and you need to update
the StGIT patch stack from MAIN.
2) You made something terribly wrong with HEAD (I don't know what can be
'terribly wrong') and you need to recreate a clean base from MAIN.
In this cases, if I understand correctly, you need to clone a new StGIT archive
from
MAIN and push the interesting stuff from old/broken HEAD.
Or you can always merge back pulling from MAIN as in case of two pure git
archives?
Thanks
Marco
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
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
Re: [RFC] Patches exchange is bad?
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 __ 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
Re: [RFC] Patches exchange is bad?
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 implemented on top if GIT instead of a series of GNU diff files. What you describe it's an asymmetrical or one way scenario, new code goes always from HEAD to MAIN. But how is the workflow if: It is asymmetrical since HEAD uses StGIT and MAIN uses plain GIT but it is a two way data flow: 'git pull HEAD' in MAIN and 'stg pull MAIN' in HEAD. 1) There is more then one contributor feeding MAIN and you need to update the StGIT patch stack from MAIN. The base of the StGIT stack in the HEAD repository (branch) should always be the head of the MAIN repository. You update it via the 'stg pull' command, which takes care of updating the patches so that they are seen as individual commits on top of the base. 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 you only push those patches that need to be merged). Doing a 'stg pull' would retrieve the latest changes from the mainline kernel (including the changes made by your patches which were merged upstream). 2) You made something terribly wrong with HEAD (I don't know what can be 'terribly wrong') and you need to recreate a clean base from MAIN. In this cases, if I understand correctly, you need to clone a new StGIT archive from MAIN and push the interesting stuff from old/broken HEAD. This is not clear for me. What do you mean by 'terribly wrong'? Broken HEAD because of a bug in StGIT or GIT? Quite unlikely but in this case the repository would be corrupt. I would recommend periodically doing a 'stg export' to keep the series of patches in GNU diff files. If you refer to a patch which breaks the code, you can simply pop it from the stack and even delete it with 'stg delete'. Popping it removes the changes it makes to HEAD and the corresponding commit won't be seen with 'git log'. You don't need to clone a new repository since StGIT allows you to choose which of your patches (commits) are included in HEAD (via 'stg push' and visible with 'stg applied'). Or you can always merge back pulling from MAIN as in case of two pure git archives? The base of the StGIT stack is identical to MAIN. Doing a 'stg pop -a' makes the HEAD and MAIN identical. Please let me know if this needs further clarification. -- Catalin - 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
Re: [RFC] Patches exchange is bad?
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 http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
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 - 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
Re: [RFC] Patches exchange is bad?
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 stuff. cheers, martin - 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
Re: [RFC] Patches exchange is bad?
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.' while, after the round-trip git-format-patch + git applymbox I have ' [PATCH] Alternate object pool mechanism updates.' The extra '[PATCH]' in the subject was introduced by git-format-patch --mbox. Perpahs I have made something wrong. Marco Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - 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
