Traverse stop condition

[chriscz]

I've been using git-machete in my workflow for some time now, and I've been using a thin wrapper around machete to make my workflows easier and more automated, especially in cases where I alone manage the branch stack I work on.

To this end I often make use of non-interactive traverse.

Building on #1362, since we now have the ability to synchronize a stack of branches, it would be great to stop after a stack has been synced.

It seems to me that the simplest API to support this would allow you to stop traversal either on or after some branch is reached.

In this example

  main
  │
  └─feat/notifications
  |  │
  |  └─feat/notifications-sms
  |    │
  |    └─feat/notifications-email
  │
  └─feat/annoy-users

If I were to run this command (--create-github-prs seems not to be present yet)

git matchete traverse --create-github-prs --start-from=feat/notifications --stop-at=feat/notifications-email

I would expect the last PR create to be for feat/notifications-email, leaving me with:

  main
  │
  └─feat/notifications #1
  |  │
  |  └─feat/notifications-sms #2
  |    │
  |    └─feat/notifications-email #3
  │
  └─feat/annoy-users

Similarly, running

git matchete traverse --sync-github-prs --start-from=feat/notifications --stop-at=feat/notifications-email

would restack these and sync them.

Alternative Approach
With the proliferation of flags and options on the traverse command, I've wondered whether a simpler --command option would not make more sense. In this case I would be able to hack together the above by doing the following:

git matchete traverse --start-from=feat/notifications --command='(git machete github create-pr || git machete github restack-pr -U) && [ $(git branch --show-current) != 'feat/annoy-users' ]'

[PawelLipski]

👋🏻

If I were to run this command (--create-github-prs seems not to be present yet)

Actually! --sync-github-prs has two effects:

I've just noticed that the docs for the flag itself don't mention creating PRs, I'll fix that now:

It seems to me that the simplest API to support this would allow you to stop traversal either on or after some branch is reached.

I agree that --stop-at=... is a better option here 😅 Flag like --command will likely be too... powerful (?), potentially leading to weird side effects where the process of traverse is disrupted in hard-to-predict ways.

I'll add two improvements then:

1. --start-from=... will also accept a managed branch name, not just a fixed value here, root, first-root,
2. --stop-at=... flag will be added, and it'll accept a managed branch name (but no fixed values — I don't think these are needed)

[PawelLipski]

PR for docs: #1495

[chriscz]

Hi @PawelLipski this sounds great. Are you also saying that using --sync-github-prs in non-interactive mode will do a create?

--command is indeed quite powerful and probably won't be used by most users, but I view it as a useful escape-hatch / extension seam for scripting non-interactive traversals like I'm doing. However it's probably only worth real consideration if you find yourself needing to hoist more and more sub-command APIs like "--sync-github-prs" to traverse.

[PawelLipski]

Are you also saying that using --sync-github-prs in non-interactive mode will do a create?

Yes, when both --sync-github-prs and --yes are both passed, then PRs are created automatically. Here's a sample execution on a sandbox repo:

needing to hoist more and more sub-command APIs like "--sync-github-prs" to traverse

Yeah, I think I might end up needing to do something like that at some point 😅
Still, for now, I've extended the semantics of --start-from at PR #1496, and a PR adding --stop-at (or --stop-after, TBD) will soon follow

[PawelLipski]

PR for --start-from: #1496
PR for --stop-after: #1509

[PawelLipski]

Soon to be released as v3.37.0