Overwhelming output from git-stack

[Bouke]

Thanks for reporting and sorry your first experience is less than ideal! This has been my daily driver for the last several months but I've only recently started to advertise it more and so it doesn't have the polish yet of many user experiences.

Feel free to create an issue about the stackview being overwhelming. Hopefully we can find safe weighs for communicating what your workflow is like that makes it so overwhelming so we can figure out alternatives, steps, or different defaults we might want

Originally posted by @epage in https://github.com/epage/git-stack/issues/95#issuecomment-947580192

The problem description of this project seems like a perfect fit to how I'm using git. Working on multiple problems at the same time, and pull requests that build on one another. So I'm happy to try this out!

So my output from git-stack starts with this:

git stack
053efb0 Resolve lint issues
├── o
|   └── feature/eslint-typescript (pushed) Added typescript linter, but gives incorrect errors
└── o
    ├── c973df9 Corrected url
    |   ├── 297ea3e Show unsupported message to IE users
    |   |   ├── 0d5bc31 Unique cookie names for both websites

So I'm parsing this as follows:

• feature/eslint-typescript this is a stack. It's an old stack, mostly an abandoned branch last committed to 3 years ago.
• c973df9 what is this rev doing here? It is a random commit merged into master (current branch) 2 years ago.
• 297ea3e another random commit merged into master (current branch) over a year ago.

There's a lot more output, mostly revs. The output ends with a few branch names which I'm currently working on, so those make sense.

[epage]

Thanks for writing this up!

By default, git-stack is showing

• All of your development branches
• All of your protected branches (main, etc)
• All of the merge-bases between these branches

If you have a lot of protected branches that you aren't directly using, this can muddle up the view.

Similarly, if you have a lot of branches not on the tips of your protected branches, this can muddle up the view.

I've tended to work where I only keep a minimal number of protected branches locally (I'll check out the remote branches as a detached HEAD state when just browsing around) and I rarely have branches that are not on the tip of a protected branch. I also understand not everyone might work like this and I'd be interested to hear how your workflow might be different so we can see how we might be able to better align this with other people's workflows.

To get the brainstorming going, some ideas of how we could improve things

• Make descendants the default
• Show descendants of each protected branch as an independent tree, hiding their merge-base
• Abbreviate or hide protected branches that do not have development branches on off of them

[Bouke]

Ok so in my example 053efb0 is where some of the other branches have branched off (common parent). Indeed, removing some old branches improves the output.

I'm often experimenting with the code and leaving the result (spike) on a local branch. I usually call those branches spike/[name]. So ignoring all those branches would be a good start. Maybe some option to just ignore certain branches?

Additionally branches not in active use go stale. Maybe we should ignore branches without a recent commit?

When reviewing other's PRs I typically create a local tracking branch. These typically shouldn't be altered by git-stack, as they are externally owned. I don't fancy having to mark each branch as protected, as that's something that will be overlooked. So maybe we should try and determine un-owned branches by committer name, ignoring those that don't have the last commit from us.

[epage]

I'm often experimenting with the code and leaving the result (spike) on a local branch. I usually call those branches spike/[name]. So ignoring all those branches would be a good start. Maybe some option to just ignore certain branches?

Would marking them as protected work? The config uses gitignore glob, so in your ~/.gitconfig, you can have

[stack]
    protected-branch=spike/*

The main downside is if there happens to be a branch in the pull-remote with the same name, we'll try to rebase your spike against it. If there is a conflict, we'll leave it as-is.

I have been worried that having only two kinds of branches, protected and development, might be insufficient, that we might need upstream, development, and ignored.

Additionally branches not in active use go stale. Maybe we should ignore branches without a recent commit?

I feel like this is concrete enough that I've split it out into https://github.com/epage/git-stack/issues/111. Even if we find an alternative solution, I feel like having that conversation discoverable will help because I bet it will come up again.

When reviewing other's PRs I typically create a local tracking branch. These typically shouldn't be altered by git-stack, as they are externally owned. I don't fancy having to mark each branch as protected, as that's something that will be overlooked. So maybe we should try and determine un-owned branches by committer name, ignoring those that don't have the last commit from us.

Similarly, I've split this out as https://github.com/epage/git-stack/issues/112

[epage]

I've also created

• https://github.com/epage/git-stack/issues/113
• https://github.com/epage/git-stack/issues/114

[epage]

I just released v0.4.2 which includes #111, #113, and #114.

There is still open discussion on how to handle #112 and on handling of spike branches (hopefully #111 helps)

[epage]

Mind upgrading to v0.4.5 and reporting back on the experience? I'm hoping we are finally there on providing a good experience on a more cluttered repo.

[Bouke]

I've upgraded to 0.5.0. The output is much easier to grasp now, so that's great! Stale branches are being hidden, which is also helpful. However I've tried to rebase some "stale" branches, but it seems I cannot change the default. I've tried git config stack.protect-commit-age 30days but that doesn't change the output of git stack --dump-config -. Is there maybe an undocumented flag I can pass?

So far I haven't used git stack as much as I've thought I would. I'm often working on the same branch between two machines (macOS and Windows), using force-push to sync between them. I see some interesting changes in git stack which will probably help in my scenario ("restore rebase"). I'll try it some more and share my experience. Thanks.

[epage]

it seems I cannot change the default. I've tried git config stack.protect-commit-age 30days but that doesn't change the output of git stack --dump-config -. Is there maybe an undocumented flag I can pass?

v0.5.1 is out with a fix

However I've tried to rebase some "stale" branches, but it seems I cannot change the default. I've tried git config stack.protect-commit-age 30days

For one off cases like this, don't forget you can use git -c stack.protect-commit-age=30days

Stale branches are being hidden, which is also helpful. However I've tried to rebase some "stale" branches,

So for operations, we always protect stale branches but for visualization, we trim all stale branches but HEAD. For a use case like yours, I think we shouldn't protect HEAD if its stale. This will let you rebase it.

So far I haven't used git stack as much as I've thought I would. I'm often working on the same branch between two machines (macOS and Windows), using force-push to sync between them

We currently push only the ready branches. Would it help to have a "push all"? Compared to doing it yourself, you get auto-detection of what branches to push and it always runs with force-with-lease, making it less likely you overwrite something unintentionally.

[epage]

v0.5.2 is now out and doesn't auto-protect HEAD.

[epage]

Sounds like this is resolved. Feel free to open up a new issue fr any further ideas!