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. -- 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