On Tue, Apr 10, 2007 at 23:21:30 +0400, Tomash Brechko wrote: > 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. Please disregard this part. It's late here, and I mistook StGIT's push for GIT's push. Once we are talking about StGIT's push (push of the patch back to the stack), why would we want to start tree-way merge when the context has changed? My point was exactly that since I want to keep my patches up-to-date with the main branch, I do rebase from time to time, and I'm not interested in doing the merge every time just because something has changed upstream in surrounding code. The same goes for patches that were already applied upstream. Whatever the current context around the code of my applied patch is, I have to accept it, because the patch was applied. I'm going to throw it away locally, but currently I have to do the merge first. I think I didn't get you point. -- 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