Re: [PATCH v3 05/13] worktree.c: mark current worktree
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 10, 2016, 23:03 UTC
- Message-ID
- <xmqqzirxldn9.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160510141416.GA22672@lanh>
Duy Nguyen <pclouds@gmail.com> writes:
Show 15 quoted lines
> 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 pathsWhere are these patches designed to apply?
It appears that this depends on something in 'next' (probably nd/worktree-various-heads topic?)
Show 11 quoted lines
> > 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.