Resetting GitLab Fork

[Robert Lancaster]

Hi Hans,

Yes, I probably should work in a branch before putting it on my fork on Gitlab.  If that avoids this issue, it might really be the way to go.  I haven’t done that in the past when using Phabricator or Github because I could always just reset my fork once I send in the pull request or changes.  Apparently Gitlab doesn’t have the same flexibility.

I just went ahead and deleted my fork again and reforked kstars.  I would like to know if there is a way to do it though.

Thanks,

Rob

> On Oct 13, 2020, at 5:34 PM, Hans <hans at lambermont.dyndns.org> wrote:
> 
> Hi Rob,
> 
> Robert Lancaster wrote on 20201013:
>> I made some changes in my fork yesterday to support load and slew.  I
>> committed the changes, sent them to GitLab and sent Jasem a merge request.
> 
> Were those changes in your fork on master or did you make a branch to work on ?
> 
>> He found a more efficient way to write my method, so he did incorporate my
>> changes, but he did it a little differently than in my merge request.
> 
> And those changes are now on the master branch in the repo which you forked from.
> 
>> So now I need to update my fork to match master again with his changes not
>> mine.
> 
> Clear.
> 
>> I found a couple of different ways to do it online, and I was able to
>> fix my local copy and update it to the upstream master, but most of them say
>> to do the command "git push origin master —force” at the end to send my
>> changes to the fork on GitLab, but this didn’t work, it rejected it.
> 
> I do not like the force part in there.
> 
>> The other day I had a very similar problem, so I finally ended up deleting my
>> fork and making a new one, but I think there should be a way to do it without
>> having to go that far.  Does anyone know how to do this?
> 
> I prefer to work in a branch in my fork of the repo, so that I can update the
> master branch always clean from the master repo.
> 
> Did you solve your problem btw ?
> 
> -- Hans