Is a single main branch sufficient?

[epage]

Frequently, developers have to deal with patching prior releases and have to work on those branches.

git-stack takes the approach of supporting many "main" branches to handle these cases, calling them "protected branches" (indicating what git-stack should not mutate).

[arxanas]

The main things stopping us from using more than one branch are:

• The underlying DAG structure is optimized for a single main branch, which is important for large repositories.
• The smartlog doesn't know how to render other main branches specially. I suppose we would want to abbreviate commits which are only ancestors of main branches?
  • What should we do if two of the main branches have no common ancestor?
• The smartlog doesn't know how to render merge commits well. (I'm worried that drawing a line from multiple commits to its merge commit will result in a difficult-to-read graph, which I've seen in git log --graph.)

The rest of the functionality, like moving/restacking/undo should work fine with multiple branches.

git-branchless meets my needs personally, so I haven't wanted to expand the scope to multiple main branches, but I'm open to the idea.

[epage]

The main things stopping us from using more than one branch are:

I guess there are two routes for multiple main branches

• Treat each main branch as a distinct area of work and auto-detect which main you are on (no smartlog visualizations needed)
• Treat all main branches as related work (all of the stuff you described)

git-stack supports both, through the config/arg

   -s, --stack <stack>                
            Which branch stacks to include [possible values: Current, Dependents, Descendants, All]

descendants is everything under the main branch you are currently descended from

all is all main branches

By default, we elide commits though this is controlled through config/arg

        --format <format>              
             [possible values: Silent, Branches, BranchCommits, Commits, Debug]

branches only shows the last commit for each branch plus shared bases

branchcommits shows all of the commits for the users branches

commits shows all

(one of the things blocking a 1.0 release is upgrading to clap3 and getting to use ArgEnum with its case-conversion rather than arg_enum)

The smartlog doesn't know how to render merge commits well. (I'm worried that drawing a line from multiple commits to its merge commit will result in a difficult-to-read graph, which I've seen in git log --graph.)

git-stack discourages users from using merge-commits in their branches. For main branches, we linearize the commits which we can get away with because we don't perform operations on them and we usually hide them.

git-branchless meets my needs personally, so I haven't wanted to expand the scope to multiple main branches, but I'm open to the idea.

Understandable. Among my open source work, only clap has to deal with this (master and v2-master). Back at my previous jobs, it would have been required.