Hi,
On Tue, 19 Feb 2008, Daniel Barkalow wrote:
> On Tue, 19 Feb 2008, Johannes Schindelin wrote:
>
> > On Mon, 18 Feb 2008, Daniel Barkalow wrote:
> >
> > > diff --git a/revision.h b/revision.h
> > > index 8572315..e3559d0 100644
> > > --- a/revision.h
> > > +++ b/revision.h
> > > @@ -74,7 +74,7 @@ struct rev_info {
> > > struct log_info *loginfo;
> > > int nr, total;
> > > const char *mime_boundary;
> > > - const char *message_id;
> > > + char *message_id;
> > > const char *ref_message_id;
> > > const char *add_signoff;
> > > const char *extra_headers;
> >
> > Mini-nit: technically, ref_message_id should be "char *", too.
>
> I'd intended ref_message_id to just reference the string owned by a
> different message's message_id, but that doesn't really work with struct
> rev_info. I bet you'd like me to not leak memory out through
> ref_message_id, too. I think I want to see how the code to collect the
> set of commits in the series (for more capable generation of cover
> letter contents) goes before changing this either way.
>
> (It's incidentally kind of amusing that you managed to convey the way
> you thought the code should be designed, different from how I'd designed
> it, through a note on whether a struct field should be const or not.)
Hehe!
You're right in that the revision machinery needs some cleaning up. AFAIK
there is no method yet to release the memory allocated during one revision
walk (including the preparation).
And you're right that this should be done separately, so please kindly
accept my apologies while I retract my comment.
Ciao,
Dscho
-
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
