On Tue, Aug 19, 2008 at 11:02 AM, David Tweed <david.tweed@xxxxxxxxx> wrote: > On Tue, Aug 19, 2008 at 3:54 PM, Avery Pennarun <apenwarr@xxxxxxxxx> 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 -- 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
