Thanks, I'll take a closer look. This branch still has conflicts; you'll need to make sure you are creating a branch from the latest main branch here, which usually involves pulling from upstream, merging into your forked repository, rebasing your branch, then pushing it again.

This doesn't really impact #29. Each of the subdomains are their own "app" with separate repositories. Layout updates would need to be applied to them separately.

This branch still has conflicts; you'll need to make sure you are creating a branch from the latest main branch here, which usually involves pulling from upstream, merging into your forked repository, rebasing your branch, then pushing it again.

I tried that. It didn't work. The posh branch of my fork was still "x commits ahead, and x commits behind" the upstream, according to github. I then tried further incantations that I found on the web. I thought I finally got it right, but apparently not.

/sigh

I clearly don't yet have a handle on git. (You no doubt saw that I just recreated the fix-alt-tag branch because I couldn't fix the first one.)

@btrem Sorry, I know it can be frustrating! I'm only an intermediate on some git things myself and still novice at others.

When I visit your main branch, it looks like it's "up to date with microformats/microformats.io:main", which is good! I think the easiest thing now might be to create a new branch from your main, re-apply these changes, and submit a new PR.

Going forward, to avoid the ahead/behind issue, my (novice) recommendation would be to wait until a PR is merged into this repo, then use the Github web UI to sync your fork. That should get your main branch back to the "up to date with microformats/microformats.io:main" status. At that point, you can git pull from your fork's main to get the latest code locally, then you can create a branch for the next PR. If you do the PRs sequentially like this, it should avoid the "ahead/behind" issues.

It's possible to do multiple PRs "at the same time," but each time one PR gets merged your subsequent PRs most likely will need to be git rebase so their commit history is on top of the new merge. I don't know the best way to describe that process, though.

@gRegorLove I can imagine why it's happening, but have not yet figured out how to fix it. I gave up on gitcola/dag, which doesn't seem to offer a graph view of multiple branches. I'm trying gittyup. That has been an improvement.

In the meantime, I'm going to recreate my work in this branch, but I'm breaking up the work so you can more easily see what has changed, and whether you want to incorporate them.