Could some more detailed examples of submit usage be provided?

[maxhaton]

Let's suppose I have a stack of commits, and I'd like to push them to a (self-hosted) gitlab, what should -F branch actually do? It doesn't seem to want to push anything because the upstream branch doesn't exist yet (e.g. I branched off to make a stack, incorrect?)

"Ideally" (I don't like gitlab, but this'll help) it could push them as separate ephemeral branches of some kind that I can twine together with MRs. Is such a thing possible?

[arxanas]

• Unfortunately, there is currently no specific integration with Gitlab.
• You're correct that nothing will be created unless you pass --create. This doesn't automatically create any MRs.
• There are a few instances on this discussion board (search for "gitlab") where people have posted their custom scripts to create the MRs.
  • In Gitlab, this is actually quite easy. You just need to set push options as part of git push: https://docs.gitlab.com/ee/user/project/push_options.html
• You could add support for Gitlab to git-branchless-submit yourself! There are examples for Phabricator and Github.
  • It might be possible to do everything with push options and never touch the Gitlab API directly?
  • Note: make sure to test and handle the case of reordering commits in a stack.
    • Normally, it suffices to visit/push commits in topological order. The current bottom-most commit has no dependencies, so you can safely push it and set its dependencies (to the empty set).
    • However, the forge itself may cause you problems. IIRC Github will automatically close a PR if it looks like its base branch has all its commits. If you reorder two commits without updating the base branch metadata, you can enter a brief state where it looks like one PR subsumes the other, and it gets auto-closed. So you need to set dependencies for each individual commit as you go, not do all the pushes first and all the dependencies second. (Shouldn't be a problem if using Gitlab push options?)
  • Note: beware the partial merge problem: if you merge some of the bottom-most commits, then git submit the remaining commits, you may lose the dependency information for the newest bottom-most unmerged commit, as it now appears to be directly based on the main branch.
    • This isn't incorrect, it's just really annoying in the forge UI because it's useful for historical reasons to know what the full stack was.
    • None of the forges at present address this. It might be possible to factor the forge interface better and somehow centralize the logic in the calling code.
    • To fix properly, I think this requires some kind of persistent state for each commit (or forge-side code review object) to check what its historical dependencies were.

[maxhaton]

The reordering I suspect may be pain; I don't really have a clear picture of how to do this just yet although its possible that simply force pushing where appropriate (and rm when not) might actually go a very long way (e.g. currently the MRs get their metadata from the commits, there isn't actually that much to update).

Wrt to persistent state we had some internal chatter about using git notes for this kind of thing, with enough contortion I suspect its actually pretty possible to make them stick ('git post-it'?) properly, but the foreign aspect could be a disaster.

In line with the latter point I'd be completely fine with shoving information in the commit message itself - its not exactly pretty but it works without much thought (other than the distributed systems aspects - to have identity, how shall we agree? - which while interesting also don't matter that much). Phabricator could be slightly annoying here in that (AFAICT / for us) the differential number didn't always make it into the commit message so getting a proper slug from a commit could be a bit of a pain.

[maxhaton]

Wrt to me contributing: Happy to (/ have a chat also?)

I think it might be prudent to nail down the semantics, implement them in our tool, then work out how to make submit give enough info to said tool, then upstream specifics (the API surface area used won't be very extensive but sufficiently large to make wrong turns expensive for a tool that isn't specifically for gitlab - let alone a non-self hosted gitlab)

[arxanas]

For the first version, think it would be fine to just implement something that doesn't store any extra metadata for now (and is annoying for some cases of landing stacks), without much extra design work. I'm guessing it would be simple to translate/migrate an existing script into git-branchless-submit by following the other forge code examples.

[claytonrcarter]

I have had idle day dreams of a mechanism by which we could a. have a GitLab forge (I agree that push args look promising) and b. read the MR data from a file, similar to how we use a lightly structured file with reword. So, an input file like this:

++ branch feature-a
# ... MR Title ...

... MR description ...

++ branch feature-b
# ... MR Title ...

... MR description ...

Could then be used by the SubmitForge to correlate the MR title/description to a particular branch, and then those values could up sent via push args.

[claytonrcarter]

I took a stab at creating a GitLab forge, powered by push options. --create seems to be working easily enough to create MRs that are targeted to merge into their nearest ancestor branch. What is not working is rearranging commits and automatically updating the MR target, such as when you might rearrange a stack of branches. In my experience, GL doesn't care if branches are rearranged and force pushed, but having to auto-update the target branch is a chore. I'll play with this locally for a while to see what/if/how I like it. I suspect that – short of integrating w/ an external tool like glab or egads the API directly – we may just have to 🤷 and issue a warning if a branch seems to need to have its target branch updated.