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