On Thu, Jun 25, 2015 at 12:36 AM, Johannes Schindelin
johannes.schinde...@gmx.de 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
Paul Tan pyoka...@gmail.com 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?
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
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
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
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 a
Hi Paul,
On 2015-06-19 18:15, Paul Tan wrote:
On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano gits...@pobox.com 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
On Fri, Jun 19, 2015 at 5:10 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
+ /* commit message and metadata */
+ struct strbuf author_name;
+ struct strbuf author_email;
+ struct strbuf author_date;
+ struct strbuf msg;
Same comment as
On Fri, Jun 19, 2015 at 11:09 PM, Junio C Hamano gits...@pobox.com 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
Paul Tan pyoka...@gmail.com writes:
On Fri, Jun 19, 2015 at 5:10 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
+ /* commit message and metadata */
+ struct strbuf author_name;
+ struct strbuf author_email;
+ struct strbuf author_date;
+
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
Paul Tan pyoka...@gmail.com 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
12 matches
Mail list logo
