On Fri, May 06, 2016 at 05:21:05PM +0700, Duy Nguyen wrote:
> > Similarly, it looks like 'path' doesn't need to be a strbuf at all
> > since the result of absolute_path() should remain valid long enough
> > for fspathcmp(). It could just be:
> >
> > const char *path = absolute_path(...);
> > wt->is_current = !fspathcmp(git_dir, path);
> >
> > But these are very minor; probably not worth a re-roll.
>
> Yeah. I think the use of strbuf is influenced by the code in
> get_worktrees(). But since this code is now in a separate function, it
> makes little sense to go with the strbuf hammer. If there's no big
> change in this series, I'll just do this as a cleanup step in my next
> series, worktree-move.
On second thought, why hold patches back, lengthen the worktree-move
series and make it a pain to review? I moved a few patches from
worktree-move into this series and I took two other out to create
nd/error-errno. So I'm going to take more patches out of it, creating
two bite-sized series, to be sent shortly.
The first one is purely cleanup (ok, 1/7 is not exactly cleanup)
[1/7] completion: support git-worktree
[2/7] worktree.c: rewrite mark_current_worktree() to avoid
[3/7] git-worktree.txt: keep subcommand listing in alphabetical
[4/7] worktree.c: use is_dot_or_dotdot()
[5/7] worktree.c: add clear_worktree()
[6/7] worktree: avoid 0{40}, too many zeroes, hard to read
[7/7] worktree: simplify prefixing paths
And the second one adds "git worktree lock" and "git worktree
unlock". This series is built on top of the first one, it needs 1/7.
[1/5] worktree.c: add find_worktree_by_path()
[2/5] worktree.c: add is_main_worktree()
[3/5] worktree.c: add is_worktree_locked()
[4/5] worktree: add "lock" command
[5/5] worktree: add "unlock" command
After this, worktree-move becomes ~10 patch series.
--
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
