FWIW, my Git tried to add the two files again (I guess from its local history). I think I caught it in time and cancelled.
I then rebased without the two commits, and without Ian’s commits to remove them (which were also in my history). So I think I’m up-to-date now, but if someone could check to make sure I didn’t bungle it again that would be great. Cheers, Jeff. > On 20 Jan 2020, at 23:43, Wayne Stambaugh <stambau...@gmail.com> wrote: > > No problem. Hopefully it wont cause too many issues for other devs who > have to rebase any local changes. > > Cheers, > > Wayne > > On 1/20/20 6:15 PM, Jeff Young wrote: >> Thanks, Wayne! >> >> Sorry for causing such a mess. >> >> Cheers, >> Jeff. >> >> >>> On 20 Jan 2020, at 22:32, Wayne Stambaugh <stambau...@gmail.com> wrote: >>> >>> I found it. I had to create a new protection for the master branch. I >>> pushed the changes and enabled the GitLab protection for the master >>> branch so we should be good to resume normal development. Thank you for >>> the help and patience to work through this. >>> >>> Cheers, >>> >>> Wayne >>> >>> On 1/20/20 5:27 PM, Nick Østergaard wrote: >>>> It should be there, I am sure you are just confused by the gitlab webui. >>>> >>>> It should be something along the lines of: >>>> Settings -> Repository -> Protected branches, click expand. Set the >>>> proper settings in the "Protect a branch" section. >>>> >>>> On Mon, 20 Jan 2020 at 23:26, Wayne Stambaugh <stambau...@gmail.com> wrote: >>>>> >>>>> Well this is a kick in the teeth. I just unprotected it and I don't see >>>>> an option to re-enable the protection after I force the changes. >>>>> >>>>> On 1/20/20 5:18 PM, Nick Østergaard wrote: >>>>>> There is a "protected branches" section in the settings of the repo. >>>>>> >>>>>> On Mon, 20 Jan 2020 at 23:18, Nick Østergaard <oe.n...@gmail.com> wrote: >>>>>>> >>>>>>> You probably need to disable the option to disable force pushing on the >>>>>>> repo. >>>>>>> >>>>>>> On Mon, 20 Jan 2020 at 23:20, Wayne Stambaugh <stambau...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> GitLab rejected the forced push using this method. Anyone else have >>>>>>>> any >>>>>>>> ideas. Until we get this resolved, please do not push any commits to >>>>>>>> the master branch. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Wayne >>>>>>>> >>>>>>>> On 1/20/20 5:13 PM, Wayne Stambaugh wrote: >>>>>>>>> Please do not push anything to the master branch or perform any merge >>>>>>>>> requests until I push the rebase the master branch to prevent any >>>>>>>>> commit >>>>>>>>> losses because forcing a push will wipe out any changes. I ran the >>>>>>>>> git >>>>>>>>> command suggested by Simon and it seems to have the desired results >>>>>>>>> but >>>>>>>>> I have no idea how this is going to play out so I'm making a backup >>>>>>>>> clone of master just in case things go sideways. I'll ping everyone >>>>>>>>> once I have pushed the rebase. Thank you for your cooperation and I >>>>>>>>> apologize for whatever pain and agony this causes. Hopefully we will >>>>>>>>> never make this mistake again. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Wayne >>>>>>>>> >>>>>>>>> On 1/18/20 7:29 AM, Simon Richter wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 17.01.20 19:14, Simon Richter wrote: >>>>>>>>>> >>>>>>>>>>> 1. "git rebase -i origin/master" >>>>>>>>>>> 2. in the editor, if they are present, remove the lines >>>>>>>>>>> >>>>>>>>>>> pick ea31730b4 Handle error returns from lstat. >>>>>>>>>>> pick e83420f19 Remove file accidentally commited in ea31730b4 >>>>>>>>>>> pick e27e6ee16 Also catch null dereference in case wxASSERT was >>>>>>>>>>> skipped. >>>>>>>>>>> pick e1925b89c Remove file accidentally added in e27e6ee1 >>>>>>>>>>> >>>>>>>>>>> 3. save and exit >>>>>>>>>> >>>>>>>>>> Even less interactive: >>>>>>>>>> >>>>>>>>>> git filter-branch \ >>>>>>>>>> --prune-empty \ >>>>>>>>>> --index-filter \ >>>>>>>>>> 'git rm --cached --ignore-unmatch common/libcommon.a.*' \ >>>>>>>>>> 9df2cfb32..HEAD >>>>>>>>>> >>>>>>>>>> This rewrites the current branch to a state where the files were >>>>>>>>>> never >>>>>>>>>> added, and removes the now-empty correction commits. The SHA1 sums in >>>>>>>>>> the new branch are different, but as the commit contents are >>>>>>>>>> identical, >>>>>>>>>> rebasing feature branches then goes smoothly even from the gitlab >>>>>>>>>> GUI. >>>>>>>>>> >>>>>>>>>> If you rebased a branch containing the offending commits on top of a >>>>>>>>>> cleaned one, this generates four commits adding and removing the >>>>>>>>>> files >>>>>>>>>> with no further changes, and the filter-branch commit above then >>>>>>>>>> reduces >>>>>>>>>> these to no-ops and removes the commits. >>>>>>>>>> >>>>>>>>>> A simple test in gitlab *merge request is descended from e1925b89c" >>>>>>>>>> could identify merge requests that would need to be rewritten. >>>>>>>>>> >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
