git-deps shows unrelated commits when dependency of 'merge' commits are checked

[vigneshraman]

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?

[aspiers]

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!

[aspiers]

BTW you should find git-deps -d quite useful for understanding how the algorithm works.

[vigneshraman]

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.

[aspiers]

Sorry I didn't find time to look at this yet. I haven't forgotten about it though.

[vigneshraman]

Thanks. Please check if https://github.com/aspiers/git-deps/pull/55 fixes the above mentioned problem.

[aspiers]

Thanks, I will!