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

[Yue Lin Ho <yuelinho777@gmail.com>]

Hi Michael:

> On 08/04/2014 03:13 AM, Duy Nguyen wrote:
>
>> On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen <[hidden email]>
>> 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" 

​I am tracing the lock path issue.
(http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using-different-worktree-td7615300.html)

and I see mh/lockfile part in 
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Sep-2014-01-Tue-2-td7617955.html
as following:

* mh/lockfile (2014-04-15) 25 commits
 . trim_last_path_elm(): replace last_path_elm()
 . resolve_symlink(): take a strbuf parameter
 . resolve_symlink(): use a strbuf for internal scratch space
 . change lock_file::filename into a strbuf
 . commit_lock_file(): use a strbuf to manage temporary space
 . try_merge_strategy(): use a statically-allocated lock_file object
 . try_merge_strategy(): remove redundant lock_file allocation
 . struct lock_file: declare some fields volatile
 . lockfile: avoid transitory invalid states
 . commit_lock_file(): die() if called for unlocked lockfile object
 . commit_lock_file(): inline temporary variable
 . remove_lock_file(): call rollback_lock_file()
 . lock_file(): exit early if lockfile cannot be opened
 . write_packed_entry_fn(): convert cb_data into a (const int *)
 . prepare_index(): declare return value to be (const char *)
 . delete_ref_loose(): don't muck around in the lock_file's filename
 . cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN
 . lockfile.c: document the various states of lock_file objects
 . lock_file(): always add lock_file object to lock_file_list
 . hold_lock_file_for_append(): release lock on errors
 . lockfile: unlock file if lockfile permissions cannot be adjusted
 . rollback_lock_file(): set fd to -1
 . rollback_lock_file(): do not clear filename redundantly
 . api-lockfile: expand the documentation
 . unable_to_lock_die(): rename function from unable_to_lock_index_die()

 Expecting a reroll.

So, do you have any plan about mh/lockfile and the lock path issue?

Thank you.​ ^_^

Yue Lin Ho



--
View this message in context: http://git.661346.n2.nabble.com/PATCH-Make-locked-paths-absolute-when-current-directory-is-changed-tp7615398p7617967.html
Sent from the git mailing list archive at Nabble.com.