Subject: Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)

From: Yue Lin Ho <[email-masked]>
Date: Wed, 27 Aug 2014 20:33:20 -0700 (PDT)

Hi ​Michael:

2014-08-27 6:09 GMT+08:00 Junio C Hamano <[email-masked]>:
​[snip]
> 
> --------------------------------------------------
> [Stalled]
> 
[snip]
> 
> * 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()
> 
>  Ejected from 'pu' to unclutter.
>  Expecting a reroll.
> 
​[snip]​
> 
> --------------------------------------------------
> [Cooking]
> 
​[snip]
> 
> * rs/strbuf-getcwd (2014-08-26) 10 commits
>   (merged to 'next' on 2014-08-26 at 11be0d6)
>  + use strbuf_add_absolute_path() to add absolute paths
>  + abspath: convert absolute_path() to strbuf
>  + use xgetcwd() to set $GIT_DIR
>  + use xgetcwd() to get the current directory or die
>  + wrapper: add xgetcwd()
>  + abspath: convert real_path_internal() to strbuf
>  + abspath: use strbuf_getcwd() to remember original working directory
>  + setup: convert setup_git_directory_gently_1 et al. to strbuf
>  + unix-sockets: use strbuf_getcwd()
>  + strbuf: add strbuf_getcwd()
>  (this branch is tangled with *nd/lock-paths-absolute*.)
> 
>  Originally merged to 'next' on 2014-08-18
> 
>  Reduce the use of fixed sized buffer passed to getcwd() calls
>  by introducing xgetcwd() helper.
> 
>  Will merge to 'master'.
> 
​[snip​]
> 
> --------------------------------------------------
> [Discarded]
​[snip​]
> 
> * nd/lock-paths-absolute (2014-08-01) 3 commits
>  . lockfile.c: store absolute path
>  . lockfile.c: remove PATH_MAX limit in resolve_symlink()
>  . lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)
> 
>  Will drop and ask ​​Michael to possibly cooperate and merge with
> *mh/lockfile*.
> 

​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)
Do you have any plan on it?

Thank you.​ ^_^

​Yue Lin Ho​

--
View this message in context: http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-04-Tue-26-tp7617534p7617655.html
Sent from the git mailing list archive at Nabble.com.