On Tue, Apr 10, 2007 at 17:48:29 +0100, Catalin Marinas wrote:
quoted text
> >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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html