search

UMPsychMethodsCore / MethodsCore

All of the projects that the methods core develops, combined into one repository!
7 stars 0 forks source link

Radical Repository Simplification #386

Closed dankessler closed 8 years ago

dankessler commented 8 years ago

No need to do this urgently, but was talking through the 2.0 release with @mangstad and came up with an idea for radically simplifying the git workflow, and I wanted to stub out documentation for the approach here before I forget.

This will much more closely follow the standard git branching workflow

  1. Introduce a "dev" branch. This will collect all changes and periodically merge into "public" to constitute a release
  2. Do away with Toolbox_beta branches for released tools. New features will branch directly off dev and merge back into dev.
  3. Maintain Toolbox_beta branches for unreleased tools. New features will either be merged in directly by maintainers or via PRs when group input is sought.
  4. Simplify Utilities by collapsing into a single Utilities_base to track contributed Utilities_patched to track our modifications.
rcwelsh commented 8 years ago

Hey Daniel, So if I look at those diagrams I'm a little confused. Maybe because the toy model diagrams are not quite consistent. If the rule is that branches are brought in and out of develop, that would imply that nodes (colored circles) can not appear unless there is an interaction (merge) with a feature branch. Am I reading those diagrams correctly? That is an arrow implies a commit but those can only happen in dev when there is a featuring being merged back into dev.

This diagram can exist (decimals are spaces to make sure digram looks correct):

dev -O------------->-----O--->---- . . . . . . . . \ . . . . . . . . . ^ . . . . . . . . .\ . . . . . . . . / feature -----O---->---O------

This diagram should not exist:

dev -O--->----O--->----O--->---- . . . . . . . . \ . . . . . . . . . ^ . . . . . . . . .\ . . . . . . . . / feature -----O---->---O------

If this diagram immediately above existed it implies that a commit was done within dev without a merger from a feature branch which breaks the philosophy. Right? The diagram I guess could however exist if people in the private repositories on their machines were doing pull requests from dev prior to merging in their feature back into dev locally before pushing back to universe. Right?

dankessler commented 8 years ago

Yes, I'm also not sure why in their diagrams there are sometimes bubbles on the develop branch that aren't the result of merges. The only thing I can hazard is that it reflects some sort of simplified diagram where those merges simply aren't shown. I would have guesses that they reflect trivial merges, which git will do via fast-forward, but there's actually a section in the article that argues for using --no-ff to prevent this type of behavior (with a clear example of why).

dankessler commented 8 years ago

I guess if there are super trivial commits that don't really encompass "new features" you could branch from develop, pull back in, and not do --no-ff so prevent cluttering the history with side branches, but github by default doesn't do this when reconciling with pull requests.

dankessler commented 8 years ago

Robert's correction aside, are there any other thoughts on this idea? Especially as we begin work on adding database hooks and stuff (which is very likely to cut across many toolboxes) I imagine it'd be much easier to just fork off of a develop branch rather than forking off of many toolbox branches.

rcwelsh commented 8 years ago

Agreed, we branch from dev and then merge back in.

Robert

typos due to iPhone 4S

On May 24, 2016, at 14:49, Daniel A Kessler notifications@github.com wrote:

Robert's correction aside, are there any other thoughts on this idea? Especially as we begin work on adding database hooks and stuff (which is very likely to cut across many toolboxes) I imagine it'd be much easier to just fork off of a develop branch rather than forking off of many toolbox branches.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

dankessler commented 8 years ago

I've updated the wiki to reflect the new workflow. I'll be doing some rapid cleanup of the branch space for universe in the next couple minutes

dankessler commented 8 years ago

Here's a todo list

Consolidate Utilities

Consolidate Toolboxes

Create Dev Branch

dankessler commented 8 years ago

Here are all of the "toolboxes" (i.e. branches with beta in the name) that are not merged into public

Of these, I think the following are basically "derelict"

To limit the namespace pollution, I'm just going to octopus merge all three into a branch I'll call "DerelictToolboxes" so that they're still reachable if we ever need them.

dankessler commented 8 years ago

And, once I octo-merge them, I'll delete the ancestors, leaving

as the unreleased toolboxes (which will remain in beta)

dankessler commented 8 years ago

All steps are completed, the wiki is updated, and we're ready to start enjoying a radically simplified repository :)