Paul Tan writes:
> OK, I'll try that out. Looks like this now:
>
> static char *read_shell_var(FILE *fp, const char *key)
> {
> ...
> str = sq_dequote(sb.buf);
> if (!str)
> return NULL;
You are unlikely to get !str, but if it does, you leak sb here,
don't you?
> return strb
On Thu, Jun 25, 2015 at 12:36 AM, Johannes Schindelin
wrote:
> On 2015-06-18 13:25, Paul Tan wrote:
>> diff --git a/builtin/am.c b/builtin/am.c
>> index 7b97ea8..d6434e4 100644
>> --- a/builtin/am.c
>> +++ b/builtin/am.c
>> @@ -94,6 +126,105 @@ static int read_state_file(struct strbuf *sb,
>> cons
On Wed, Jun 24, 2015 at 11:59 PM, Junio C Hamano wrote:
> Paul Tan 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 duri
Hi Paul,
On 2015-06-18 13:25, Paul Tan wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index 7b97ea8..d6434e4 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -94,6 +126,105 @@ static int read_state_file(struct strbuf *sb,
> const char *file, size_t hint, int
> }
>
> /**
> + * Reads
Paul Tan 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 simpl
Okay, let's focus only on the API design issues.
For the record, I'm not completely satisfied with the current code
organization and API, however I don't have really good ideas at hand to
improve it, so any ideas with examples would be appreciated.
On Fri, Jun 19, 2015 at 09:13:00AM -0700, Junio
Hi Paul,
On 2015-06-19 18:15, Paul Tan wrote:
> On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano wrote:
>
>> The primary thing I care about is to discourage callers of the API element
>> am_state from touching these fields with strbuf functions. If it is char *
>> then
>> the would think twice
On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano wrote:
> You do realize that strbuf internally does alloc/free so as a solution to
> fragmentation issue you are at the mercy of the same alloc/free, don't you?
Yes, of course, but it has the "alloc" variable to keep track of the
size of the alloca
Paul Tan writes:
> On Fri, Jun 19, 2015 at 5:10 AM, Junio C Hamano wrote:
>> Paul Tan writes:
>>
>>> + /* commit message and metadata */
>>> + struct strbuf author_name;
>>> + struct strbuf author_email;
>>> + struct strbuf author_date;
>>> + struct strbuf msg;
>>
>> Same co
On Fri, Jun 19, 2015 at 5:10 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> + /* commit message and metadata */
>> + struct strbuf author_name;
>> + struct strbuf author_email;
>> + struct strbuf author_date;
>> + struct strbuf msg;
>
> Same comment as "dir" in the earlier
Paul Tan writes:
> + /* commit message and metadata */
> + struct strbuf author_name;
> + struct strbuf author_email;
> + struct strbuf author_date;
> + struct strbuf msg;
Same comment as "dir" in the earlier patch applies to these. If the
fields are read or computed and the
For the purpose of applying the patch and committing the results,
implement extracting the patch data, commit message and authorship from
an e-mail message using git-mailinfo.
git-mailinfo is run as a separate process, but ideally in the future,
we should be be able to access its functionality dir
12 matches
Mail list logo
