Closed vigneshraman closed 3 years ago
@aspiers Please review. Thanks.
Thanks. I'm probably missing something - please can you explain why we should skip cherry-picked commits?
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.
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.
I will check why is_excluded doesn't return true in this case with debugging enabled.
Thanks!
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.