On Mon, 2007-02-19 at 23:07 +0000, Catalin Marinas wrote:
quoted text
> 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.

One possible workaround would be to report an error and do nothing if
the old head would become unreachable (it's possible that I'm missing
something and that it was discussed to death already).

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

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

Any fix for the current behavior would be fine to me.  Either restore
the old default or don't rebase if the old head becomes unreachable.

-- 
Regards,
Pavel Roskin

-
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