How to begin when there exist many branches and commits

[canadaduane]

Wiki page

No response

Subcommand

init

Description

I just ran git branchless init on my existing repository, and now I'm a bit confused about how to proceed. I have many branches and commits that exist from before trying git-branchless:

I guess I was expecting more of a "clean slate" beginning point.

I noticed there is a git hide command, but also read that that command may cause commits to be garbage collected.

At this point, dipping a toe in to git-branchless, I want to be able to "jump out" if it is too confusing or the flow doesn't work, so I'd rather not have existing branches or commits garbage collected.

What do you suggest is the right way to try this? Am I right to expect that the output of git sl should be a "clean slate" in order to begin my commit stack?

[claytonrcarter]

Hi @canadaduane, welcome to git-branchless!

Your experience sounds similar to mine when I first picked up git-branchless last year. I was coming from a low-discipline workflow with little/no rebasing, lots of long lived feature branches, frequent merges from master/main, etc ... it made a hash of the git smartlog output, which would produce several screens of output every time I ran it. 😆

At the time, I "resolved" that by getting more comfortable with rebasing, and pruning old branches that I figured I probably would never get back to. Since that time, a lot has been added to branchless that might make this an easier "boot up" process for you, though. In particular, I think that revsets (which have been released) and the configurable default smartlog revset (which has been merged but not yet released, I think) may come in handy. To wit:

• git smartlog can take an argument to constrain what is rendered
• By default this is ((draft() | branches() | @) % main()) | branches() | @ which is more or less "all commits that have not been merged to main, plus branches"
• I have git sl aliased to git smartlog stack(), which is "just the commits in my current stack". I find this useful to focus only on my current work.
• I have git sld aliased to git smartlog draft(), which is "all of my draft commits". I find this useful to step back and see everything I've got going on.
• I have git sla aliased to show the "branchless default revset" (ie "smartlog all"). I ... don't use this very often. 😄
• To get you started, you may want to consider trying something like git smartlog stack() or even git smartlog (((draft() | branches() | @) % main()) | branches() | @) & date.authored('after:2023-04-03') to show you all of the "normal" smartlog commits, but only if they were authored after today (or whenever you ran init)
• I think you get the idea ... revsets have been fun to play with.
• See also: https://github.com/arxanas/git-branchless/wiki/Reference:-Revsets and Revset recipes #496

To your other points:

• git hide does not cause commits to be gc'd, but it will stop branchless from preventing them from being gc'd. 🙃
  • branchless uses special refs to prevent "branchless" commits from being gc'd, git hide removes those refs (among other things)
  • so long as they (or any of their descendants) are pointed to by a branch, tag or other ref, they will not be gc'd (this is gits normal gc behavior)
  • In the screenshot you posted, all commits look like they're on a branch, so none of them would be gc'd, even if you ran hide on all of them ... that might not clean up your smartlog, though 😄
• "want to be able to "jump out" if it is too confusing or the flow doesn't work"
  • If you decide to back out, and you have any branchless commit stacks at that time, just be sure to create a branch for each of them before you uninstall branchless so that they will still be visible to you after the uninstall.
• "Am I right to expect that the output of git sl should be a "clean slate" in order to begin my commit stack?"
  • No, not at all. You can begin a new stack anywhere you want: on a clean slate; or on a long lived, merge filled branch.

[arxanas]

Thanks for the great answer, @claytonrcarter 😄.

• You can also write e.g. date.authored('after:2 weeks ago'), which is useful for some people who tend to keep many branches but leave many of them "stale".
• Just to emphasize, if you have a branch pointing to a commit, then it will never be garbage-collected. The GC stuff in the documentation applies to commits which have no branches pointing to them or a descendant (aren't "reachable" from a branch) — but that practically never happens with normal Git usage. You'd have to enter "detached HEAD" mode and then make a commit.
  • git-branchless makes it easier to create commits which aren't reachable from any branch. The GC docs are noting the mechanism by which git-branchless prevents Git itself from throwing away those commits.
• The "default revset" configuration option is branchless.smartlog.defaultRevset. See Manual testing if you want to try out a development version of git-branchless which supports this feature.