Feature branches (apologies to everyone for changing my mind... again)

[ctrlplusb]

UPDATE

I have decided branches are too noisy and difficult to manage. We will offload features onto seperate repositories.

I have created a redux and apollo repo (see README.md for links).

We need to decide on ownership for the following feature branches and move them to seperate repos:

• [ ] postcss-sass (created by @strues)

Here is an example workflow:

# Clone required incubator branch into target new repo folder
git clone https://github.com/ctrlplusb/react-universally -b incubator/state/redux react-universally-redux

# Enter repo folder
cd react-universally-redux

# Create a master branch
git checkout -b master

# Rename the remote
git remote rename origin upstream

# Add the new repo target as origin remote
git remote add origin https://github.com/ctrlplusb/react-universally-redux.git

# Push master rebinding it to origin
git push -u origin master

# Remove the old incubator branch
git branch -d incubator/state/redux

#
# Now you can use the following workflow to update your repo...

# Fetch the latest changes from react-universally master
git fetch upstream

# Merge any new changes from upstream master
git merge upstream/master

# Fix the merge conflicts and commit

[cellis]

Have just checked out the new react-universally with config changes. Having a look and then will try to replay my relay changes into it.

[ctrlplusb]

Oki, we now have tons of branches, as pointed out by @codepunkt.

We will have to be very critical in considering the addition of any more, and we should even question the overhead of maintaining any of the existing ones if we feel over time that they don't have value.

I've amended the branch list above with the creator/owners of each respective branch. We can mix and match the owners down the line per any discussions.

It will be great to come up with a set of guidelines in maintaining these branches to ensure that none of them go stale, and that we achieve a decent upgrade/incubation strategy for each of them. I'll try get a base document together during some free time this week.

Let's give these branches a bit of time in incubation. I see @codepunkt has already started contributing towards their quality. Once we feel they are at a more mature state we can rename them to feature/category/name.

[ctrlplusb]

Proposal: delete postcss feature as it's covered in the sass feature. The others are CSS-in-JS imps which are standalone.

[ctrlplusb]

And... rename sass to postcss-sass

[strues]

I like the idea of condensing the two.

[ctrlplusb]

We have too many CSS-in-JS implementations I think.

I think we should choose one. styletron is heavily leaning itself as a universal targetted solution so perhaps this would be the most natural choice?

Sorry @lucianlature I know you have spent a lot of effort on all of these branches, but I am already seeing the complexity of management they bring to the table. I want to cut them right down to a few choice technologies.

[ctrlplusb]

Thoughts @strues @lucianlature @bkniffler @carsonperrotti @enten?

[ctrlplusb]

Perhaps we could reconsider the strategy and have the extensions hosted seperately.

I would be happy to link them from the official readme. @lucianlature so instead of deleting your branches we could recreate them on your github. I would appreciate you taking ownership of them as me maintaining the merging of them all takes some effort. :)

[ctrlplusb]

Thinking about it more and more I think the separate repo strategy may be the best. Then I don't need to limit anything, as anyone can create any extension they like and all I have to do is maintain a list of links. :)

It makes cloning off a target implementation far easier too.

[ctrlplusb]

Here is the workflow I used for creating my react-universally-redux repo:

# Clone required incubator branch into target new repo folder
git clone https://github.com/ctrlplusb/react-universally -b incubator/state/redux react-universally-redux

# Enter repo folder
cd react-universally-redux

# Create a master branch
git checkout -b master

# Rename the remote
git remote rename origin upstream

# Add the new repo target as origin remote
git remote add origin https://github.com/ctrlplusb/react-universally-redux.git

# Push master rebinding it to origin
git push -u origin master

# Set tracking of the master branch of react-universally
git branch --track up/master upstream/master

# Remove the old incubator branch
git branch -d incubator/state/redux

#
# Now you can use the following workflow to update your repo...

# Fetch the latest changes from react-universally master
git fetch upstream

# Merge any new changes from upstream master
git merge up/master

# Fix the merge conflicts and commit

[ctrlplusb]

Please let me know if you want to take ownership of any repos.

I am going to claim the apollo branch too.

[ctrlplusb]

Also, please try follow the example of react-universally-redux, i.e. have a small note at the top of the README.md that links to a FEATURE.md (sorry @lucianlature I told you BRANCH.md before). It's best to keep the README.md the same across them to avoid merge issues on prose, which is far trickier.

[ctrlplusb]

