Re: Optimizing writes to unchanged files during merges?

>
>> On 16 Apr 2018, at 19:45, Jacob Keller <jacob.keller@gmail.com> wrote:
>>
>> On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider
>>> <larsxschneider@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