Re: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)

[Michael Haggerty <mhagger@alum.mit.edu>]

On 08/04/2014 03:13 AM, Duy Nguyen wrote:
> On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen <tboegi@web.de> wrote:
> [...]
>> My first impression reading this patch was to rename
>> clear_filename() into free_and_clear_filename() or better free_filename(),
>> but I never pressed the send button ;-)
>>
>> Reading the discussion above makes me wonder if lk->filename may be replaced
>> by a strbuf
>> some day, and in this case clear_filename() will become reset_filenmae() ?
> 
> I didn't realize Mike is making a lot more changes in lockfile.c, part
> of that is converting lk->filename to use strbuf [1]. Perhaps I should
> just withdraw this series, wait until Mike's series is merged, then
> redo 3/3 on top. Or Mike could just take 3/3 in as part of his series.
> 
> [1] http://thread.gmane.org/gmane.comp.version-control.git/246222/focus=246232

I've neglected my patch series for ages (sorry!)  The last round of
review pointed out a couple of places where lock_file objects were still
being left in undefined states, and since then it also bit-rotted.

Over the past few days I re-rolled the patch series and fixed some more
code paths.  I still want to check it over before submitting it to the
list, but if you are interested the current version is here [1].

Duy, I'll try to look at your patches, but probably won't get to it
until next week when I return from vacation.

Michael

[1] https://github.com/mhagger/git branch "lock-correctness"

-- 
Michael Haggerty
mhagger@alum.mit.edu