Sending again without HTML Den mån 10 sep. 2018 kl 12:28 skrev Hultqvist <hultqvist@xxxxxxxxxxxxxxx>: > > First I need to correct my previous observations. > > Today there appeared new set of config files in the root. > I looked into a few of them and found that their content doesn't match that of the repo at "G:/Min enhet". > Instead separate files had content from separate git repos within the G drive. > These repos are not like the one we're discussed previously, they are completely within G: using a classical .git directory. > > I guess git is creating the temporary files as close as possible to the root, since "G:\" can't be written to, only "G:\Min enhet". and then copy them to the final destination which in this case is the same drive. > If so then we can't get away from the duplicate files, the duplicates themselves are the fault of Google Drive File Stream. > If git would create the config/master/index files within the .git dir to start with that would hide the clutter from the root but not prevent the duplicates. > Is this observation correct, that git creates temporary files closer to the root than inside the .git directory or a sub directory thereof? > > I haven't experiences any issues working with these repos themselves. > One risk could be that the final "index" is an older version than "index (45)". > I'm certain this haven't been the case since I push every commit to a remote repo that doesn't accept changes in history. > > I understand that master and index needs to be updated with regular use. > Does config need the same amount of updates? > I've considered that file to only change when I make explicit changes, not during regular use(push, commit, status). > > Thanks for the help looking into this for me. > > > Den sön 9 sep. 2018 kl 17:30 skrev Hultqvist <hultqvist@xxxxxxxxxxxxxxx>: >> >> Since this thread started I haven't seen a single file mentioned being created, >> Usually they appear during work days when there is more activity. >> I've never seen the files created directly, only a larger amount of >> them once in a while. >> >> I will run process monitor and get back once I find out more. >> Den lör 8 sep. 2018 kl 15:44 skrev Duy Nguyen <pclouds@xxxxxxxxx>: >> > >> > On Sat, Sep 8, 2018 at 3:09 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> > > >> > > On Sat, Sep 8, 2018 at 11:28 AM Hultqvist <hultqvist@xxxxxxxxxxxxxxx> wrote: >> > > > >> > > > The bash commands are using a git and bash bundle that was installed >> > > > in parallel with gitextensions(a gui for git) >> > > > >> > > > G:\Min enhet> set GIT_TRACE_SETUP=1 >> > > > G:\Min enhet> git st >> > > > 10:40:28.881927 trace.c:318 setup: git_dir: >> > > > C:/Users/hultqvist/Drive.git >> > > > 10:40:28.881927 trace.c:319 setup: git_common_dir: >> > > > C:/Users/hultqvist/Drive.git >> > > > 10:40:28.881927 trace.c:320 setup: worktree: G:/Min enhet >> > > > 10:40:28.881927 trace.c:321 setup: cwd: G:/Min enhet >> > > > 10:40:28.881927 trace.c:322 setup: prefix: (null) >> > > > 10:40:28.882930 chdir-notify.c:67 setup: chdir from 'G:/Min >> > > > enhet' to 'G:/Min enhet' >> > > >> > > Unfortunately this looks good. Whenever those files 'index', >> > > 'config'... are created, they should always be created in >> > > C:\Users\hultqvist\Drive.git, not G:\Min enhet, including their >> > > temporary versions. I don't know if there are any more changes on the >> > > windows fork that could affect this though, I only checked git.git. >> > >> > BTW do you notice these files showing up after any particular command >> > or they're always there after cloning? Perhaps some command got the >> > ".git" directory discovery wrong and assumed $GIT_DIR=$GIT_WORK_TREE. >> > We have a much bigger problem then. >> > -- >> > Duy
