On Sat, Jul 11, 2015 at 7:05 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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 <sunshine@xxxxxxxxxxxxxx> > --- > > 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') -- Duy -- 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