Re: Dumb "continuous" commit dumb question

From: Avery Pennarun <apenwarr@gmail.com>
Date: Aug 19, 2008, 15:08 UTC
Message-ID: <32541b130808190808g79bb53a1l9ea7f2ea4c1e5ed3@mail.gmail.com>
In-Reply-To: <e1dab3980808190802r202aadc0p2cf8431f645354e3@mail.gmail.com>

On Tue, Aug 19, 2008 at 11:02 AM, David Tweed <david.tweed@gmail.com> wrote:

Show 16 quoted lines

> On Tue, Aug 19, 2008 at 3:54 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> You could just have a makefile rule or bash alias that does something
>> like "make && git commit -a -m temp".  Then remember to always run
>> that instead of 'make' when you're building.
>
> As ever, I wanna do something more deviant than that :-) . The idea is
> to take a snapshot (if any tracked file has changed) roughly every ten
> minutes. If there happens to have been a successful compile around
> that time (+/- 1 minute say), grab the snapshot (including detecting
> potential newly created files) then. But if there hasn't, I still want
> a snapshot roughly on that 10 minute interval. I could try doing
> something like "git reset --soft HEAD~1 && git commit -a" if a make
> succeeds within 1 minute, on a strictly chronological snapshot but
> scripted resets make me a bit nervous.
>
> It's not hyper-important, just something I'm thinking about.

Doing the 10-minute snapshot doesn't preclude the on-make snapshot. Just commit at *both* times. But commiting "around the time there was a successful build" is kind of pointless since you might change a file two seconds later. (Or maybe only I'm that idiosyncratic. :))

Shawn's GIT_INDEX_FILE script seems like a good place to start.  If it
were me, I'd use *two* branches here: one for every time I build, and
one for the periodic commits.  Then the build branch would always be
bisectable, and the periodic branch would always have up-to-date data.
 Commits on the periodic branch would use *both* branch heads as
parents, so you'd be able to easily see and diff the full history.

Have fun,

Avery