On May 23, 2019, at 03:13, Chris Jones wrote:
> On 22/05/2019 10:41 pm, Jann Röder wrote:
>> On 22/05/2019 at 22:37 Joshua Root wrote:
>>>
>>> Discussion on IRC indicates it was done from the GitHub web UI.
>>>
>> The github app. I don't think you can even rebase in that.
>
> If that is indeed the case (although it would seem strange to me to not have
> such a commonly used feature), then we should recommend not using it,
> certainly for MacPorts related work.
I use the GitHub Desktop app. It is nice to have a graphical display of
differences and to be able to select which ones to commit. Do you have a
suggestion for something I should use instead?
I believe I have run into this same problem once before. I believe I had
committed a change to master locally and I wanted to push it, so I clicked the
button that is usually "push", but I had not realized that GitHub Desktop had
changed the "push" button to a "fetch" or maybe "pull" button because it had
detected that there were upstream changes. Unbeknownst to me, pressing this
button caused a merge to happen. Since it simply appeared to me as though
pressing the button had not done anything, I pressed the "push" button again,
which then published my unintended merge.
For myself, whenever I use git, I have worked around the problem by not working
on master whenever possible, for repositories where I expect others to be
pushing changes to master. For simple changes I want to make directly to
master, I avoid using git, and instead use the GitHub Subversion bridge to
commit my changes, since I have a better understanding of how Subversion works;
for more complicated changes, I make a new git branch and publish it and create
a pull request so that I can confirm the changes on the GitHub web interface
before merging the PR.
~
Something else: the massive merge commit did schedule buildbot builds for every
port in the merge. So that's another reason to try to avoid merge commits. We
don't want to schedule builds for ports that don't need to be built.
