On 01/03/06, Chuck Lever <cel@xxxxxxxxxxxxxx> wrote: > Catalin Marinas wrote: > > I attached another patch that should work properly. It also pushes > > empty patches on the stack if they were merged upstream (a 'stg clean' > > is required to remove them). This is useful for the push --undo > > command if you are not happy with the result. > > if maintainer X takes a patch "a" from developer Y, but modifies patch > "a" before committing it, then your nifty automated mechanism will still > have trouble merging developer Y's stack when Y pulls again. > > the convention might be that maintainers who accept patches will always > accept exactly what was sent, and then immediately apply another commit > that addresses any issues they have with the original commit. This won't solve the problem since testing whether patch "a" was merged upstream will fail because its reverse won't apply cleanly onto the upstream HEAD. Of course, you can try combination of upstream commits and local patches but it's not really feasible. As I said, this method doesn't solve all the upstream merge situations but it is OK for most of them. -- Catalin - : 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