> On 16 Apr 2018, at 19:45, Jacob Keller <jacob.kel...@gmail.com> wrote: > > On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: >> On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider >> <larsxschnei...@gmail.com> wrote: >>> What if Git kept a LRU list that contains file path, content hash, and >>> mtime of any file that is removed or modified during a checkout. If a >>> file is checked out later with the exact same path and content hash, >>> then Git could set the mtime to the previous value. This way the >>> compiler would not think that the content has been changed since the >>> last rebuild. >> >> That would only work until they actuall *did* a build on the second >> branch, and upon changing back, how would this detect that it needs to >> update mtime again? I don't think this solution really works. >> Ultimately, the problem is that the build tool relies on the mtime to >> determine what to rebuild. I think this would cause worse problems >> because we *wouldn't* rebuild in the case. How is git supposed to know >> that we rebuilt when switching branches or not? >> >> Thanks, >> Jake > > I think a better solution for your problem would be to extend the > build system you're using to avoid rebuilding when the contents > haven't changed since last build (possibly by using hashes?). At the > very least, I would not want this to be default, as it could possibly > result in *no* build when there should be one, which is far more > confusing to debug.
I am 100% with you that this is a build system issue. But changing the build system for many teams in a large organization is really hard. That's why I wondered if Git could help with a shortcut. Looks like there is no shortcut (see my other reply in this thread). Thanks Lars
