Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Wed, Jun 1, 2016 at 12:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: >> >>> We need this later to avoid double locking a worktree, or unlocking one >>> when it's not even locked. >> >> Shouldn't this be done lazily? >> >> If a user is working in worktree B and is not doing anything funky, >> she would not care why worktree A and C are locked, even though she >> might care the fact that they are locked. > > You and Eric will have to settle this. It was done lazily in v2, but > Eric convinced me this lock thing will be needed for many worktree > commands (list, lock, unlock, move, remove and maybe even prune) that > it makes more sense to make it a field in struct worktree instead. For > a dozen worktrees, it does not really matter. But get_worktrees() is > also being used outside "git worktree" command, some of those new > callers may get picky. Maybe a common ground is adding a flag to > get_worktrees() to select what fields to be filled? NO. When you tell callers that they have DIRECT access to fields, then they need to keep track of what flag they (or their callers) passed when get_worktrees() was called, which is a road to insanity. By "lazily", I didn't mean "do not have a field there; instead every time read from the file and return the value". A lazy interface would give a function to read the "is it locked and if so why" information as the sole interface, whose implementation would _not_ do the reading when a worktree structure is instantiated, the first call would do the reading, and it is up to the implementation to cache the result of that first call's work in the structure and answer the subsequent calls from the cache, or do the same reading for subsequent calls. -- 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