Re: [PATCH v5 2/2] am: reload .gitattributes after patching it

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

 



On 2019-08-28 at 11:30:53, Johannes Schindelin wrote:
> > diff --git a/convert.c b/convert.c
> > index 94ff837649..0e6e9d2d75 100644
> > --- a/convert.c
> > +++ b/convert.c
> > @@ -8,6 +8,7 @@
> >  #include "pkt-line.h"
> >  #include "sub-process.h"
> >  #include "utf8.h"
> > +#include "ll-merge.h"
> >
> >  /*
> >   * convert.c - convert a file when checking it out and checking it in.
> > @@ -1293,10 +1294,11 @@ struct conv_attrs {
> >  	const char *working_tree_encoding; /* Supported encoding or default encoding if NULL */
> >  };
> >
> > +static struct attr_check *check;
> > +
> >  static void convert_attrs(const struct index_state *istate,
> >  			  struct conv_attrs *ca, const char *path)
> >  {
> > -	static struct attr_check *check;
> >  	struct attr_check_item *ccheck = NULL;
> >
> >  	if (!check) {
> 
> After this line:
> 
>                 check = attr_check_initl("crlf", "ident", "filter",
> 				"eol", "text", "working-tree-encoding",
> 				NULL);
> 		user_convert_tail = &user_convert;
> 		git_config(read_convert_config, NULL);
> 	}
> 
> I am a bit worried about `user_convert`: it seems never to be re-set.

Yeah, it looks like I'll need to reset that as well.  The only
consequence is that we leak a small amount of memory if there are filter
attributes, but it's better to avoid that leak if we can.

> Also, how thread-safe do we need `reset_parsed_attributes()` to be?

Since patch application isn't thread safe, it doesn't need to be
thread safe at all.  The original wasn't thread safe, either, since it
used a static variable without a mutex.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature


[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]

  Powered by Linux