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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Paul Tan <pyokagan@xxxxxxxxx> 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.

> (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).
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]