On 15/01/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote: > >I have started work on implementing "stg pull --to <newbase>", 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 <newbase> 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/<branch>/current or so, and then modify the remote.<name>.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/<branch>/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 - 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