kicad-developers team mailing list archive

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

On Fri, Jan 17, 2020 at 4:46 PM Nick Østergaard <oe.nick@xxxxxxxxx> wrote:

> On Fri, 17 Jan 2020 at 17:18, Ian McInerney <Ian.S.McInerney@xxxxxxxx>
> wrote:
> >
> > There are 2 main issues I can see with rebasing:
> > 1) Rebuilding the history will change the commit hashes on master, which
> will throw off our 5.1 cherry-picked commit messages that refer to the
> master commit they came from (there are at least 4 that this would happen
> to).
>
> That is currently only two commits on 5.1
>

No, there are 4 on 5.1:
https://gitlab.com/kicad/code/kicad/commit/923dad6ca8abe62e4f1b8d6f096360c855649add
https://gitlab.com/kicad/code/kicad/commit/9f17d91b32013e5eaea385bf8f4ecd6f26732bdc
https://gitlab.com/kicad/code/kicad/commit/2bcb04a3b1b6792aa0cd77db79b87f812020d0f4
https://gitlab.com/kicad/code/kicad/commit/a530b600b88873227fd2c01a8965cdaca10b9f55


>
> > 2) The GitLab merge requests would be completely confused and each
> contributor would have to manually fixup their branches and force push to
> them to clean it up.
> >
> > For CI systems and the like, they can just do a shallow clone of the
> repo and avoid those commits (at this point we are already 14 commits ahead
> of the most recent (a clone of the last 5 commits is only 24.48MiB instead
> of the 204.37MiB for a full clone).
>
> This is not an issue, merge requests still need to be rebased when
> changes pop in to master.
>

The difference is where that will happen. Currently, merge requests are
rebased by the GitLab backend before the merge into master because the
histories are in-sync. If we rebase master, then the merge request will
have to be rebased manually first, and in a way that will be more difficult
for some contributors. You can't just use the `git rebase master devBranch`
command to fix it, since that will go back to the last unchanged commit
before the binary blobs, then replay all the contents of their branch since
then onto the current master - which will include the commits from master
itself that they picked up since the binary blobs. Not all of our
contributors have an enormous amount of experience using git, so that could
be difficult for them to do properly.

-Ian