Re: StGIT discards local commits on "stg pull"

From: Yann Dirson <ydirson@altern.org>
Date: Feb 20, 2007, 18:55 UTC
Message-ID: <20070220185532.GA4149@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <20070220000059.GK4248@nan92-1-81-57-214-146.fbx.proxad.net>

On Tue, Feb 20, 2007 at 01:00:59AM +0100, Yann Dirson wrote:

Show 15 quoted lines

> 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.