I might steal jest and styletron as I am going to use these two a lot moving forward. But will add you as a collaborators @strues and @lucianlature.

[lucianlature]

Ok, so that leaves me koa2, glamor and styled-components. Happy to host them in my GitHub account, but maybe some links from master's README.md could be also useful.

[ctrlplusb]

If you are happy to maintain them that would be awesome. :-)

Yeah follow the example I did in the react-universally-redux repo.

Also, you could consider the preact feature now ;)

[ctrlplusb]

I've added you as a contributor in the master repo.

[lucianlature]

Cool, cheers mate!

[codepunkt]

I liked the branches a lot more. When you try to combine things such as apollo, redux, glamor and jest to build a stack you like, you're basically fucked because you can't diff the repositories easily. Trying to integrate apollo into redux, it seems easier doing it on my own based on the redux repository as opposed to checking the related -apollo repository because i can't find out what code is related to apollo compared to the base repo.

[LorbusChris]

I was eyeballing styled-components, but is there even the slightest twist with styletron? Looks amazing!

@lucianlature If you could keep the koa2 branch alive for a little while that would be great! Thats definitely something I want to investigate further. Thanks for the great work :)

[ctrlplusb]

@codepunkt - the Apollo feature already includes redux. :-)

I hear what you are saying, but I think if you choose one rep from each category(state/style/test) you can still attach them as upstreams and merge them into your target project. The projects all have their commit history maintained too. I'll play with a couple of workflows in this regard and document it.

I'm sorry if it's a disappointment but I feel like having any more branches than what we had was gonna get noisy, and I like the openness that external repos provide. Each repo can then maintain their own master/next branches and issue lists etc. It's also easier for people to take ownership which takes workload off my plate.

Let's try find a happy medium. :-)

[LorbusChris]

@ctrlplusb talking about workflows...

If all the feature branches were to be built ON TOP of master, one could also use a rebase-based workflow approach for the feature branches. I've found this to be a little less annoying than merging, but one might loose some history and in order to update one needs to force push which is probably not something everybody is comfortable with.

[ctrlplusb]

Yeah here you.we need to play. The current workflow I have been using its essentially a similar experience as merging master into a branch. Git does a great job of taking into account previous merges etc.

I guess if you plan to break away from react-universally completely in a project - then a rebase is highly appealing.

[lucianlature]

@LorbusChris I'm using koa2 for my projects instead of express, so that branch will stay alive for a long time, hopefully.

As decided, I will take care of my branches in my account. Next to be released are the repositories for hapi support and preact integration instead of React, once they will be available I will drop the links.

[ctrlplusb]

@codepunkt

Ok, I managed to merge multiple repositories with minimal effort/issues. I only had to deal with 2 merge conflicts even. :)

In my case I used react-universally-apollo and react-universally-jest.

Workflow:

# Select your "primary" repository (generally a "state" category I think)
git clone react-universally-apollo my-project

# Rename the "origin" appropriately
git remote rename origin upstream/apollo

# Add your project's repo remote target
git remote add origin https://github.com/ctrlpusb/my-project

# Push the current code to it, rebinding the master branch to the "origin" remote.
git push -u origin master

# Now select whatever other features you would like.
# In my case I wanted "jest"
git remote add upstream/jest https://github.com/ctrlplusb/react-universally-jest

# Fetch the latest from it
git fetch upstream/jest

# Merge into your project
git merge upstream/jest/master

# Deal with the conflicts, commit and push.

# Then any time you want updates it is a matter of repeating the above two
# steps. For example:
git fetch upstream/apollo
git merge upstream/apollo/master

[ctrlplusb]

Merging the yarn files are a pain. I generally just select "merge all from theirs" and then kill the yarn file and run the yarn command again to rebuild it based on the current dependencies.

[lucianlature]

@ctrlplusb @LorbusChris

Created repositories for:

• koa2: https://github.com/lucianlature/react-universally-koa2
• Glamor: https://github.com/lucianlature/react-universally-glamor
• Styled Components: https://github.com/lucianlature/react-universally-styled-components

Now you can tick off from the list above these three items, and then add these links to Extensions paragraph in README.md. :)

[ctrlplusb]

Awesome work @lucianlature!

[ctrlplusb]

The styletron feature repo is live too.

I now have a project with apollo, jest, and styletron merged. :)

Working nicely so far! :)

[lucianlature]

Yep, same here ;)

Great stuff, I'm loving it!

