kicad-developers team mailing list archive
Mailing list archive
Re: Rebase the tree?
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>
> > 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
> That is currently only two commits on 5.1
No, there are 4 on 5.1:
> > 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.