Committed patches should be removed from plaid

[ftomassetti]

We have figure out how to determine if a patch has been committed.

• Do we want to use a git hook?
• What to do about mercurial?
• Can be the patchwork script imported?

[lu-zero]

The patchwork script requires to run on a tree and it is just working on patches (scm-agnostic), but has an high ratio of false-negatives so would be good to look at it and see why.

The way it works require to support some kind of rpc, an initial version can just share the plaid configuration, use a local tree and directly use the database.

Makes also easier to check if a patch applies.

[ftomassetti]

rpc?

[lu-zero]

xml-rpc to be specific. I won't mimic it.

[ftomassetti]

Does this make sense? http://git.661346.n2.nabble.com/Figuring-out-which-patches-have-been-applied-td3755727.html

#!/bin/bash 

set -o pipefail 
searchCommitID=`git rev-parse $1` 
searchPatchID=`git show $searchCommitID | git patch-id` 
if [ $? -ne 0 ]; then 
        exit 1 
fi 
searchPatchID=${searchPatchID% *} 

echo "Searching for equivalents to commit $searchCommitID (patch 
$searchPatchID)..." 
git log --all -p | git patch-id | grep $searchPatchID | 
while read patchID commitID; do 
        if [ "$commitID" = "$searchCommitID" ]; then 
                echo "Exact commit $commitID is on the following branches:" 
        else 
                echo "Equivalent commit $commitID is on the following branches:" 
        fi 
        git branch -a --contains $commitID 
done

[ftomassetti]

Perhaps we could use the date: we look at the files involved and their history. If we find a commit by the same author at the same time it means the patch was committed

[lu-zero]

DESCRIPTION
       A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a patch, with whitespace and line numbers
       ignored. As such, it's "reasonably stable", but at the same time also reasonably unique, i.e., two patches that have the
       same "patch ID" are almost guaranteed to be the same thing.

This help if the only change in the commit patch is in the message. If we want to go this route we should keep a list of sha1 per-hunk and use it to decide if a patch is an update or not.

All depends on the control of the users and if for minor changes (e.g. bumping the version file when rebasing a set over another just merged) it is worthy to spam the mailing list or not.

Are you willing to play with the concept I'd make it a stand-alone library.

For now probably it is a good initial approximation using the patch-id.

[lu-zero]

I guess we can use any of those heuristic, implement one see how many false positives we can get and the how many false negatives and let the user improve it.

If we manage to make a better job in figuring out what is an update to what probably the patch ID approach would be enough.