{"thread":{"id":"6061","subject":"git-add,& \"file vanishing\" -> need git-add again?","startedAt":"2006-12-21T14:13:35Z","lastAt":"2006-12-21T20:27:23Z","messageCount":2,"participants":["David Tweed","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29952","messageId":"20061221141335.65170.qmail@web86902.mail.ukl.yahoo.com","threadId":"6061","inReplyTo":null,"subject":"git-add,& \"file vanishing\" -> need git-add again?","fromName":"David Tweed","fromEmail":"tweed314@yahoo.co.uk","sentAt":"2006-12-21T14:13:35Z","receivedAt":"2006-12-21T14:13:35Z","isPatch":false,"sender":{"key":"tweed314@yahoo.co.uk","avatar":null},"body":"Hi, I'm working on using git for chronological backups (think selective P9 venti),\nwhich I've almost got working. (I know I'm using git for something it wasn't\ndesigned for, and is arguably perverse.) I've been trying to figure out why files which \"ought\"\nto be tracked weren't in the database in certain commits and I think I've figured out why.\nCan someone confirm the following: with the set of operations\n\ngit-init-db\n....\ngit-add path/to/fileX\ngit-commit -a -m blah <1>\n..... changes to things including fileX and commits\n[file X vanishes from the tree being tracked, but nothing mentioned to git] <2>\n..... changes to things and commits\n[file X reappears in the 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 haven't changed. Between\n<2> and <4> the git tree doesn't contain fileX (perfectly properly). From <4> onwards fileX\nstill doesn't appear in the git trees recorded from the working directory even though fileX is\nthere again. If I want fileX tracked I have to explicitly git-add it again\nat <3>. (Ie, git-commit -a when it detects a file have vanished from the working tree removes\nit from the files git will look at in future for changes to commit.)\n\nIs it also correct that this behaviour (\"forget\" about a tracked file when it disappear from the\nworking tree in a commit) would be difficult to change without major surgery to git?\nWould there be any problems with git-add'ing every file you want the tree to track before every\ncommit?\n\n(I'm currently working on code to keep track of things that have ever been tracked, and whether\nthey're currently in the tree, in my scripts outside git but obviously partially duplicating stuff git\nhas in its datastructures 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 hack-job to git. As well as\nmanual snapshots there's a cron job that runs every hour to snapshot stuff. Consequently\nthere will be \"automatic commits\" when you wouldn't have made one if you were doing normal\nsource control, eg, after you've wrongly deleted a file and before you've noticed & restored it\nfrom the database an automatic commit can come in (and even more kinky situations you\ndon't want to know about) and so sees the file \"gone\".\n\nSidenote: I'm moving the database from the old format to the new one by repeatedly unpacking\nthe old database for snapshot X, git-add'ing any file names which have _never_ been in any snapshot\nbefore, git-commit -a, git-tag, then remove all the files unpacked by the\nold database and move onto snapshot X+1. This takes less than a second per snapshot. I understand\nthis shouldn't be a problem but just to let people know the timestamps on the files aren't what\nwould be expected.\n\nMany thanks for any insight,\ncheers, dave tweed\n\n\n\n\nSend instant messages to your online friends http://uk.messenger.yahoo.com \n"},{"id":"29966","messageId":"46a038f90612211227v2f1325e5i96ca6f773eb05def@mail.gmail.com","threadId":"6061","inReplyTo":"20061221141335.65170.qmail@web86902.mail.ukl.yahoo.com","subject":"Re: git-add,& \"file vanishing\" -> need git-add again","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-12-21T20:27:23Z","receivedAt":"2006-12-21T20:27:23Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/22/06, David Tweed <tweed314@yahoo.co.uk> wrote:\n> Sidenote: I'm moving the database from the old format to the new one by repeatedly unpacking\n> the old database for snapshot X, git-add'ing any file names which have _never_ been in any snapshot\n> before, git-commit -a, git-tag, then remove all the files unpacked by the\n> old database and move onto snapshot X+1. This takes less than a second per snapshot.\n\nNot sure how large your snapshots are -- a second sounds like a long\ntime for git operations. While it is a bit more complex, you _can_\noperate directly on the index, and the \"snapshot\" never needs to hit\nthe disk as such during your migration.\n\nHave a look at how the cvsimport script works for an example.\n\ncheers.\n\n\nmartin\n"}]}