Re: [Question] .git folder file updates for changing head commit
- From
- John Garry <john.garry@huawei.com>
- Date
- Mar 24, 2022, 12:56 UTC
- Message-ID
- <f80bac33-7864-8f31-d81f-78cf7cb2987d@huawei.com>
- In-Reply-To
- <YjuCSpAHD6xHkb5G@nand.local>
On 23/03/2022 20:25, Taylor Blau wrote:
Show 9 quoted lines
> 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.
Show 6 quoted lines
> > 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