On Tue, Apr 10, 2007 at 17:48:29 +0100, Catalin Marinas wrote: > >Fix in apply_diff() relaxes the restriction in 'push --merged' and > >'rebase --merged' for detection of upstream merges, fix in > >apply_patch() does relaxation 'import', 'fold' and 'sync' commands. > > Thanks for the patch. I'm OK with -C1 in apply_patch() but I'm a bit > concerned with the 'push/rebase --merged' logic being relaxed. There > is also the reporting of patches being modified during 'push', i.e. > the push succeeded only after a three-way merge. > > I think I could add separate config options for both apply_diff and > apply_patch, only that it might confuse users not knowing the StGIT > internals. Aha, I've made a mistake, I wanted to say 'pull --merged and rebase --merged', not 'push'. The idea was that StGIT should be liberal when it decides if the patch was applied upsteam, it should not force the user to merge her own patch back because of different context upstream. Of course we can imagine the situation when during such merge the user will realize that her patch was applied upstream incorrectly, but such cases will be rare, so better not to enforce the merge. But I see your point, and back then I didn't realize how it will affect the 'push' command. So, I think the best would be to have 'pull'-like commands (pull, rebase, import, fold, sync) to be liberal by default (accept pathes with -C1), while 'push'-like commands (push, any other?) to be conservative (require full context match). And both classes should provide the way to explicitly control acceptance level. -- Tomash Brechko - 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