walt <wa1ter@xxxxxxxxxxxxx> wrote: > Shawn O. Pearce wrote: > > walt <wa1ter@xxxxxxxxxxxxx> wrote: > >> First, 'make install' as root leaves dozens of files owned by root > >> in my personal source directory. > > > Which files, specifically? ... > > ~/src/git $find . -user 0 > ./git-fsck-objects ...+100 files... This is caused by below... > >> Second, this is a more recent problem with 'make install': > >> make -C git-gui all > >> make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui' > >> GITGUI_VERSION = 0.6.GITGUI > > > Hmm. You can't get the right version number for git-gui. Do you > > have tags fetched? > > Oops. I stupidly forgot to tell you the reason for the failure > when running the script as root: /usr/local is not in root's path, > and thus /usr/local/bin/git-* can't be found. Since the script > assumes that git is already installed and working, I would guess > that it would also fail if I had just fetched Junio's repository > for the first time and attempted an initial install. Right. So what is happening is the toplevel Makefile tries to run GIT-VERSION-GEN to obtain the version, that calls git-describe, which does not exist, fails, and falls back on the hardcoded version number. That version number differs from what the software was compiled with, so it gets recompiled. Instant set of +100 files owned by root. Same issue happens down inside of git-gui. I think the only answer I have for you is the following: If you want to run the Makefile without having git in your path then make a tarball first (make dist) with Git in your path, then unpack the tarball and compile that. This works as the tarball embeds version and credits files that sidestep the need for git-describe. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html