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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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