1

(Note: I strongly suspect my issue here is that I don't know what term to search for, it's very possible that the terms I'm using and what I actually want are different things. Pleas don't assuming too much based on the terms I used.)

Edit: All of the following is with regards to remote. (For the sake of discussion; assume that at the start, no local clients exist anywhere and, once I'm done, any local client created will be deleted.)

I created a fork, created a PR, that was merged into upstream and I attempted a rebase. But now when I look at the branches I intend to continue using (e.g. master), they show as being a merge of upstream/master and the stuff I did in my fork, and that despite having no changes that don't come from upstream.

What I want is to have my fork's master, when viewed on GitHub, reflect reality and show as having only upstream/master in its history. That is:

GitHub "Network" view and what I want to make happen

If I didn't mind losing the rest of the history, I could accomplish this by deleting the entire repository and starting over, but that seems rather drastic for such a routine and necessary operation (and that won't work at all if I had other branches with ongoing work).

RJFalconer
  • 10,890
  • 5
  • 51
  • 66
BCS
  • 75,627
  • 68
  • 187
  • 294
  • 1
    I'm not clear on whether you have changes in your local `master` branch that you want to apply on top of the remote `master` or if you just want your `master` to be the same as the remote. The former is potentially complex depending on the exact state you're in. The latter is just a reset: `git reset upstream/master`. – Calum Halpin Mar 04 '20 at 22:32
  • The current content of all files in origin/master is the same as upstream/master. -- When I attempt `git reset upstream/master ; git push origin master` I get "Updates were rejected because the tip of your current branch is behind its remote counterpart." – BCS Mar 04 '20 at 22:51
  • 1
    You can resolve that with a force push but your probably shouldn't unless you're the only one working on your fork. – Calum Halpin Mar 04 '20 at 23:23

1 Answers1

1

What I want is to have my fork's master, when viewed on GitHub, reflect reality and show as having only upstream/master in its history

If I understand correctly, that isn't reality. The history of your fork begins from the point you made the fork, not from where the remote master is. Your fork will run forever in parallel with the remote, with forward/backward merges as necessary.

When I git reset upstream/master ; git push origin master I get "Updates were rejected because the tip of your current branch is behind its remote counterpart."

The short answer is that you can accomplish what you want with git push origin master -f, effectively killing the history of your fork, and disrupting other people who may be working on your fork.

What you describe sounds more like the workflow you'd have if you were a contributor on the remote directly, making a new branch for each feature.

My understanding for context: crude diagram made in www.draw.io/

Top is a typical fork workflow, bottom is the workflow you'd follow if you were developing independent feature branches as a contributor on the remote. Red is a (perfectly valid) commit on the fork's master, following a merge to remote.

RJFalconer
  • 10,890
  • 5
  • 51
  • 66
  • Your diagram is what I'm expecting to do. -- The reality to be reflected is that I will be creating multiple "work items" where each one's history starts from some point in upstream/master's history (and that starting point *won't* be a merge from my repo). I expect that those work items will depend on each other, but only through upstream. -- But how to do that? Maybe have a repo where only named branches are used and master is permanently ignored (https://stackoverflow.com/questions/4410091)? Or maybe where master doesn't even exist? – BCS Mar 05 '20 at 01:45
  • https://github.com/github/hub/issues/1553 I don't think it's possible to do what you want to do on github I'm afraid. Outside github, you'd just create branches in the repository, rather than having to deal with forks. – RJFalconer Mar 05 '20 at 02:41