On Tue, Feb 20, 2007 at 01:00:59AM +0100, Yann Dirson wrote:
quoted text
> On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote:
> > > I think the fail-safe solution would be to leave the old behaviour
> > > (i.e. git-pull and pull-does-rebase=no) and people that need to pull
> > > from branches like that described above would use the fetch+rebase
> > > approach. Ideally, we'll have this configurable per-branch (and could
> > > leave the global one as well if the most specific is not available,
> > > but should default to git-pull).
> > 
> > By the way, it would be great to reduce all complexity to "one bit" per
> > branch.  If stgit.internal-pull (the name is subject to improvement) is
> > on, "stgit pull" calls git-fetch and does rebase.  Otherwise, it calls
> > git-pull.  No need to configure two variables per branch.
> 
> Being able to specify the command to use makes it possible to hook to
> other SCM's (eg. using git-cvsimport, git-svn or similar).

Thinking twice, we could make things even better :)

Let's acknowledge that we have several ways of pulling, by getting rid
of the awkward 'stgit.pull-does-rebase'.  Instead we could use a new
"pull-policy" setting, with possible values "pull" and "fetch-rebase"
to match the 2 currently-available behaviours.  Then according to the
pull-policy, "stg pull" would use "pullcmd" or a new "fetchcmd"
setting, thus removing the requirement to mess with pullcmd in the
common case.

All of "pull-policy", "pullcmd", and "fetchcmd" would have a
per-branch and a global setting (stgit.<foo> and
branch.*.stgit.<foo>).

We could also introduce a 3rd "rebase" policy, to support local parent
branches better.

Best regards,
-- 
Yann.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html