On Sat, Jul 11, 2015 at 9:20 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Sat, Jul 11, 2015 at 7:05 AM, Eric Sunshine <sunsh...@sunshineco.com> > wrote: >> The plan is eventually to populate the new worktree via "git reset >> --hard" rather than "git checkout". Thus, rather than piggybacking on >> git-checkout's -b/-B ability to create a new branch at checkout time, >> git-worktree will need to do so itself. >> >> Signed-off-by: Eric Sunshine <sunsh...@sunshineco.com> >> --- >> >> I considered calling branch-related API, such as create_branch(), >> directly, however, git-branch provides extra value which may be useful >> in the future (such as when --track and --orphan get added to >> git-worktree), so it seemed wise to re-use git-branch's implementation >> rather than duplicating the functionality. If this proves the wrong >> choice, then the series can either be re-rolled or follow-on patches can >> address the issue. > > I don't know much about ref handling code (especially after the big > transaction update), so i may be wrong, but do we need to invalidate > some caches in refs.c after this? The same for update-ref in the other > patch. We may need to re-read the index after 'reset --hard' too if we > ever need to do touch the index after that (unlikely though in the > case of 'worktree add')
I'm not sure I understand. Are you talking about this patch's implementation or a possible future change which uses the C API rather than git-branch? If you're talking about this patch, then I don't think we need to do anything more, as the "git branch" and "git reset --hard" invocations are separate process invocations which shouldn't affect the current worktree or the current "git worktree add" process. If you're talking about a future patch switching over to the C API, and avoiding run_command(), then perhaps (but I haven't investigated that avenue thoroughly enough to answer). Or, am I totally misunderstanding you? -- 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
