From: John Garry <john.garry@huawei.com>
Date: Thu, 24 Mar 2022 12:56:32 GMT
Subject: Re: [Question] .git folder file updates for changing head commit
Message-ID: <f80bac33-7864-8f31-d81f-78cf7cb2987d@huawei.com>
In-Reply-To: <YjuCSpAHD6xHkb5G@nand.local>

On 23/03/2022 20:25, Taylor Blau wrote:
> On Wed, Mar 23, 2022 at 03:19:06PM +0000, John Garry wrote:
>> For building the linux perf tool we use the git head commit id as part of
>> the tool version sting. To save time in re-building, the Makefile rule has a
>> dependency on .git/HEAD for rebuilding. An alternative approach would be to
>> compare git log output to check current versus previous build head commit,
>> but that is seen as inefficient time-wise.
> Having a Makefile recipe that depends on $GIT_DIR/HEAD seems strange to
> me.
> 

Yeah, as mentioned, the idea was the we can check a rebuild on this 
rather than running a relatively time-consuming command like "git 
describe". Wasn't my idea :)

> Presumably your Makefile rules would map out which parts of your program
> depend on each other, and would get invalidated when the source itself
> changes, no?

Correct, they do. It's just the part which constructs the app version 
tag which depends on this.

> 
> Perhaps you also care about the commit you're building from in order to
> embed something into your program. But it seems like you could inject
> the output of "git rev-parse HEAD" when you construct the version
> identifier whenever you do need to rebuild.
> 

ok, so I think that we may need to run a git command always one way or 
another.

Thanks,
John