| Message ID | 20190201220420.36216-1-nbelakovski@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | [v7,1/3] ref-filter: add worktreepath atom | expand |
nbelakovski@gmail.com writes: > ref-filter: add worktreepath atom > branch: Mark and color a branch differently if it is checked out in a > linked worktree > branch: Add an extra verbose output displaying worktree path for refs > checked out in a linked worktree As you can see in "git shortlog --no-merges", later two patches would look quite out of place by having overlong title and starting the description(i.e. after "<area>: ") in a capital letter. It is still not clear why we would want 2/3, even though I think 3/3 is a good idea. This round signs off all the three patches, which is a great improvement ;-)
On Fri, Feb 1, 2019 at 2:54 PM Junio C Hamano <gitster@pobox.com> wrote: > > > As you can see in "git shortlog --no-merges", later two patches > would look quite out of place by having overlong title and starting > the description(i.e. after "<area>: ") in a capital letter. Hadn't looked at it that way. OK, will shorten/uncapitalize. > > It is still not clear why we would want 2/3, even though I think 3/3 > is a good idea. > It's interesting to me that you like 3/3 but not 2/3 :) My apologies for restating the commit message, but the point of 2/3 is to communicate to the user that highlighted/marked branches will behave differently from unhighlighted/unmarked branches for commands to check out or delete. I think this is useful since it gives the user actionable information ahead of time, as opposed to providing that information upon failure of checkout/delete. It also makes sense since 'git branch' is already highlighting the current branch, i.e. this is just an extension of that idea. As we've stated earlier in this thread, 1/3 allows for users to implement this on their own with a custom git branch format. Personally I think there's value in making it default, since it's adding information in a minimally intrusive way. I do believe that merely adding information isn't a good enough reason to change things, as information overload is a real thing, but in this case the output isn't changed for anyone not using a worktree (same goes for 3/3), and for someone using a worktree this provides useful and actionable information, IMO. Does that change your mind at all?
From: Nickolai Belakovski <nbelakovski@gmail.com> Moved initialization of ref_to_worktree_map outside of atom parser. Other minor fixes. Put the hashmap and the worktree struct in the same struct, to make it more obvious that they are to be initialized and free'd together. Travis CI results: https://travis-ci.org/nbelakovski/git/builds/487642061 Nickolai Belakovski (3): ref-filter: add worktreepath atom branch: Mark and color a branch differently if it is checked out in a linked worktree branch: Add an extra verbose output displaying worktree path for refs checked out in a linked worktree Documentation/git-branch.txt | 21 +++++----- Documentation/git-for-each-ref.txt | 5 +++ builtin/branch.c | 16 ++++++-- ref-filter.c | 78 ++++++++++++++++++++++++++++++++++++++ t/t3200-branch.sh | 8 ++-- t/t3203-branch-output.sh | 21 ++++++++++ t/t6302-for-each-ref-filter.sh | 15 ++++++++ 7 files changed, 147 insertions(+), 17 deletions(-)