On 11/19/07, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > "Jon Smirl" <jonsmirl@xxxxxxxxx> wrote: > > On 11/18/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> "Jon Smirl" <jonsmirl@xxxxxxxxx> writes: > >> > >> > What's causing this? I'm using stgit on the master branch. > [...] > >> pushed "A" to the remote's 'master', then built this history: > >> > >> o---o---A > >> / > >> ---o---o---o---o---A' > >> > >> by rewinding and rebuilding, and the tip of the branch now > >> points at A', which you tried to push to the remote. > > > > stgit must be doing this when I rebase. It pops all of it's patches, > > moves to head of linus/master and then rebases them. > [...] > > What is the right way to share repositories using stgit? I have a set > > of patches which I am working on for kernel inclusion. I have them > > applied as a stgit stack on top of linus/master. I need to share this > > patch stack with other developers. These developers may want to change > > one of my patches. Right now they are emailing me deltas and I apply > > them to the appropriate stgit patch. I have seventeen patches in my > > stack currently. > > StGIT is meant for keeping a clean history but with the big > disadvantage that this history is volatile. > > A solution is for the other developers to use StGIT or just git-rebase > so that they always have the same base (volatile) history and keep > their patches on top of yours. > > A 2nd approach is to use topic branches rather than StGIT patches but > you might lose some flexibility. > > Yet another approach (which I used) is to keep a public branch (can be > maintained by StGIT) where the history doesn't change and a devel > volatile branch. When I modify some patches and they are ready for > publishing, switch to the public branch and cherry-pick them (stg > pick) from the devel branch. Because this is done with a three-way > merge in StGIT, you will only get the new changes rather than the full > patch. You need to change the patch message (as it is that of the > original patch) to describe the specific changes and run 'stg refresh > && stg commit' to store it into the immutable history (well, there is > an 'uncommit' command as well if something goes wrong). Is a StGit where we can transparently share patches under version control in the works? Something like this: clone repo with stgit normal stg commands work with no setup change a patch stg push the repo I stg pull and the patch is updated. I also get rebased forward if the base repo has been updated -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
