regexversion-controlmercurialtortoisehg

How can I filter tortoisehg (Mercurial) to not show branches containing part of a string?


Our Mercurial/HG repo has a fair amount of wip feature branches, and I would like to be able to create a cleaner view and filter out any branches containing part of a string.

I know I can specify which branches to show, but I would rather like to be able to set a search string that is excluded, since all of those branches include something like feature_xx

Something a long the lines of: not branch_contains("feature"), possibly using regex? Hiding them from the history/hierarchy view individually would also be an ok solution.

How do I do this in TortoiseHG?


Solution

  • Preface

    You have to understand: Mercurial per se and TortoiseHG are slightly different products with own interfaces (CLI vs GUI) and toolsets due to nature

    Face

    If you want only hide some subtrees from main window of Workbench (top-right area), you can activate Filter Toolbar (View - Filter Toolbar or Ctrl+S)

    Empty Filter Toolbar

    and apply (previously tested in pure CLI or write and debug in-place) revset (hg help revsets) to hide unwanted branches (namely branch(string or set) revset and operator not x)

    Note 1: Entered revset here doesn't restore filtering after restart of THG in new session automatically, you have to do it by hand

    Note 2: All and any used revset doesn't disappear after re-launch of THG, but stored in history of toolbar (until manually removed) and can be easy restored later

    For your use-case "all branches, not having feature_ in branch-name" I got in the revset with (simplest) regexp something like

    ! branch('re:(?i)feature_')
    

    PS: just a sample. During testing, with such filter

    Excluding release branches

    in repo with branch-list

    hg branches
    1.0.x                       2193:20739d2244a1
    default                     2190:efadd9becb86
    0.10.x                      2118:4a18ab4b2fed (inactive)
    

    I removed from view not only existing release-branches 0.10.x + 1.0.x, but also all future releases, which will follow the same pattern of naming (trailing "0.x")