what will happen if I frequently change the "main" branch?

[xxleyi]

Wiki page

https://github.com/arxanas/git-branchless/wiki/Concepts#main-branch

Subcommand

init

Description

as the title say

[arxanas]

Sorry, I don't understand the question. Why would something significant happen if you frequently change the main branch? Is there a particular part of the documentation you're referring to?

[rleconte]

I came upon this thread when having the same kind of "problem", and modifying the default revset for git sl indeed works, thanks!
For information the modified revset looks like:
((draft() | branches() | @) % (main() | long-living-branch)) | branches() | @
And the result:

❯ git sl
⋮
◇ e105f91 30d Long living branch has been branched here
┣━┓
⋮ ⊘ 76 omitted commits
⋮ ⋮
⋮ ◯ 074b099 2d (long-living-branch) Last commit on long living branch
⋮ ┃
⋮ ◯ 25b4d2a 1m Some commit on a branch of long living branch
⋮ ┃
⋮ ◯ a3a8dfd 1m (branch-on-long-living-branch) Last commit on my branch
⋮
◆ 6518cd8 1d (ᐅ main) Last commit in main
┃
◯ e63aab1 22s (branch-on-main) Some work on main

As I feel it is a common workflow in enterprises to have release branches, that are as "hard as a diamond" as main, should I open a feature request to declare other branches that could be treated as main, or it has already been proposed and rejected for some reason?

The expected result of such a feature would be to have a variation of the following smartlog:

❯ git sl
⋮
◇ e105f91 30d Long living branch has been branched here
┣━┓
⋮ ◆ 074b099 2d (long-living-branch) Last commit on long living branch
⋮ ┃
⋮ ◯ 25b4d2a 1m Some commit on a branch of long living branch
⋮ ┃
⋮ ◯ a3a8dfd 1m (branch-on-long-living-branch) Last commit on my branch
⋮
◆ 6518cd8 1d (ᐅ main) Last commit in main
┃
◯ e63aab1 22s (branch-on-main) Some work on main

[arxanas]

The main problem is that commands like [git sync] and revsets like stack() (and, of course, main()) are defined in terms of the main branch. In your workflow, does declaring multiple main branches do anything other than remove the "omitted" node from the smartlog?

[rleconte]

It does!
I also adapted git sync to my uses, with an alias:
git sync 'draft() - :release-branch - descendants(release-branch)'

Then it allows me to call this alias to sync all my branches and commits on top of main but also release-branch (for fixes that need to go on the release)

So I don't use all the commands yet, and don't know this project well enough to judge if having main() revset reference main + release branches would break things in all kind of weird ways, but so far I had to adapt git sl and git sync to treat those branches as immutable stuff on top of which I'm contributing commits and branches.

[arxanas]

@rleconte In the general case, if a commit to be synced has a common merge-base with multiple long-lived branches, how will we know which one to rebase it on top of?

[rleconte]

That's a good question, that I did not ask myself because with the way our branches are set up, once release-branch has been branched off, it never "crosses" main again, everything that needs to go in release-branch is cherry picked, not merged into it.
So I guess that's why my alias git sync 'draft() - :release-branch - descendants(release-branch)' that I talked about earlier works the way I expect it to (meaning a bunch of commits on release-branch are rebased on top of the newer version of release-branch and the same for main).