Open vigneshraman opened 9 years ago
Are you using -r
? That is known to run for an extremely long time in many cases. We actually need some way to limit recursion to a maximum depth (see also #16), or to a given list of revision ranges.
But --no-merges
sounds like it could be a good idea too. Again it would help if you could provide an exact testcase with which I can reproduce the issue.
Thanks for the report!
BTW you should find git-deps -d
quite useful for understanding how the algorithm works.
I'm using the git-deps tool for linux kernel backporting work.
Yes I used -r option. I will check -d option, Thanks.
I'm backporing a commit from v3.12 to v2.6
So the use case is: I want to backport commit '48d9eb97dc74d2446bcc3630c8e51d2afc9b951d' from master to 'v2.6_branch'
git-deps -r -e v2.6_branch 48d9eb97
This runs for long time when it tries to find dependency for commit a107e5a3a473a2ea62bd5af24e11b84adf1486ff which is a merge commit.
Sorry I didn't find time to look at this yet. I haven't forgotten about it though.
Thanks. Please check if https://github.com/aspiers/git-deps/pull/55 fixes the above mentioned problem.
Thanks, I will!
I'm using the git-deps tool for linux kernel backporting work.
When git-deps is run to find any dependent commits in linux kernel there is a chance it encounters 'merge' commits. git-deps output is very huge when it checks dependency for 'merge' commits and git-deps needs to be stopped manually since it runs for a very long time.
Maybe '--no-merges' needs to be used to avoid merge commits?