tcup ideas

notes

> tcup server github add

When I'm managing a GH project, I really want to sync everybody's repo.
See what people are building on top, even if they're not done or shy to create
an official PR.
When contributing, I want to know how my changes will conflict with a major
refactor one of the dozen core devs has waiting in their branch. (Only
discussed on IRC, too.)
See https://github.com/defunkt/github-gem for ideas

Tell me what'll conflict. Tell me what CI thinks about the code.
Also, give me the wikis by default.
Extra credit: map issues to Git repos. I have some ideas here, too.


> tcup should print a big scary warning and adamantly refuse to change history
> that it thinks has been published.

I want to force-push PRs and scratch CI requests, all the time.
AFAIAC, If you didn't pull from my master branch or tag, be prepared to rebase.
Remote branches should be markable to disable this, and perhaps remotes should
be markable so new branches on them are created with that mark by default.

wipbranches

= Problem =

Sometimes, I work on two+ branches at once:
 - The two features are orthogonal, and they usually don't conflict (except
    the occasional CHANGELOG entry etc.).
 - The features aren't complete enough to push to the official public master,
    though I might want to push one to a scratch branch.
 - At the same time, I'm developing a program that needs all the WIP features
    of the library.
Note that working on something tends to involve heavy squashing and rebasing.

I can't find a good way to do this with Git.

= My current workflow =

Currently I use tags in commit messages. For example (refs in parentheses,
bracketed stuff is part of commit message):

* (HEAD, devel) [size-fixes] Documentation improvements
*  [imagelayer] Exporting image layers
*  Fix bug #1234
*  [imagelayer] Creating image layers
*  [size-fixes] Consolidate `size` and `pixel_size` attributes
*  [imagelayer] Importing image layers
* (origin/master) Release version 0.1

When I want to push a branch (to create a PR, or to get CI to pick it up), I
rebase one "virtual branch" to the bottom, removing the tags, and make a real
branch:

* (HEAD, devel) [imagelayer] Exporting image layers
*  Fix bug #1234
*  [imagelayer] Creating image layers
*  [imagelayer] Importing image layers
* (size-fixes) Documentation improvements
*  Consolidate `size` and `pixel_size` attributes
* (origin/master) Release version 0.1

When I push out two WIP branches, I need a merge on top. Of course a new
commit can appear for one of the "virtual branches":

*   (HEAD, devel) [size-fixes] Consolidate `pos` and `pixel_pos`
*    [imagelayer] Exporting image layers
*    [imagelayer] Creating image layers
*    [imagelayer] Importing image layers
*    Merge WIP stuff
|\
* | (bugfixes) Fix bug #1234
| * (size-fixes) Documentation improvements
| *  Consolidate `size` and `pixel_size` attributes
|/
*   (origin/master) Release version 0.1


= Possible solution =

Combine patch queues with octopus merges

The problem maps nicely to the following structure:

*__   (HEAD, imagelayer+bugfixes+size-fixes) Merge WIP branches
|\ \
| | * (imagelayer) Exporting image layers
| | *  Creating image layers
| | *  Importing image layers
* | | (bugfixes) Fix bug #1234
| * | (size-fixes)  Documentation improvements
| * |  Consolidate `size` and `pixel_size` attributes
|/_/
*     (origin/master) Release version 0.1

If only the tools could make working with this easier....

Something like ("wipbranch" is a bad name):

git commit --wipbranch=bugfixes -m "M"
git commit --amend --wipbranch=imgelayer
git rebase -i --wipbranch=size-fixes  # to rearrange a single branch only

Also, [branchname] at start of commit message could work like squash!/fixup!.

Most of these would:
 - Check out the named branch
 - Do the action
 - Octopus-merge everything and put into the "top" branch
 - Check out the "top" branch
... with proper checks and reverts along the way

The "+" notation in the "top" branch name is all the metadata we need.


Problem: CHANGELOGs will conflict. Do something with that.
rerere comes to mind -- it's just making it work properly with octopus merges.


Sometimes branches will depend on each other. The tools shouldn't destroy the
following structure:

*__   (HEAD, imagelayer+bugfixes+size-fixes) Merge WIP branches
|\ \
| | * (imagelayer) Exporting image layers
| | *  Creating image layers
| | *  Importing image layers
* | | (bugfixes) Fix bug #5678
| * | (size-fixes) Optimize size attributes (needs bug 1234 fixed)
|/| |
* | |  Fix bug #1234
| * |  Documentation improvements
| * |  Consolidate `size` and `pixel_size` attributes
|/_/
*     (origin/master) Release version 0.1

When the #1234 fix is merged upstream, I should, with a simple [from user POV]
pull --rebase, get this:

*__   (HEAD, imagelayer+bugfixes+size-fixes) Merge WIP branches
|\ \
| | * (imagelayer) Exporting image layers
| | *  Creating image layers
| | *  Importing image layers
* | | (bugfixes) Fix bug #5678
| * | (size-fixes) Optimize size attributes (needs bug 1234 fixed)
| * |  Documentation improvements
| * |  Consolidate `size` and `pixel_size` attributes
|/_/
*     (origin/master) Fix bug #1234


Note: This could obsolete stashes (!!)
 - stash save -> a new branch subcommand?
    - put index&tree into branch (random name by default),
    - clean index+tree
 - stash apply -> wipbranch add <stash name>
    - adds the last stash to the octopus commit if there is one
    - if there isn't one, creates a new merge commit named
        currentbranch+stashbranch
 - stash apply + commit -> rebase everything onto that branch, pushing it out
    of the "wip branches" set
 - stash drop -> branch -D