On Tue, Feb 27, 2007 at 11:38:45PM +0000, Catalin Marinas wrote: > >> 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. > >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. - 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