[ctrlplusb]

@lucianlature please check out my styletron branch and let me know if you think it looks okay. Thanks.

https://github.com/ctrlplusb/react-universally-styletron

[lucianlature]

@ctrlplusb Looks good to me, sir 👍

[smirea]

is there a way to have the feature repositories be forks of this one instead?

It would be more useful in the sense that you'd be able to easily get a diff between feature repos and master

[ctrlplusb]

@smirea - actually, that makes a lot of sense.

Do you know if I can fork my own repo though?

[smirea]

oh... that's unfortunate, github doesn't apparently allow for you to fork yourself :| annoying. Well hopefully others do it with other feature branches ^^

[smirea]

it might be extra work, but what do you think about having a standard "canonical" branch on every feature repo, that gets updated whenever the feature repo is rebased? (that gets fast forwarded on every rebase) That way we can use the branch diff tool.

It might even be better since the diff would reflect more relevant changes - as opposed to a fork diff which would compare against the current HEAD that probably has upstream commits

[ctrlplusb]

Some great feedback @smirea

I'll do some investigation! :)

[LorbusChris]

The missings diffs are my main problem with that too.

However, you can rename a fork, see react-universally-found.

If one singular person can't maintain several forks of the same repo, maybe an organization can?

[ctrlplusb]

An organisation may be the way to go. Could be a cool option as all the features would be collocated then.

Currently you have to manually clone, add upstream remote and then do a git diff upstream/master.

[ctrlplusb]

Hmm, oki I tried creating an organisation and then forking within the org - it doesn't work. :(

Buuuut, if I moved react-universally into the org I could then fork the repo to produce feature repos.

[ctrlplusb]

The compare view of @LorbusChris's repo: https://github.com/ctrlplusb/react-universally/compare/master...LorbusChris:found

It is useful. :)

[ctrlplusb]

Would rebasing of the fork affect the compare view?

---

Edit: Can you even rebase a fork? One advantage of clones...

[ctrlplusb]

Forks feel like the simplest/sanest solution for now...

Yep, the compare may be running against a master that is ahead in terms of commits like you point out @smirea but I am afraid of complexity here.

Any other ideas chaps?

[ctrlplusb]

Argh, actually one other issue with forks: you can only fork a repo once. :(

Clones are unfortunately the only way forward, but perhaps we could bake in tooling that allowed you to view a diff?

Feels more complex than I would have liked though...

---

Update:

Ok, so there is pretty-diff.

We could bake in a script that could be executed, producing the diff. Down side - you have to clone the repo first.

Starting to feel that branches are easier... sigh.

[strues]

Hopefully I'm not derailing the conversation too much here. I've been skimming over the recent discussions and am wondering if it might be worth looking into writing the additional repos as a yeoman generator instead?

From everything we've been discussing, it honestly feels like we're doing everything we can to give the flexibility of a yeoman generator, without actually providing a yeoman generator.

[ctrlplusb]

@strues - please, derailing is welcome! :)

Hmm, I don't think generators quite have the same value here. In our current case we can merge together any of the repos (or branches) to suite our needs. With generators we would need to create pre-baked combinations to achieve the similar as I don't think we could rely on a script to execute merging automatically.

[ctrlplusb]

I have been looking at this more and more and I am going to do a 180 on this decision.

I'm sorry guys, it's my bad, I was a bit hasty in this decision without involving you all. I'll do the copy and pasting into branches. It will be much easier to manage the branches in the repo. I think we can have them follow the same strategy of having a FEATURE.md. I'll just need to add more collaborators to the project if need be.

I am going to change the branching strategy though. No more "incubation". It'll just be straight up "feature/branchname". This way it will feel much easier to grok and maintain the branches. We can use the PR system to prove updates to branches. It's the master branch which needs an "incubation" branch (i.e. next).

I humbly apologise to everyone!

@codepunkt - you were right! :)

I am going to start creating the branches for my feature repos now. I'll leave the repos be for now just in case someone comes up with an amazing strategy, but for now I think the simple branching strategy is the easiest for everyone to use all round.

[lucianlature]

Oooh maaaan... 😠

[ctrlplusb]

@lucianlature - I know I know - I am so sorry for wasting your time like this. But I think its better to do what is right for everyone. I am really really really sorry.

Don't worry about merging your branches. I am already doing it for you.

[lucianlature]

Could this help?

[ctrlplusb]

I don't think so no. :(