{"action":"created","issue":{"url":"https://api.github.com/repos/github/git-lfs/issues/1401","repository_url":"https://api.github.com/repos/github/git-lfs","labels_url":"https://api.github.com/repos/github/git-lfs/issues/1401/labels{/name}","comments_url":"https://api.github.com/repos/github/git-lfs/issues/1401/comments","events_url":"https://api.github.com/repos/github/git-lfs/issues/1401/events","html_url":"https://github.com/github/git-lfs/issues/1401","id":167998074,"number":1401,"title":"Feature request: \"lfs worktree add\" command that's similar to \"lfs clone\"","user":{"login":"dakotahawkins","id":638578,"avatar_url":"https://avatars.githubusercontent.com/u/638578?v=3","gravatar_id":"","url":"https://api.github.com/users/dakotahawkins","html_url":"https://github.com/dakotahawkins","followers_url":"https://api.github.com/users/dakotahawkins/followers","following_url":"https://api.github.com/users/dakotahawkins/following{/other_user}","gists_url":"https://api.github.com/users/dakotahawkins/gists{/gist_id}","starred_url":"https://api.github.com/users/dakotahawkins/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dakotahawkins/subscriptions","organizations_url":"https://api.github.com/users/dakotahawkins/orgs","repos_url":"https://api.github.com/users/dakotahawkins/repos","events_url":"https://api.github.com/users/dakotahawkins/events{/privacy}","received_events_url":"https://api.github.com/users/dakotahawkins/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2016-07-28T02:04:59Z","updated_at":"2016-07-29T09:36:23Z","closed_at":null,"body":"Since using worktrees is my MO, and since it's a suggested workaround for #766, It would be great to have an explicit command that does as much lfs work as possible in bulk when you want to add a new worktree.\r\n\r\nFrom recent experience, `git worktree add` took more time than a `git lfs clone` plus a `git lfs fetch --all` so I suspect there are savings to be had there that are very similar to the savings you're getting from `git lfs clone` for cloning a repo.\r\n\r\nIn truth, it probably needs to be little more than a wrapper around `worktree add` (sans filters), `cd <worktree dir>`, and `lfs pull`."},"comment":{"url":"https://api.github.com/repos/github/git-lfs/issues/comments/236137542","html_url":"https://github.com/github/git-lfs/issues/1401#issuecomment-236137542","issue_url":"https://api.github.com/repos/github/git-lfs/issues/1401","id":236137542,"user":{"login":"sinbad","id":142735,"avatar_url":"https://avatars.githubusercontent.com/u/142735?v=3","gravatar_id":"","url":"https://api.github.com/users/sinbad","html_url":"https://github.com/sinbad","followers_url":"https://api.github.com/users/sinbad/followers","following_url":"https://api.github.com/users/sinbad/following{/other_user}","gists_url":"https://api.github.com/users/sinbad/gists{/gist_id}","starred_url":"https://api.github.com/users/sinbad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sinbad/subscriptions","organizations_url":"https://api.github.com/users/sinbad/orgs","repos_url":"https://api.github.com/users/sinbad/repos","events_url":"https://api.github.com/users/sinbad/events{/privacy}","received_events_url":"https://api.github.com/users/sinbad/received_events","type":"User","site_admin":false},"created_at":"2016-07-29T09:36:22Z","updated_at":"2016-07-29T09:36:22Z","body":"> I'd add a more generic concern that all of that seems like it will require locking the index for a relatively long time while a bunch of various operations must all succeed (file I/O, network transfers, etc) in order to wind up in a good state.\r\n\r\nI don't think so - as I say you can write the pointer data to the working copy when the filter request initially comes through, so if the process is halted in the middle the state is stable & clean - the clean filter does a passthrough on pointer files in the working copy, not only because of this kind of problem but also because you can exclude folders you don't want actual LFS content for.\r\n\r\nWhen it comes to updating the index at the end it would be the same as `git lfs checkout`.\r\n\r\n> Does LFS do any kind of global safety operation with the index (like copy it to a temp location and copy it back if part of something that involves index-writing fails)? At least that way it might have failed, but your index is at least back where it started.\r\n\r\nSince we only ever update the index via `git update-index` we don't have to. Obviously any future direct writing to the index for performance will need to be a lot more careful."}}
{"actor":{"display_login":"sinbad"}}