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
