Re: [PATCH/WIP v3 07/31] am: extract patch, message and authorship with git-mailinfo

[Paul Tan <pyokagan@gmail.com>]

On Wed, Jun 24, 2015 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Paul Tan <pyokagan@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