Catalin Marinas wrote:
On 27/02/06, Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
An idea (untested, I don't even know whether it's feasible) would be to
check which patches were merged by reverse-applying them starting with
the last. In this situation, all the merged patches should just revert
their changes. You only need to do a git-diff between the bottom and the
top of the patch and git-apply the output (maybe without even modifying
the tree). If this operation succeeds, the patch was integrated and you
don't even need to push it.
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.
I'll try this patch for a bit more before pushing into the repository.
i think this is a cool idea. but it seems still to require a bit of
convention on the part of the maintainer.
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 is
also a good idea so that the history contains the exact attribution of
each change.
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@xxxxxxxxxxxxxx
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard