It was previously assumed that all forges would want to create and operate on branches, and, in fact, the calling git-branchless-submit code would even create the branches returned by CreateStatus. This has turned out not to be the case. For example, the Phabricator forge embeds the commit identifier in the (updated) commit message, and doesn't need a branch (and, in practice, it's turned out to be more annoying than useful to create the branches as shorthand identifiers).
This commit removes the auto-branch-creation behavior and updates the terminology to be branch-agnostic and refer to "commits" instead of "branches".
As a result, commits are now "submitted" at the beginning of their submission lifecycle, and future pushes (etc.) are "updates". This doesn't exactly make sense with the name of the --create flag, since we never refer to "creating" a commit anywhere, only "submitting" one, so we might want to change that flag name or terminology in the future.
Stack:
feat(submit): make forges branch-agnostic
It was previously assumed that all forges would want to create and operate on branches, and, in fact, the calling
git-branchless-submitcode would even create the branches returned byCreateStatus. This has turned out not to be the case. For example, the Phabricator forge embeds the commit identifier in the (updated) commit message, and doesn't need a branch (and, in practice, it's turned out to be more annoying than useful to create the branches as shorthand identifiers).This commit removes the auto-branch-creation behavior and updates the terminology to be branch-agnostic and refer to "commits" instead of "branches".
As a result, commits are now "submitted" at the beginning of their submission lifecycle, and future pushes (etc.) are "updates". This doesn't exactly make sense with the name of the
--createflag, since we never refer to "creating" a commit anywhere, only "submitting" one, so we might want to change that flag name or terminology in the future.