gitlabhq
Use git log --follow to get commits collection. Closes #6966 of gitlabhq/gitlabhq
Coverage decreased (-0.48%) when pulling e151fcb7b962739ff47532c94265f4faa3bdc8d0 on laube:fix/commit_where_follow into 7860e500f14f24cb7726372caf936e8b80217d3a on gitlabhq:master.
Coverage decreased (-0.48%) when pulling f79fe704ccd2fbe0675a55b2bd522ec244729842 on laube:fix/commit_where_follow into 7860e500f14f24cb7726372caf936e8b80217d3a on gitlabhq:master.
@laube is this something you can get working again? Perhaps @woita, @akzhan, and @mr-vinn may be able to help or at least offer tips.
For reference: related to https://github.com/gitlabhq/gitlabhq/pull/3502, https://github.com/gitlabhq/gitlabhq/pull/7417, https://github.com/gitlabhq/gitlabhq/issues/7832, https://github.com/gitlabhq/gitlabhq/issues/6966
I'm not sure we want this in gitlab_git - I agree with @woita in https://github.com/gitlabhq/gitlabhq/pull/7417#issuecomment-50961245 that GitLab should dictate whether --follow is used. This PR would make it impossible to call Commit::where with follow: false
Hmm so do you think the original solution proposed at https://github.com/gitlabhq/gitlabhq/pull/7417 would work.
@bbodenmiller Yeah, I would probably vote to put it in GitLab instead of the gem. But since gitlabhq/gitlabhq#7417 does the same thing as this PR and always uses --follow when a path is given, I think you could make a case for either one.
Ideally I think it would be nice to have GitLab set the option and default to follow: true, but allow the UI/API to override the default. So instead of making --follow dependent on whether a path is given, we could add a follow parameter to GitLab's Repository#commits that defaults to true.