Proposal: git hide -b <BASE> - Hide entire subtree starting from the main branch

[zachallaun]

Context

Let's say I'm working on a feature being contributed to another repository:

* 1 (main) initial Initial state
|
* 2 Add foo
|
* 3 Add bar
|
* 4 (my-feature) Add baz

The feature is accepted and the maintainer squashes all commits and merges into main. After pulling, my tree looks like:

* 1 Initial state
|\
| * 2 Add foo
| |
| * 3 Add bar
| |
| * 4 (my-feature) Add baz
|
* 5 (main) Add my-feature

I'd now like to delete the my-feature branch and hide all commits. The easiest way to do this is:

$ git hide -r 2 -D
* 1 Initial state
|
* 5 (main) Add my-feature

This is a nice one-liner, but if you have a lot of commits in that branch, it can involve scrolling up and copying the commit hash.

Proposal

I'd love to page a page from the book of git move and add git hide -b/git hide --base. Like git move -b, it would hide from the "other direction", hiding the entire subtree between the main branch and the commit. Using this, the command above would become:

$ git hide -b my-feature -D
* 1 Initial state
|
* 5 (main) Add my-feature

Other thoughts

• I considered that git hide -b my-feature should delete my-feature by default, which (I think) you'd almost always want to do. This would make -D redundant when using -b with a branch, however, and may be surprising to some.
• Is there a better/easier way to do this already that I can't find/don't know of? The goal is to delete a branch using the branch's name and hide its subtree in one command.

[arxanas]

You probably want to check Reference: Revsets.

On git hide's flags:

• -r should be removed, as you can always write -r foo as foo:. (The flag existed before there was support for revsets.)
• -D should probably be the default (or only mode of operation?) as it's generally not useful to keep a branch to a hidden commit.

If you have committed the feature branch upstream by rebase, then you can use git sync and it should clean up the commits/branch automatically. Otherwise, I often use git hide -D 'stack(my-branch)' to accomplish a similar effect. If you need to be more precise (such as if the feature branch is in a stack but you don't want to hide the entire stack), you could do something like (untested) git hide -D 'my-branch % main()' to hide all commits reachable from my-branch but not from the main branch.

[zachallaun]

This is perfect!

git hide -D 'stack(my-branch)' is perfect. This is indeed a good opportunity for me to learn more about revsets. (Your note about -r foo being equivalent to foo: is great as well.)

[claytonrcarter]

I think that there is merit in making common use cases easier. In this case, I also often want to delete a branch, and my lazy fingers would prefer to type hide -bD my-branch instead of hide -D 'stack(my-branch)'. Basically, the need to add the quotes and the parens often feels verbose.

In particular, I will often do something like hide my-branch – forgetting that that will only hide a single commit – and then have to rerun it with hide 'stack(my-branch)'. I have a similar quirk w/ git sync, but I'll bring that up elsewhere.

@arxanas are you opposed to a -b flag for hide, or just not interested in it yourself?

[arxanas]

@claytonrcarter I am not necessarily opposed to it, but the semantics would be slightly troublesome, because git move's -b stands for --base, not --branch. If you compute the merge-base with the current commit, you might accidentally hide some extra commits that you didn't intend to if you were expecting the "branch" interpretation. For example, if you have this graph:

graph TD;
    Z --> main
    Z --> Y["Y (HEAD)"]
    main --> A
    A --> B

Loading

where you're at commit Y, and you run git hide -b B, then the commits since the merge-base would include main, which you probably don't want to hide.

Possibly it's fine if we just don't hide public commits when doing this.