Did someone already do this? I just checked the github repo and the latest commit hash is correct.
On 1/20/20 5:46 PM, Ian McInerney wrote: > The GitHub mirror will also need to be force pushed for its first > update, since it looks like it got the first of the large files already > mirrored to it and it was choking on the second of the files. > > -Ian > > On Mon, Jan 20, 2020 at 10:25 PM Simon Richter <simon.rich...@hogyros.de > <mailto:simon.rich...@hogyros.de>> wrote: > > Hi Wayne, > > On 20.01.20 21:25, Wayne Stambaugh wrote: > > > If I run the commands Simon suggested to remove the blobs, what does > > this mean for devs who pull from the dev repo on gitlab? > After fetching normally, using > > $ git fetch > > anyone who doesn't have local work on top can just reset their > branch, using > > $ git reset --keep origin/master > > to pivot over. The --keep option makes sure that no local changes are > overwritten, and complains if it would do so. > > If they have local work, the sanest approach is to rebase on top of > origin/master and delete the offending commits at the same time by doing > an interactive rebase > > $ git rebase -i origin/master > > This gives a list of all commits that don't have identical content in > the old and new history. Since the filtered branch is the same except > for those four, the first four lines will be > > 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 > > and all local changes will follow those. You can either delete these > lines from the todo list, or replace the work "pick" by "drop". > > The approach using "git filter-branch" is not recommended for normal > developers, because it generates another alternate history that needs to > be resolved by calling "git rebase origin/master", and when you're > rebasing anyway, you can also remove the commits at that point. > > Wayne, if you want to avoid filter-branch, you can also use an > interactive rebase: > > $ git rebase -i 9df2cfb32 > > In the list, move the correction commits under the commits they fix, and > replace "pick" by "fixup". The first six lines should read > > pick ea31730b4 Handle error returns from lstat. > fixup e83420f19 Remove file accidentally commited in ea31730b4 > pick b3af41e1b RTree: Fix iterator in single branch trees > pick e27e6ee16 Also catch null dereference in case wxASSERT was > skipped. > fixup e1925b89c Remove file accidentally added in e27e6ee1 > pick 7399465fd Handle nullptr. > > i.e. line 2 becomes "fixup", lines 5 and 6 are swapped, and line (now) 5 > also becomes "fixup". > > Both this method and the filter-branch method alter the committer name > and date in the new history, so the commit IDs are not reproducible. > > Anyone but Wayne can of course run the same commands and get commits > with identical contents but different ID, which a normal rebase will > clean up nicely. > > The merge request workflow probably doesn't have to change (much), since > we rebase changes before merging them, for these the same interactive > rebase as above works. > > Simon > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto: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
