{"thread":{"id":"15079","subject":"Dumb \"continuous\" commit dumb question","startedAt":"2008-08-19T03:47:47Z","lastAt":"2008-08-19T17:55:20Z","messageCount":9,"participants":["Pat LeSmithe","Marcus Griep","David Tweed","Shawn O. Pearce","Avery Pennarun","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"87641","messageId":"48AA4263.8090606@gmail.com","threadId":"15079","inReplyTo":null,"subject":"Dumb \"continuous\" commit dumb question","fromName":"Pat LeSmithe","fromEmail":"qed777@gmail.com","sentAt":"2008-08-19T03:47:47Z","receivedAt":"2008-08-19T03:47:47Z","isPatch":false,"sender":{"key":"qed777@gmail.com","avatar":null},"body":"\nHello,\n\nIs it possible to enable git to automatically and continuously \"softly\"\ncommit or stage *all* changes to a [subset of] files in a repository,\nwithout my intervention, as they happen? Perhaps via a daemon which\nmonitors the disk for explicit file-saving?\n\nOf course, I would still be able to perform explicit commits (with\ndescriptive comments) and other git commands, in which case there\nprobably should be smart handling of the recent soft history. For\nexample, it could simply be discarded.\n\nI understand that I could simply remember to commit and/or branch early\nand often. But given that changes by an individual on a given branch\nare well-ordered by time, and that the \"continuous\" operation may be\ncheap in many situations, a \"live\" journal could be useful.\n\nPerhaps a better term is branch-aware undo or git with microstructure.\n\nSorry if this is old stuff or plain crap.\n\nThanks.\n\nSincerely,\nPat LeSmith\n"},{"id":"87643","messageId":"48AA4873.4040107@gmail.com","threadId":"15079","inReplyTo":"48AA4263.8090606@gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"Marcus Griep","fromEmail":"neoeinstein@gmail.com","sentAt":"2008-08-19T04:13:39Z","receivedAt":"2008-08-19T04:13:39Z","isPatch":false,"sender":{"key":"neoeinstein@gmail.com","avatar":"https://gravatar.com/avatar/75d467077b37e56699d408fb97545e9a92a2907ff1feea4ba3a4b861f7cb7af4?d=mp&s=160"},"body":"Pat LeSmithe wrote:\n> Hello,\n> \n> Is it possible to enable git to automatically and continuously \"softly\"\n> commit or stage *all* changes to a [subset of] files in a repository,\n> without my intervention, as they happen? Perhaps via a daemon which\n> monitors the disk for explicit file-saving?\n\nPerhaps with a cron job running a script every minute or so. You'd want\nto verify that changes actually took place before attempting a commit.\nAlso, what log messages would you be providing? Log messages can be\nvery important to the context of a change and the ability to later find\nthem.\n\nIf you're using a specific application, such as a Wiki, it may work\nnicely, as log messages can be easily gleaned, and many offer post-edit\nhooks that you could use to invoke git.\n\n> Of course, I would still be able to perform explicit commits (with\n> descriptive comments) and other git commands, in which case there\n> probably should be smart handling of the recent soft history. For\n> example, it could simply be discarded.\n\nYou may want to use StGit as that may allow you to make such lightweight\ncommits easily while still allowing reordering, etc., though I am not\nfamiliar with that application porcelain.\n\n> I understand that I could simply remember to commit and/or branch early\n> and often. But given that changes by an individual on a given branch\n> are well-ordered by time, and that the \"continuous\" operation may be\n> cheap in many situations, a \"live\" journal could be useful.\n> \n> Perhaps a better term is branch-aware undo or git with microstructure.\n\nObviously, my final caution is that while this is possible with some\nconfiguration, you may lose valuable \"signal\" information in the \"noise\" of\ncommits that such a continuous operation might incur. This low SNR may\nmake it more difficult to find and revert changes you didn't actually want\nto happen or to glean a meaningful history of your working tree.\n\nWhile in the operable borders of Git, it's outside the normal usage patterns.\nIf you have success, let us know how it worked for you.\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n\n"},{"id":"87697","messageId":"e1dab3980808190732i303f06ach50e36e13a624bd23@mail.gmail.com","threadId":"15079","inReplyTo":"48AA4263.8090606@gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-19T14:32:58Z","receivedAt":"2008-08-19T14:32:58Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Tue, Aug 19, 2008 at 4:47 AM, Pat LeSmithe wrote:\n>\n> Hello,\n>\n> Is it possible to enable git to automatically and continuously \"softly\"\n> commit or stage *all* changes to a [subset of] files in a repository,\n> without my intervention, as they happen? Perhaps via a daemon which\n> monitors the disk for explicit file-saving?\n>\n> Of course, I would still be able to perform explicit commits (with\n> descriptive comments) and other git commands, in which case there\n> probably should be smart handling of the recent soft history. For\n> example, it could simply be discarded.\n>\n> I understand that I could simply remember to commit and/or branch early\n> and often. But given that changes by an individual on a given branch\n> are well-ordered by time, and that the \"continuous\" operation may be\n> cheap in many situations, a \"live\" journal could be useful.\n\nWhat I do is have a script that runs every 10 minutes that stages\nfiles to the index and then, using the low-level git plumbing, creates\ntree and commit objects on a side branch \"temp\". With this you can\neasily commit to the main branch \"main\" PROVIDING you are commiting a\nsuperset of the changes you're storing to the side-branch. If you\nwanted to specify exactly the things in your \"main\" commit I suspect\nyou'd have to do some kind of \"git-reset --mixed\" to rollback the\nside-branch state. One thing to be aware of if you do this is that git\nexpects your index file to be describing what you intend to do on the\ncurrent branch you are on (in, eg, git status), but by doing it this\nway you'll get output that acts as if you've staged things for your\n\"main\" branch.\n\nThis isn't a problem for me as my (idiosyncratic) usage is to have\ncommits on my main branch every hour via cron anyway.\n\nIf you're particularly interested in this approach I can either try\nand explain the commands I use in email or you can try and extract\nthem from my python script chronoversion:\n\nhttp://www.personal.rdg.ac.uk/~sis05dst/chronoversion.tgz\n\n> Perhaps a better term is branch-aware undo or git with microstructure.\n\nI actually find I don't use the temp branch to actually undo stuff\n(partly because I'm not even trying to keep a neat history so I do\nmodifications primarily via new commits). Instead, I sometimes modify\nand extend my research code in a way that I do maybe an hour or so of\nnew code and refactoring before it's in a state to actually run again.\nIf when it finally runs something's broken I find it very helpful to\nbe able to look backwards to see what changes I've made as the problem\neither jumps out or I know where to start experimenting.\n\nOne problem with chronological backups is that they often don't\ncompile/run so you can't bisect on them. One thing I have been trying\nto figure out is if there's an easy way to modify my build system so\nthat it makes a commit approximately every 10 minutes but just after a\nsuccessful compile. However, that looks to be a bit too complex and\nerror prone for the moment.\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"87700","messageId":"20080819144853.GD20947@spearce.org","threadId":"15079","inReplyTo":"e1dab3980808190732i303f06ach50e36e13a624bd23@mail.gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-19T14:48:53Z","receivedAt":"2008-08-19T14:48:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Tweed wrote:\n> What I do is have a script that runs every 10 minutes that stages\n> files to the index and then, using the low-level git plumbing, creates\n> tree and commit objects on a side branch \"temp\". With this you can\n> easily commit to the main branch \"main\" PROVIDING you are commiting a\n> superset of the changes you're storing to the side-branch.\n\nHave the script use \"export GIT_INDEX_FILE=.git/temp-branch-index\"\nso that it stages changes into an index which isn't the main one,\nand thus has no impact on the main branch. Thus you can still\ncommit a subset of the temp branch at any time.\n\nActually you can do something like this:\n\n\texport GIT_INDEX_FILE=.git/temp-branch-index &&\n\tcp .git/index $GIT_INDEX_FILE &&\n\tgit add . &&\n\tgit add -u &&\n\tgit update-ref refs/heads/temp $(date | git commit-tree $(git write-tree) -p temp)\n\n;-)\n\n-- \nShawn.\n"},{"id":"87703","messageId":"32541b130808190754l43f053abnc4e3c5c064d6ade7@mail.gmail.com","threadId":"15079","inReplyTo":"e1dab3980808190732i303f06ach50e36e13a624bd23@mail.gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-19T14:54:58Z","receivedAt":"2008-08-19T14:54:58Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Aug 19, 2008 at 10:32 AM, David Tweed wrote:\n> One problem with chronological backups is that they often don't\n> compile/run so you can't bisect on them. One thing I have been trying\n> to figure out is if there's an easy way to modify my build system so\n> that it makes a commit approximately every 10 minutes but just after a\n> successful compile. However, that looks to be a bit too complex and\n> error prone for the moment.\n\nYou could just have a makefile rule or bash alias that does something\nlike \"make && git commit -a -m temp\". Then remember to always run\nthat instead of 'make' when you're building.\n\nOf course, committing on a side branch and not screwing with the index\nwould be much less intrusive.\n\nAvery\n"},{"id":"87706","messageId":"e1dab3980808190802r202aadc0p2cf8431f645354e3@mail.gmail.com","threadId":"15079","inReplyTo":"32541b130808190754l43f053abnc4e3c5c064d6ade7@mail.gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-19T15:02:54Z","receivedAt":"2008-08-19T15:02:54Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Tue, Aug 19, 2008 at 3:54 PM, Avery Pennarun wrote:\n> You could just have a makefile rule or bash alias that does something\n> like \"make && git commit -a -m temp\". Then remember to always run\n> that instead of 'make' when you're building.\n\nAs ever, I wanna do something more deviant than that :-) . The idea is\nto take a snapshot (if any tracked file has changed) roughly every ten\nminutes. If there happens to have been a successful compile around\nthat time (+/- 1 minute say), grab the snapshot (including detecting\npotential newly created files) then. But if there hasn't, I still want\na snapshot roughly on that 10 minute interval. I could try doing\nsomething like \"git reset --soft HEAD~1 && git commit -a\" if a make\nsucceeds within 1 minute, on a strictly chronological snapshot but\nscripted resets make me a bit nervous.\n\nIt's not hyper-important, just something I'm thinking about.\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"87708","messageId":"32541b130808190808g79bb53a1l9ea7f2ea4c1e5ed3@mail.gmail.com","threadId":"15079","inReplyTo":"e1dab3980808190802r202aadc0p2cf8431f645354e3@mail.gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-19T15:08:19Z","receivedAt":"2008-08-19T15:08:19Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Aug 19, 2008 at 11:02 AM, David Tweed wrote:\n> On Tue, Aug 19, 2008 at 3:54 PM, Avery Pennarun wrote:\n>> You could just have a makefile rule or bash alias that does something\n>> like \"make && git commit -a -m temp\". Then remember to always run\n>> that instead of 'make' when you're building.\n>\n> As ever, I wanna do something more deviant than that :-) . The idea is\n> to take a snapshot (if any tracked file has changed) roughly every ten\n> minutes. If there happens to have been a successful compile around\n> that time (+/- 1 minute say), grab the snapshot (including detecting\n> potential newly created files) then. But if there hasn't, I still want\n> a snapshot roughly on that 10 minute interval. I could try doing\n> something like \"git reset --soft HEAD~1 && git commit -a\" if a make\n> succeeds within 1 minute, on a strictly chronological snapshot but\n> scripted resets make me a bit nervous.\n>\n> It's not hyper-important, just something I'm thinking about.\n\nDoing the 10-minute snapshot doesn't preclude the on-make snapshot.\nJust commit at *both* times. But commiting \"around the time there was\na successful build\" is kind of pointless since you might change a file\ntwo seconds later. (Or maybe only I'm that idiosyncratic. :))\n\nShawn's GIT_INDEX_FILE script seems like a good place to start. If it\nwere me, I'd use *two* branches here: one for every time I build, and\none for the periodic commits. Then the build branch would always be\nbisectable, and the periodic branch would always have up-to-date data.\n Commits on the periodic branch would use *both* branch heads as\nparents, so you'd be able to easily see and diff the full history.\n\nHave fun,\n\nAvery\n"},{"id":"87709","messageId":"e1dab3980808190821l2d859bf0p4986260b1fe1ab65@mail.gmail.com","threadId":"15079","inReplyTo":"32541b130808190808g79bb53a1l9ea7f2ea4c1e5ed3@mail.gmail.com","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-19T15:21:24Z","receivedAt":"2008-08-19T15:21:24Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Tue, Aug 19, 2008 at 4:08 PM, Avery Pennarun wrote:\n> Doing the 10-minute snapshot doesn't preclude the on-make snapshot.\n> Just commit at *both* times. But commiting \"around the time there was\n> a successful build\" is kind of pointless since you might change a file\n> two seconds later. (Or maybe only I'm that idiosyncratic. :))\n\nI think I was unclear: the only point about the \"roughly\" was to\nemphasize that being dead-on 10 minutes line doesn't matter from the\nchronological aspect. Clearly you want to start the commit processes\nas soon as a successful compile you decide is worth keeping completes.\n(Actually, looking at the commit times on my cron-initiated commits\nthe time is mostly 1 or 2 seconds past the 10 minute boundary already,\nso there's an already up to 2 seconds for my \"detect new files\" script\nto scan the directories.)\n\n> Shawn's GIT_INDEX_FILE script seems like a good place to start. If it\n> were me, I'd use *two* branches here: one for every time I build, and\n> one for the periodic commits. Then the build branch would always be\n> bisectable, and the periodic branch would always have up-to-date data.\n> Commits on the periodic branch would use *both* branch heads as\n> parents, so you'd be able to easily see and diff the full history.\n\nI think you mean 3 branches: successful compile, short term history\n(every 10 minutes) and long-term archival history (every hour). I\nalready have the last two, although not in as optimal a manner as\nShawn suggested, and wipe the short term history every week or so.\n\nInteresting idea. I'll ponder it.\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"87720","messageId":"20080819175520.GB10142@coredump.intra.peff.net","threadId":"15079","inReplyTo":"20080819144853.GD20947@spearce.org","subject":"Re: Dumb \"continuous\" commit dumb question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-19T17:55:20Z","receivedAt":"2008-08-19T17:55:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 19, 2008 at 07:48:53AM -0700, Shawn O. Pearce wrote:\n\n> Actually you can do something like this:\n> \n> \texport GIT_INDEX_FILE=.git/temp-branch-index &&\n> \tcp .git/index $GIT_INDEX_FILE &&\n> \tgit add . &&\n> \tgit add -u &&\n> \tgit update-ref refs/heads/temp $(date | git commit-tree $(git write-tree) -p temp)\n\nGet with the times, Shawn. It's \"git add -A\" now. ;)\n\n-Peff\n"}]}