From: Catalin Marinas Date: Tue, 16 Jan 2007 22:42:17 GMT Subject: Re: Rebasing stgit stacks Message-ID: In-Reply-To: <20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net> On 15/01/07, Yann Dirson wrote: > On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote: > > >I have started work on implementing "stg pull --to ", but I'm > > >facing some issues. > > > > I think the combination of 'pull' and '--to' is confusing (at least to > > me) if you think of there English meaning. > > That's possible, I'm not a native english speater :) I'm not either :-) > The idea is that we pull our stack from one place (current base) to > another. Another possiblity would have been "stg rebase", but I'm not > very keen on adding another command to do a very similar job. Can you give a typical example of what argument for --to is and what you repository looks like? I just want make sure I correctly understand the problem. I see the 'pull' command as a way to fetch the latest remote changes and merge them into the current branch (which would usually be a fast-forward). This command was meant as a stgit-aware 'git pull'. > > As Petr suggested at the OLS last year, I added the possibility to > > configure the 'git pull' command so that people use whatever script > > they like. > > Right. Maybe different workflows should have this option set to > different values in different repos ? I'm merely trying to get the > best default :) But you want to replace the call to 'git pull' with 'git fetch'. I think this is fine with my workflow but some people might actually rely on calling 'git pull' (or cg-pull). > > I was working on a set of patches (mainly picking from other > > branches and minor modifications) and just committing them when > > finishing. Further updates from kernel.org triggered full merges > > with the base. > > But doing this means that you can end with a base that is not any more > on the parent branch, but on a local merge, right ? I'm not sure it > is an easy thing to work with. Yes, indeed, but this is probably the only way you can publish a branch and still partially manage it with StGIT. > On the StGIT front, we could have "stg clone" look at > patches//current or so, and then modify the > remote..fetch entry accordingly. Or do you think of any > workflow that would break under this change ? Currently, 'stg clone' just calls 'git clone' and initializes the master branch. There is no patches//current file as there is no current patch. > Even if we would not need it here, it would be good to have those 2 > parameters set when we can infer them. That reminds me that "stg > clone" does not appear to allow selecting a specific branch in the > parent repo (which explains why the .merge parameter is not so > crucially needed yet: we always clone the main branch). I haven't looked at 'git clone' recently, can you select a specific branch? -- Catalin