0

I have forked on github a public repository, created a branch that fixes an issue and submitted a pull request which was accepted. Now I want to update my fork to the latest version of the public repository which has got 100+ commits since then. Since my change was accepted I simply want to fetch the latest repository without merging anything from my own fork. Then I want to create a new feature branch on the latest version to submit further fixes.

I have read several posts e.g.

which deal with that issue but that is far away from simple because git wants me to merge every single commit which it cannot automerge. I have changed on my fork one or two files but git wants me to merge hundreds of files on my fork. That cant be right.

I did for my PerfView clone basically

  1. git clone https://github.com/Alois-xx/perfview.git
  2. git remote add upstream https://github.com/Microsoft/perfview.git
  3. git fetch upstream
  4. git checkout master
  5. git rebase upstream/master

I then get a warning that I need to merge things one by one for hundreds of files. 

C:\Source\git\PerfView_Fork\perfview>git rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: Updated HtmlJS directory to contain a stock ASP.NET 5 Service.  We can use this to build the back end of the cross platform version of PerfView.
.git/rebase-apply/patch:9414: trailing whitespace.
The basic architecture for the app is there are two processes
.git/rebase-apply/patch:9416: trailing whitespace.
   1. One that acts as a 'back end' that acts as a data model.
.git/rebase-apply/patch:9417: trailing whitespace.
    This has no user interface and communiates to the UI by
.git/rebase-apply/patch:9419: trailing whitespace.
        (that is a REST API)  This is responsible for all data.
.git/rebase-apply/patch:9424: trailing whitespace.
   2. A second process that
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M       src/HtmlJs/documentation/DesignBasics.md
M       src/HtmlJs/documentation/DevNotes.md
M       src/PerfView/Properties/AssemblyInfo.cs
A       src/PerfView/SupportDlls/UsersGuide.htm
Falling back to patching base and 3-way merge...
Auto-merging src/PerfView/Properties/AssemblyInfo.cs
CONFLICT (content): Merge conflict in src/PerfView/Properties/AssemblyInfo.cs
Auto-merging src/HtmlJs/PerfDataService/Views/static/help.html
Patch failed at 0001 Updated HtmlJS directory to contain a stock ASP.NET 5 Service.  We can use this to build the back end of the cross platform version of PerfView.
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

I have tried Visual Studio which also follows the git workflow where I have to deal with every single merge error. That should be a common issue to skip merging and simply take the branch as is from the master but I was unable to find a satisfying solution so far.

Why should I even need to merge files which I did never touch on a branch (main) to which I never did any commit at all? That makes no sense to me. The Visual Studio merge dialog shows me

enter image description here

What is Source and Target? I would expect to see as source

https://github.com/Microsoft/perfview.git/master

and Target

https://github.com/Alois-xx/perfview.git/master

That would be helpful to not blindly merge the wrong thing. What is really disturbing me that the merge tool expects me to take a decision for every single file. There seems at least in Visual Studio no option to simple take everything from Source and be done with it.

What is the magic command line looking to do a bulk update of my fork without needing to merge manually hundreds of files? 

git merge -Xtheirs ... ?

I have tried to create a pull request for my fork but github also complains about manual merges which are necessary. The easiest thing would be to delete my fork and recreate it but since we have version control there should be an easy way.

Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
  • @downvoter: Care to comment? If I have made an error which is obvious to everyone else I would like to know how to fix this. – Alois Kraus Jan 03 '18 at 11:15

2 Answers2

0

The easiest way was actually to clone both repositories into different directories.

  • Fork/Repo
  • Orig/Repo

Then I did delete everything in Fork/Repo except the .git directory and then I did copy the contents of Orig/Repo into my fork (except the .git directory) which I then committed.

That is easy and if one does a rebase while merging nothing you get the history of commit messages without saving the actual contents. When you update the fork you have one commit which contains all changes together which is nice if you want to see changes since the last fork.

Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
-2

Sorry, I did not read carefully.

I want to create a new feature branch on the latest version to submit further fixes.

...

git clone https://github.com/Alois-xx/perfview.git
git remote add upstream https://github.com/Microsoft/perfview.git
git fetch upstream

git checkout -b next_feature upstream/master
<code, commit>
git push origin next_feature
<submit PR in github from Alois-xx:next_feature to Mictosoft:master>

Most people (unless they really intend to fork the software and provide it to own users) do not need to do any "fork maintenance". Particularly, it is not needed to push branches to create PRs to upstream repository.

max630
  • 8,762
  • 3
  • 30
  • 55
  • 1
    Yes it is not needed to push branches back. But it should be pretty common to fork a repository, create a feature branch and create from that a PR. At least https://help.github.com/articles/creating-a-pull-request/ tells me to do that. But now my fork is dated and I wanted to update it which should be easy to do. So far it seems not to be the case. – Alois Kraus Jan 03 '18 at 23:23