On 10/04/07, Tomash Brechko <tomash.brechko@xxxxxxxxx> wrote:
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.
When something has changed in the surrounding code (not touched by your patch), the automatic three-way merge should, in general, be able to solve the issue as it uses the ancestor information. Is the automatic three-way merge failing as well in your case?
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 -C1 should be OK for merge detection (in most situations) and importing patch files (via import, fold) but I personally don't like it when rebasing a patch. I still prefer a more precise context checking, rather than the fuzzy one similar to the "patch" tool (as the line numbers are usually volatile). I'm OK with the idea of this patch but I would prefer a config option and/or command line option rather than hard-coding it for people with different views. A command line option could make sense for commands like import/fold and a config option for the rest. Thanks. -- 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