On Tue, Aug 19, 2008 at 4:47 AM, Pat LeSmithe <qed777@gmail.com> wrote:
quoted text
>
> 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

quoted text
> 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@gmail.com
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html