kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

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.Richter@xxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>