{"thread":{"id":"6130","subject":"Re: git-add & \"file vanishing\" -> need git-add again [reformatted]","startedAt":"2006-12-27T21:58:51Z","lastAt":"2006-12-27T21:58:51Z","messageCount":1,"participants":["David Tweed"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30366","messageId":"e1dab3980612271358w3dec594cy8453910ca9064806@mail.gmail.com","threadId":"6130","inReplyTo":null,"subject":"Re: git-add & \"file vanishing\" -> need git-add again [reformatted]","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2006-12-27T21:58:51Z","receivedAt":"2006-12-27T21:58:51Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"This is a resend of previous mail reformatted.\n(Unfortunately even university staff acounts\nthese days seem to only give you unconfigurable\nweb-browser interfaces; hopefully gmail won't butcher\nthe 72-character wrapped layout I'm seeing on my\nscreen right now too much.)\nMany thanks for your forbearance and any insight.\n\nOriginal message<<<<<<<<<<<<<<<<<<<<<<<<\n\nHi, I'm working on using git for chronological backups (think\nselective P9 venti), which I've almost got working. (I know I'm using\ngit for something it wasn't designed for, and is arguably perverse.)\nI've been trying to figure out why files which \"ought\" to be tracked\nweren't in the database in certain commits and I think I've figured\nout why.  Can someone confirm the following: with the set of\noperations\n\ngit-init-db ....\ngit-add path/to/fileX\ngit-commit -a -m blah <1>\n..... changes to things including fileX and commits\n[fileX vanishes from the tree being tracked, but nothing\nmentioned to git] <2>\n..... changes to things and commits\n[file X reappears in the working tree being tracked]\n<3>\ngit-commit -a -m blah <4>\n\nThe git trees from <1> to <2> all contain fileX, even if its contents\nhaven't changed. Between <2> and <4> the git tree doesn't contain\nfileX (perfectly properly). From <4> onwards fileX still doesn't\nappear in the git trees recorded from the working directory even\nthough fileX is there again. If I want fileX tracked I have to\nexplicitly git-add it again at <3>. (Ie, git-commit -a when it detects\na file have vanished from the working tree removes it from the files\ngit will look at in future for changes to commit.)\n\nIs it also correct that this behaviour (\"forget\" about a tracked file\nwhen it disappear from the working tree in a commit) would be\ndifficult to change without major surgery to git?  Would there be any\nproblems with git-add'ing every file you want the tree to track before\nevery commit?\n\n(I'm currently working on code to keep track of things that have ever\nbeen tracked, and whether they're currently in the tree, in my scripts\noutside git but obviously partially duplicating stuff git has in its\ndatastructures has the potential for subtle bugs when they diverge.)\n\nLong story:\n---------------\n\nI'm trying to move a snapshotting-style system from my personal\nhack-job to git. As well as manual snapshots there's a cron job that\nruns every hour to snapshot stuff. Consequently there will be\n\"automatic commits\" when you wouldn't have made one if you were doing\nnormal source control, eg, after you've wrongly deleted a file and\nbefore you've noticed & restored it from the database an automatic\ncommit can come in (and even more kinky situations you don't want to\nknow about) and so sees the file \"gone\".\n\nSidenote: I'm moving the database from the old format to the new one\nby repeatedly unpacking the old database for snapshot X, git-add'ing\nany file names which have _never_ been in any snapshot before,\ngit-commit -a, git-tag, then remove all the files unpacked by the old\ndatabase and move onto snapshot X+1. This takes less than a second per\nsnapshot. I understand this shouldn't be a problem but just to let\npeople know the timestamps on the files aren't what would be expected.\n\nFollow up clarification msg <<<<<<<<<<<<<<<<<<<<<<<<\n\n|Not sure how large your snapshots are -- a\n|second sounds like a long time for git operations. While it is a bit\n|more complex, you _can_ operate directly on the index, and the\n|\"snapshot\" never needs to hit the disk as such during your migration.\n\nBy trying to be brief I was a rather cryptic. What I was trying to say\nwas:\n\nRunning the git commands earlier in the message in a script, I see\nthat file are not present from the git tree generated by a commit at a\ntime when I know the file I'd previously git-added reappeared in the\nworking directory. I'm hypothesising that this is because when the\nfile disappears the machinery in git loses the `track this file'\ninformation. However, I haven't (and would prefer not to) dig into the\ngit code to check that's the correct explanation. If this is why the\nfiles aren't being tracked I can try to script around the issue by\ngit-adding all the files I want tracked by the snapshot before the\ngit-commit -a. To help anyone thinking about if the explanation is\nright, the working directory is repeatedly being wiped and refilled\nfrom my old backup system with a second, so often all files have both\ncreation and modification times set to the current second. This is a\nreally weird thing to do and might in some way be responsible for the\nuntracked file (cf racy-git).\"\n\nMost of the maybe half-second overhead is coming from my script\nunpacking the files with gzip from my old database; git seems more\nthan fast enough.\n\n|Have a look at how the cvsimport script works for an example.\n\nAs its my personal db which I'll only convert once if I can just make\nreplaying work I don't need anything more complicated; I've only got\n2000-odd snapshots.\n\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\nDetails are all that matters; God dwells there, and you never get to\nsee Him if you don't struggle to get them right. -- Stephen Jay Gould\n"}]}