Re: StGIT discards local commits on "stg pull"

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 12/02/07, Yann Dirson <ydirson@altern.org> wrote:
> 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