On Tue, Aug 19, 2008 at 4:47 AM, Pat LeSmithe <qed777@xxxxxxxxx> wrote: > > Hello, > > Is it possible to enable git to automatically and continuously "softly" > commit or stage *all* changes to a [subset of] files in a repository, > without my intervention, as they happen? Perhaps via a daemon which > monitors the disk for explicit file-saving? > > Of course, I would still be able to perform explicit commits (with > descriptive comments) and other git commands, in which case there > probably should be smart handling of the recent soft history. For > example, it could simply be discarded. > > I understand that I could simply remember to commit and/or branch early > and often. But given that changes by an individual on a given branch > are well-ordered by time, and that the "continuous" operation may be > cheap in many situations, a "live" journal could be useful. What I do is have a script that runs every 10 minutes that stages files to the index and then, using the low-level git plumbing, creates tree and commit objects on a side branch "temp". With this you can easily commit to the main branch "main" PROVIDING you are commiting a superset of the changes you're storing to the side-branch. If you wanted to specify exactly the things in your "main" commit I suspect you'd have to do some kind of "git-reset --mixed" to rollback the side-branch state. One thing to be aware of if you do this is that git expects your index file to be describing what you intend to do on the current branch you are on (in, eg, git status), but by doing it this way you'll get output that acts as if you've staged things for your "main" branch. This isn't a problem for me as my (idiosyncratic) usage is to have commits on my main branch every hour via cron anyway. If you're particularly interested in this approach I can either try and explain the commands I use in email or you can try and extract them from my python script chronoversion: http://www.personal.rdg.ac.uk/~sis05dst/chronoversion.tgz > Perhaps a better term is branch-aware undo or git with microstructure. I actually find I don't use the temp branch to actually undo stuff (partly because I'm not even trying to keep a neat history so I do modifications primarily via new commits). Instead, I sometimes modify and extend my research code in a way that I do maybe an hour or so of new code and refactoring before it's in a state to actually run again. If when it finally runs something's broken I find it very helpful to be able to look backwards to see what changes I've made as the problem either jumps out or I know where to start experimenting. One problem with chronological backups is that they often don't compile/run so you can't bisect on them. One thing I have been trying to figure out is if there's an easy way to modify my build system so that it makes a commit approximately every 10 minutes but just after a successful compile. However, that looks to be a bit too complex and error prone for the moment. -- cheers, dave tweed__________________________ david.tweed@xxxxxxxxx Rm 124, School of Systems Engineering, University of Reading. "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot -- 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
