Re: [PATCH] Add a testcase for the safety of pull-policy='pull'.

From: Yann Dirson <ydirson@altern.org>
Date: Feb 28, 2007, 21:48 UTC
Message-ID: <20070228214851.GC4149@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0702271538q32e6a9d5y6ac73adfc4854ab6@mail.gmail.com>

On Tue, Feb 27, 2007 at 11:38:45PM +0000, Catalin Marinas wrote:

Show 8 quoted lines

> >> BTW, push --undo now requires a status --reset beforehand.
> >
> >Oh, I had not noticed that.  Why so ?  It's not like if "push --undo"
> >would lose any valuable data...
> 
> I added it so that one cannot remove the local changes by doing a
> "push --undo" in error. You would have to explicitly ask for local
> changes removing with status --reset.

At least, the message in that case should probably be made better, when undoing to avoid having to resolve a conflict: the message says I cannot undo because I have a conflict, whereas it is the exact reason why I want to undo. Especially, since the conflict markers are now auto-recorded, we could simply allow undo in that case.

Show 8 quoted lines

> >What strikes me most in this case is the difference in behaviour
> >between this type of conflict (conflict marked in index, so needs an
> >operation outside the current scope of stgit to proceed), with a
> >regular stgit conflict that occurs during a push (index clean,
> >conflict info not available to tools written for regular GIT).
> 
> I think this is a valid GIT conflict as the upstream tree re-wrote the
> history and git-pull will trigger a 3-way merge.

I do not discuss the validity of the conflict. I'm just emphasizing that it makes it hard to handle things in stgit, with *any* post-rebase processing being skipped. For now we seem to have nothing critical for that workflow (I'll surely end up with deactivating the orig-base check for pull-policy=pull), but that may cause more trouble later, eg. when implementing transactions.

> If you would always use git-fetch + stgit-rebase, there wouldn't be
> any problem.

Sure, that's why I'm lobbying for this policy to be the default :)

> (BTW, I just added a patch for a 2-way interactive merge as well).

Sounds great - I just had an add/add conflict today on 0.12.1 when trying to play with "resolved -i", and it loudly complained it had no ancestor to play with. Sounds like a perfect usage for 2-way merges.

Best regards,

-- 
Yann.