Do not check dependencies for already cherry-picked commits

[vigneshraman]

If a commit is already cherry-picked, git-deps tool will still check for the dependent commits. This commit will check if a commit is already cherry-picked and will avoid checking the dependencies for that commit.

[vigneshraman]

@aspiers Please review. Thanks.

[aspiers]

Thanks. I'm probably missing something - please can you explain why we should skip cherry-picked commits?

[vigneshraman]

I'm using the git-deps tool for linux kernel backporting work.

I'm backporing some commits from v3.12 to v2.6. From 'master' I have already cherry-picked commit 'fa77dcfa' to 'v2.6_branch'

commit 00112233 Author: Test test@test.com Date: Fri Feb 26 18:06:53 2013 +0900

(cherry picked from commit fa77dcfa) Signed-off-by: Test test@test.com

Now I want to backport another commit 'dbde0abe' from v3.12 to v2.6 and I use git-deps tool to find the dependent commits. I give '-e' option to exclude commits are already present in v2.6_branch and to show only dependent of commit 'dbde0abe'. git-deps -r -e v2.6_branch dbde0abe, shows

dbde0abe 7a4c5de2 dbde0abe fa77dcfa fa77dcfa fd034a84 fa77dcfa 813e5727

Even though 'v2.6_branch' branch has the commit 'fa77dcfa' cherry-picked from v3,12 (commit 00112233), git-deps will still show in the list of dependent commit the original commit (fa77dcfa).

I hope I explained the use case and reason to skip cherry-picked commits. Thanks.

[aspiers]

Thank you, that's extremely helpful! In that case I don't understand why is_excluded() doesn't return True for fa77dcfa - do you have an idea? It would be helpful to run it with debugging enabled.

[vigneshraman]

I will check why is_excluded doesn't return true in this case with debugging enabled.

[aspiers]

Thanks!