2008/6/7 Karl Hasselström <kha@xxxxxxxxxxx>:
> As I said, I've been thinking a bit about stg pull and stg rebase
> recently (though I haven't written any code; I don't want to be
> juggling too many balls at once).
>
> Currently, there's stg rebase which only does rebasing, and stg pull
> which does either rebase or merge depending on a config option. And on
> top of that there's config stuff like stgit.pullcmd that is invoked in
> some cases but not others.
This would need some clean-up indeed or maybe better documentation.
They might be a bit difficult and I have to look at the code from time
to time. 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
> 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.
> * When pull is invoked, the following happens:
>
> 1. The branch we pull from may be updated, depending on the
> configuration. (e.g. git fetch or git svn fetch)
OK.
> 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?
> 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.
> Fast-forward is the default if no configuration or command-line
> flag is given.
OK.
> I've personally never had a need for the merge case, but I recall you
> arguing to keep it, Catalin?
I don't use it either but there might be people that have complicated
configurations and they mix Git commits with StGIT patches. Not sure
though.
--
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
