Do a full clone when tag filter is set and branch is not

[regisbelson]

I tought I was opening this against my own fork but... let's do this anyway.
Tag filtering is quite useful but being limited to the tracked branch isn't suitable for all workflows. In our team, we tag commits from other branches and expect to be able to build/deploy these tags if we want to.
Cloning with --single-branch prevents that. Since you can't know if the commit exists in a given branch before cloning the repository, just clone everything when there are tags involved unless you explicitly specified a branch to track.

[pivotal-issuemaster]

@kurlzor Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@kurlzor Thank you for signing the Contributor License Agreement!

[r-chris]

I was about to do a similar thing. You @kurlzor probably need to update the documentation as well. Right now the branch documentation talks about it defaulting to the master.

[vito]

This was previously attempted in #165 which ended up with a fairly complicated discussion. I'm not sure the proposed changes are enough.

To be honest, I don't think we should have pulled in the tag_filter behavior, and that should really just be a different resource. The semantics are entirely different. This may be something we consider during the migration to the new resource interface that we're planning in concourse/rfcs#1.

[vito]

Hmm, I think this should maybe just be closed for now (because #165 showed that things are a bit more complicated), and we should revisit tag_filter in the future. It may make more sense to have support for tags across all branches as another way to support spaces (concourse/concourse#1707), either with this resource type or a more tag-focused one.

Thanks for PRing this though!