On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:
> However, I found some these policies useful. For example, I just do
> a "stg pull" from a Subversion repository with the config below:
>
> [stgit]
> pull-policy = fetch-rebase
> fetchcmd = git svn fetch
> rebasecmd = git svn rebase
Looks useful.
But what exactly is "rebasecmd" useful for, when you already have
"fetchcmd" and a built-in rebase?
> 2008/6/7 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > What I think I'd like is the following:
> >
> > * Just one command, stg pull. stg rebase is removed.
>
> I still find "rebase" useful and use it in some situations when I
> don't need a pull. As Jakub mentioned, maybe we could keep the
> "rebase" functionality outside of the "pull" command (make it part
> of Stack with a corresponding Branch.rebase?) and have "rebase" use
> it.
Yes. We could have "stg rebase" == "stg pull --rebase --no-fetch".
> > 2. Depending on the configuration (overridable by the
> > --fast-forward, --rebase, and --merge options), one of these
> > three things happen:
>
> But "pull" always suggests fetching something. Adding "--rebase"
> would mean that it doesn't fetch. Shouldn't we leave this
> functionality to "rebase" only?
These two things are orthogonal:
1. Whether and how to update the branch we're pulling from
(fetching).
2. How to do the actual pulling (rebase, fast-forward, or merge).
I envision (1) being controlled by the branch config (and overridable
with a --no-fetch option or something), and (2) being controlled by
another part of the branch config (and overridable with
--fast-forward, --merge, and --rebase).
> > 1. We pop all patches, fast-forward to the new base, and
> > push them back. If it's not a fast-forward, we error
> > out.
> >
> > 2. We pop all patches, reset to the new base, and push
> > them back.
> >
> > 3. We pop all patches, merge with the other branch, then
> > push the patches back.
>
> These are OK, with the comment on have rebase functionality in
> "rebase" only.
Why? I don't see the difference between rebase and the other two that
would motivate such a separation.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
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
