On Wed, Jun 24, 2015 at 11:59 PM, Junio C Hamano <gits...@pobox.com> wrote: > Paul Tan <pyoka...@gmail.com> writes: > >> 3. I'm over-thinking this and you just want the "struct strbufs" in the >> struct am_state to be switched to "char*"s? > > Yes, everybody interacts with am_state, and these fields are > supposed to be constant during the processing of each patch input > message; they should be simple strings, not strbufs, to make sure if > anybody _does_ muck with them in-place, that would be very visible. > The helpers to initialize them are free to use strbuf API to prepare > these simple string fields, of course.
OK. I've implemented it on my end. >> (On a somewhat related thought, currently we do write_file() all over >> the place, which is really ugly. I'm leaning heavily on introducing an >> am_save() function, for "I don't care how it is done but just update the >> contents of the am state directory so that it matches the contents of >> the struct am_state". > > Sure; the scripted Porcelain may have done "echo here, echo there" > instead of "concatenate into a $var and then 'echo $var' at end" as > that is more natural way to program in that environment. You are > doing this in C and "prepare the thing in-core and write it all at > the point to snapshot" may well be the more natural way to program. > > As long as a process that stops in the middle does not leave on-disk > state inconsistent, batching would be fine. For example, you may > apply and commit two (or more) patches without updating the on-disk > state as you do not see need to give control back to the user > (i.e. they applied cleanly) and then write out the on-disk state > with .next incremented by two (or more) before giving the control > back could be a valid optimization (take this example with a grain > of salt, though; I haven't thought too deeply about what should > happen if you Ctrl-C the process in the middle). Right, I briefly wondered if we could hold off writing the am_state to disk as much as possible, and only write to disk when we are about to terminate. This would involve installing an atexit() and SIGTERM signal handler, but I haven't thought too deeply about that. Anyway, moving all the "writing am_state to disk" logic to a central function am_save() would be a good immediate step, I think, so I've implemented it on my end. Thanks, Paul -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
