On 01/03/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
On Wed, Feb 28, 2007 at 10:48:51PM +0100, Yann Dirson wrote: > On Tue, Feb 27, 2007 at 11:38:45PM +0000, Catalin Marinas wrote: > > 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.
That's because of the order of the safety checks.
> Especially, since the conflict markers are now auto-recorded, we could > simply allow undo in that case. Actually, I find the behaviour to be much worse than before: forcing the user to run "status --reset" before "push --undo" indeed brings the patch that conflicted in a state where it is partly committed.
I don't have a strong opinion on forcing status --reset before push --undo anyway, so I can revert that commit (it bothers me a bit as well :-)).
Indeed, the problem may well be that we should not commit the unresolved conflict. Why it has some value, recording it as if the user had refreshed the patch is probably not a good idea at all, precisely because we're mid-way in the push, and that the operation can be aborted without stgit knowing.
The idea of commit 0f4eba6a37c1a5454560b097873e5a22bfcde908 was to only show the conflict files with 'stg diff' and also allow me to later see how I fixed a conflict via the 'stg log (-p|-g)' command. But this interim refresh shouldn't affect the backup information (backup = False in Series.refresh_patch). Do you have a simple test showing this problem? Regards. -- 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