{"thread":{"id":"1568","subject":"Re: [RFC] Patches exchange is bad?","startedAt":"2005-08-18T10:00:23Z","lastAt":"2005-08-18T11:16:59Z","messageCount":2,"participants":["Marco Costalba","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7494","messageId":"20050818100023.80893.qmail@web26310.mail.ukl.yahoo.com","threadId":"1568","inReplyTo":null,"subject":"Re: [RFC] Patches exchange is bad?","fromName":"Marco Costalba","fromEmail":"mcostalba@yahoo.it","sentAt":"2005-08-18T10:00:23Z","receivedAt":"2005-08-18T10:00:23Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Catalin Marinas wrote:\n\n>\n>The base of the StGIT stack in the HEAD repository (branch) should\n>always be the head of the MAIN repository. \n\nThat's the point I missed, now it's more clear.\n\n>\n>That's how you would normally do development on Linux using StGIT -\n>clone the mainline kernel, create patches in your StGIT tree and submit\n>them either via e-mail or ask the gatekeeper to pull directly from your\n>tree (assuming that you only push those patches that need to be merged).\n>Doing a 'stg pull' would retrieve the latest changes from the mainline\n>kernel (including the changes made by your patches which were merged\n>upstream).\n>\n\nIf I uderstand correctly you never commit patches from StGIT stack directly\nin your base git repository, in this example git HEAD, but you always round \ntrip to MAIN. \n\nThen you don't have two git repository: HEAD and MAIN\n\nInfact there is only one git repository, MAIN, cloned on your box and called HEAD and \nwith a StGIT stack added on top.\n\n>\n>Please let me know if this needs further clarification.\n>\n\nI think so. \nPlease, reading my notes above tell me if I thinking right ;-)\n\nMarco\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam?  Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"7499","messageId":"tnxbr3v336c.fsf@arm.com","threadId":"1568","inReplyTo":"20050818100023.80893.qmail@web26310.mail.ukl.yahoo.com","subject":"Re: [RFC] Patches exchange is bad?","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-18T11:16:59Z","receivedAt":"2005-08-18T11:16:59Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Marco Costalba <mcostalba@yahoo.it> wrote:\n> Catalin Marinas wrote:\n>>That's how you would normally do development on Linux using StGIT -\n>>clone the mainline kernel, create patches in your StGIT tree and submit\n>>them either via e-mail or ask the gatekeeper to pull directly from your\n>>tree (assuming that you only push those patches that need to be merged).\n>>Doing a 'stg pull' would retrieve the latest changes from the mainline\n>>kernel (including the changes made by your patches which were merged\n>>upstream).\n>\n> If I uderstand correctly you never commit patches from StGIT stack directly\n> in your base git repository, in this example git HEAD, but you always round \n> trip to MAIN.\n\nOne usually doesn't maintain MAIN. That's an example for the Linux\nkernel development where you can't control what get merged into MAIN.\n\nThere is a bit of confusion here since you said in a previous e-mail\nthat more people can commit to the stable branch. In this case, you\nwould need a separate repository for stable with a maintainer pulling\nchanges from others.\n\n> Then you don't have two git repository: HEAD and MAIN\n>\n> Infact there is only one git repository, MAIN, cloned on your box\n> and called HEAD and with a StGIT stack added on top.\n\nThe StGIT usage idea is that you only know what patches you have on\ntop of a main repository. Since you expect your patches to be merged\nupstream or just updated every time the main repository changes, it\nmight not make sense to commit the patches onto the base.\n\nIf you want to keep a stable branch (and only you comitting to it), I\nwould recommend having separate branches for stable and development in\nthe same tree (and avoid having separate trees) rather than directly\nmodifying the base. StGIT doesn't support this directly (didn't think\nanyone would ask) but you can do the following steps:\n\n1. Use 'stg clone <remote repository>' to create the initial\n   clone. The 'master' branch will be used for development. You can\n   use 'git-init-db' and 'stg init' if you don't follow a remote\n   repository\n\n2. 'git checkout -b stable' will create the stable branch. This will\n   initially be the same as the master one since there are not patches\n   applied to the master stack\n\n3. switch back to the devel branch with 'git checkout master' and do\n   the normal StGIT development (create patches, commit them etc.). If\n   you are tracking a remote respository, you could pull the latest\n   changes with 'stg pull'\n\n4. Once you have a set of patches applied and your stack is stable\n   (some patches can be unapplied, they don't affect the head of the\n   development branch), you can switch to the stable branch with 'stg\n   checkout stable' and merge the changes in master with\n   'git-resolve-script'.\n\n   I think it might make more sense to simply do a 'cp\n   .git/refs/heads/master .git/refs/heads/stable' instead of the\n   previous paragraph since the stable branch doesn't have additional\n   data from what's in master. The remote repository tracking is done\n   via master.\n\n5. You can advance the base of the stack to what's in stable with an\n   'stg pull stable' but it's not clear for me whether this makes any\n   sense since you lose the StGIT patches already added to stable and\n   you will might later get conflicts when pulling the changes from\n   the remote repository you are tracking.\n\nFor the 2, 3 and 4 steps above I will add a 'snapshot' command to\nStGIT but I'm not sure why one would want step 5 since this would mean\nthat the devel branch needs to track both the remote repository and\nthe stable branch.\n\nSome questions: do you track a remote repository? Do you need a stable\nrepository or branch where more people can update? If you track the\nremote repository, do you want the latest remote changes merged into\nthe stable branch directly (i.e. is the stable branch tracking the\nremote repository)?\n\nI need a bit more clarification about your work flow.\n\n-- \nCatalin\n"}]}