On Mon, Feb 19, 2007 at 11:07:09PM +0000, Catalin Marinas wrote: > >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. Right - a better solution is highlighted in today's proposal (which I have started to implement). > 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. We could do this, but I only see this as a temporary measure to avoid unleashing the new behaviour onto unsuspicious users before we've ironed out the final behaviour. I still think that the current behaviour belongs to a very specific workflow which is not that expected by most users. > Ideally, we'll have this configurable per-branch (and could > leave the global one as well if the most specific is not available, Right. > 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). Since it is important that users don't unknowingly loose commits, yes it is preferable to release 0.12.1 with the old behaviour. Let's take the time to shake things more for 0.13, and we can reconsider this choice by then. Best regards, -- Yann. - 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