Re: StGIT discards local commits on "stg pull"

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Feb 19, 2007, 23:07 UTC
Message-ID: <b0943d9e0702191507m636348e7yab2a712925f9f55@mail.gmail.com>
In-Reply-To: <20070212214704.GS5362@nan92-1-81-57-214-146.fbx.proxad.net>

On 12/02/07, Yann Dirson <ydirson@altern.org> wrote:

Show 10 quoted lines

> On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:
> > No, I agree it's a bug.  Rebasing after a fetch should allow this
> > workflow to work as well.  If the parent branch is not a rewinding
> > one, we should ensure there is nothing lost.  And even for rewinding
> > branches, we should probably keep track of the existence of commits,
> > so we can warn and nothing gets lost without knowing.
>
> Thinking about it, detecting whether we're going to lose a commit is
> just checking *before pulling* whether the current base is reachable
> from the parent's current head.

There is a potential problem with this approach - pulling/fetching from a tree which is always rebased (either managed with StGIT or simply running git-rebase before publishing it) would report an error since the old base is no longer reachable from the current head. In this case, the current fetch+rebase behaviour would be desirable.

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

Let me know what you think so that I'll try to release a 0.12.1 update (I already have the simple patch for using git-pull by default if you are OK with this scenario).

Thanks.

-- 
Catalin