Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
Hi Michael: 2014-08-27 6:09 GMT+08:00 Junio C Hamano : > [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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
On Wed, Aug 27, 2014 at 09:38:09AM -0700, Junio C Hamano wrote: > > Makes sense. I think the v2 I sent[1] is OK, and as far as I was > > planning to take it for now (there were some other possible enhancements > > discussed, but I think those can happen in-tree if somebody feels like > > working on it). > > I queued it as-is; sent some comments. Thanks. Sorry, I hadn't seen your comments yet when I responded here. I'll send out a v3 in just a moment. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
Jeff King writes: > On Wed, Aug 27, 2014 at 08:31:51AM -0700, Junio C Hamano wrote: > >> > - jk/send-pack-many-refspecs; this is in pu, but I didn't see it in >> > "what's cooking". I'm concerned that the "ulimit" test gave you >> > trouble and you punted on it. :) >> >> It was picked up after the day's edition of "What's cooking" was >> written, or something, I think. > > Ah, sorry to nag, then. Not at all. Reminders are very much appreciated. >> > - "fast-export --anonymize"; I noticed you didn't pick this up at all. >> ... > Makes sense. I think the v2 I sent[1] is OK, and as far as I was > planning to take it for now (there were some other possible enhancements > discussed, but I think those can happen in-tree if somebody feels like > working on it). I queued it as-is; sent some comments. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
On Wed, Aug 27, 2014 at 08:31:51AM -0700, Junio C Hamano wrote: > > - jk/send-pack-many-refspecs; this is in pu, but I didn't see it in > > "what's cooking". I'm concerned that the "ulimit" test gave you > > trouble and you punted on it. :) > > It was picked up after the day's edition of "What's cooking" was > written, or something, I think. Ah, sorry to nag, then. > > - "fast-export --anonymize"; I noticed you didn't pick this up at all. > > I agree it has yet to prove its worth, but I wonder if it is worth > > shipping it (possibly labeled as experimental and not to be depended > > on) to get it in the hands of users. The intended use is getting bug > > reports from users, who are not always savvy enough to pick up (and > > possibly rebase) a patch from the list. I dunno. > > I was waiting for the topic to calm down a bit, without knowing if > there will or will not be a reroll with some low-hanging fruit > enhancement based on the discussion, to avoid an "oops, need to > replace the one I queued but haven't pushed out yet with the new > reroll". Makes sense. I think the v2 I sent[1] is OK, and as far as I was planning to take it for now (there were some other possible enhancements discussed, but I think those can happen in-tree if somebody feels like working on it). -Peff [1] http://article.gmane.org/gmane.comp.version-control.git/255646 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
Jeff King writes: > On Tue, Aug 26, 2014 at 03:09:34PM -0700, Junio C Hamano wrote: > >> -- >> [New Topics] > > There are a few misc topics of mine that I'd like to ping on: > > - jk/contrib-subtree-make-all; you picked up the topic, but it's not > in pu or "what's cooking". Just forgotten, I think? Correct, I think. Will requeue. > - jk/send-pack-many-refspecs; this is in pu, but I didn't see it in > "what's cooking". I'm concerned that the "ulimit" test gave you > trouble and you punted on it. :) It was picked up after the day's edition of "What's cooking" was written, or something, I think. > - "fast-export --anonymize"; I noticed you didn't pick this up at all. > I agree it has yet to prove its worth, but I wonder if it is worth > shipping it (possibly labeled as experimental and not to be depended > on) to get it in the hands of users. The intended use is getting bug > reports from users, who are not always savvy enough to pick up (and > possibly rebase) a patch from the list. I dunno. I was waiting for the topic to calm down a bit, without knowing if there will or will not be a reroll with some low-hanging fruit enhancement based on the discussion, to avoid an "oops, need to replace the one I queued but haven't pushed out yet with the new reroll". Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2014, #04; Tue, 26)
On Tue, Aug 26, 2014 at 03:09:34PM -0700, Junio C Hamano wrote: > -- > [New Topics] There are a few misc topics of mine that I'd like to ping on: - jk/contrib-subtree-make-all; you picked up the topic, but it's not in pu or "what's cooking". Just forgotten, I think? - jk/send-pack-many-refspecs; this is in pu, but I didn't see it in "what's cooking". I'm concerned that the "ulimit" test gave you trouble and you punted on it. :) - "fast-export --anonymize"; I noticed you didn't pick this up at all. I agree it has yet to prove its worth, but I wonder if it is worth shipping it (possibly labeled as experimental and not to be depended on) to get it in the hands of users. The intended use is getting bug reports from users, who are not always savvy enough to pick up (and possibly rebase) a patch from the list. I dunno. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
