Hi John, I'm not a big expert on Make (or even Git :p) but think I can answer some of your questions. John Garry <john.garry@xxxxxxxxxx> writes: > Hi guys, > > I have a question about which files in the .git folder are updated as we > change the head commit. I could check the codebase myself but prob will > make a mistake and maybe some expert would be so kind as to just kindly > tell me. > > 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. You're on the right track because if .git/HEAD doesn't change, the HEAD is still pointing to either the same commit (if in detached HEAD) or branch (if not in detached HEAD). The problem is that when HEAD points to a branch, the branch's 'head commit' can change, implicitly changing the commit that .git/HEAD actually points to. > The problem is that actions like git cherry-pick and git reset --hard > HEAD^ may not update .git/HEAD (so don't trigger a rebuild). That's what's happening here. If your HEAD is pointing to "refs/heads/main", "cherry-pick" and "reset --hard" will change where "refs/heads/main" points, but HEAD still points to "refs/heads/main". Branches are often located in "loose form" under .git/refs/heads/*, *but* refs can also be stored in a "packed form" under .git/packed-refs (https://git-scm.com/docs/git-pack-refs). There is also a relatively new ref storage format called reftable that I'm not familiar with, but presumably stores its refs in other locations too. All of this is to say that depending on specific files under .git/ exposes you to a lot of Git internals that really aren't meant for external consumption. I suggest finding a different approach than watching Git-internal files for changes. > Is there some more suitable file(s) which we could use as a dependency? > From my limited experimentation, .git/index seems to always update when > the changing head commit. I think users typically expect the index (and therefore .git/index) to change when the head commit changes, but this isn't always true e.g. "reset --soft" will move the branch without changing the index. P.S. Even if you knew the value of .git/index or .git/HEAD, that wouldn't tell you whether or not the files in your working directory have changed, so I'm not sure if you want to use either as Makefile dependency. > > Thanks, > john
