From: Catalin Marinas Date: Mon, 19 Feb 2007 23:07:09 GMT Subject: Re: StGIT discards local commits on "stg pull" Message-ID: In-Reply-To: <20070212214704.GS5362@nan92-1-81-57-214-146.fbx.proxad.net> On 12/02/07, Yann Dirson 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