Support sub folder reconciliation logic

[sambhav]

Currently if a git repository with a sub folder is used, kpack performs a rebuild even if the subfolder contents are not changed at all.

This is problematic for monorepos with lots of changes. We should support such use cases and only build when necessary.

[tylerphelan]

I like it, we would graciously accept a pr!

[matthewmcnew]

@samj1912 How would you expect kpack to detect sub directory specific changes?

[sambhav]

I would imagine that the source controller would need to be changed so that it has the latest commit and the latest effective commit and a build to be triggered only if the latest effective commit changes.

The latest commit reconciliation logic would remain as is but we would need to add a new effective commit field that has additional logic which is equivalent to https://stackoverflow.com/questions/12671404/latest-commit-hash-of-subdirectory

[chenbh]

Note: this subfolder logic should only apply if .spec.source.git.revision is a branch. Since if an Image is configured with a commit hash or tag, I would assume the user wants to build that exact git tree regardless of files changed in the subfolder.

Pedantry corner

I guess it's technically possible for tags to be re-pushed, and one of those re-pushes could have a change affecting the subfolder. But I consider this enough of an edge case to say we shouldn't support it.

[chenbh]

#1358 caused a memory usage regression and has been reverted in #1476.