On Tue, Jul 14, 2015 at 4:53 PM, Michael J Gruber <g...@drmicha.warpmail.net> wrote: > Related to that, I'm interested in "worktree list", and I'm wondering > how many more worktree commands we foresee, and therefore how much > refactoring should be done: Currently, the parsing of the contents of > .../worktrees/ into worktree information is done right in prune-spcefic > functions. They will have to be refactored. The following questions come > to my mind: > > - Is a simple funtion refactoring enough, or should we introduce a > worktree struct (and a list of such)? > - Should each command do its own looping, or do we want > for_each_worktree() with a callback?
fhe for_each_xxx sounds like a good pattern to reuse. > - Is a fixed output format for "list"[1] enough, or do we want something > like for-each-ref or log formats (GSOC project...)? We could stick to a fixed format for "worktree list" then introduce --format later if one output does not please everybody. > - Finally: Who will be stepping on whose toes doing this? I'm happy to step aside and let people implement it. I still have plenty of hanging topics to finish up :( -- Duy -- 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
