host-specific adapters for git-stacked-rebase

words:	3 + 232 = 235
last update:

#public
parent:: [[git-stacked-rebase]]

Linked Mentions (2 in 1 page)

January 24th, 2022 (2)
- though, i intentionally don't put the [[host-specific adapters for git-stacked-rebase]] as the first priority here, because it feels like being able to integrate into the existing ecosystem, while creating some additional extras ([[browser extension]]) to make it easier to use [1], is the right approach
- because we might not even need this at all, and perhaps the [[host-specific adapters for git-stacked-rebase]] would be completely enough to automate the manual parts so that it wouldn't matter as much of having multiple PRs vs one
  - though, i intentionally don't put the [[host-specific adapters for git-stacked-rebase]] as the first priority here, because it feels like being able to integrate into the existing ecosystem, while creating some additional extras ([[browser extension]]) to make it easier to use [1], is the right approach
  - [1] i think specifically the issue of having comments in separate PRs is important -- if you decide to split out a PR into multiple ones, then some comments will get lost, because we do not control in which PR they appear - we only control the PRs & the commits.
    - but, if we had the single PR + extension, we could now play w/ the comments, or perhaps wouldn't need to do much if anything at all, since you'd only have an extra partial branch / diff to cycle through the UI when reviewing - the comments/changes would remain in the same place.