On Mon, 2007-02-19 at 23:07 +0000, Catalin Marinas wrote: > On 12/02/07, Yann Dirson <ydirson@xxxxxxxxxx> 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). > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html