Unintentional double commits

[Rainer Müller]

On 2016-12-21 11:41, Andrea D'Amore wrote:
> While trying to push a small change (shell/xonsh) I managed to rebase
> AND merge the about 300 commits since my previous update,
> as a results those 300 commits in master now are "duplicated".
> 
> The files in master are unaltered, except for the actual portfile I
> was pushing, but the history is now messier.
> 
> 
> I've been checking on IRC how to address this for last two hours, I
> had the dilemma that force pushing to the commit before mine would
> clean the history but at the same time break workflow for users that
> may already have fetched the changes.

The recommend 'git pull --rebase' could probably cope with a reset to an
older history state, as long as all real changes on top of the old
master are preserved. On rebasing, commits that have been applied before
will be skipped by default.

However, the cronjob generating ports.tar is still checking out the
ports tree from the repository via the Subversion mirror [1]. As this
script seems to rely on a monotonically increasing revision number,
I am afraid to break the tarball generation with force-pushing a reset
to the previous history state.

Hint: we should rewrite the mprsyncup script to use git.

> I couldn't get hold of anybody on #macports to double check this so
> I'm not calling the shot since the messier history doesn't actually
> break the workflow.
> 
> 
> I apologize for the error, I'm really sorry for the confusion and
> noise it will trigger in tickets.

I guess we have to live with this history...

Rainer

[1]
https://github.com/macports/macports-infrastructure/blob/master/jobs/mprsyncup