llvm dev - Oct 2019 - Phabricator picking up downstream commits from Github forks of llvm-project?

On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote:
> October 30, 2019 5:58 AM, "Alex L via llvm-dev" <llvm-dev at
lists.llvm.org> wrote:
>
>> Oh, this explains it! Unfortunately one of our engineers made a
mistake, and pushed the ref to
>> wrong remote while resolving a merge conflict on
https://github.com/apple/llvm-project (pushed to
>> https://github.com/llvm/llvm-project instead of
https://github.com/apple/llvm-project). I just
>> deleted the ref from the https://github.com/llvm/llvm-project. It's
weird that Phabricator decided
>> to pick this up, since it's not in the usual refs/heads namespace.
Hopefully now it will stop going
>> through those commits.
>> 
>> We will work on improving the process on our end to avoid mistakes like
this in the future.
>
> What's a good way to avoid these mistakes?
One way that I use to avoid accidentally pushing to the wrong repo, is to 
make sure that the "origin" remote (which is set as the upstream for
the
master branch, where pushes would go implicitly) is set up via an url that 
is (to me) read-only.

When dealing with github, I don't have a stored authenticated session for 
https, so to me, https://github.com/llvm/llvm-project is read-only (or, if 
I try to push there, it'd prompt me for username/password, which I'd 
notice). When pushing to github, I use ssh as transport, with urls like 
git at github.com:llvm/llvm-project, and add this as a separate remote that I 
only use for pushing. That forces me to explicitly spell out e.g. "git 
push <read-write-remote-name> master" to push there.

If access to github via https is authenticated already, one can choose to 
set the origin remote to a git://github.com/llvm/llvm-project url instead, 
which always is read only.

None of this helps against accidentally doing "git push <accidentally 
wrong remote name> <other branch>" though.

// Martin

On 10/30/2019 12:56 AM, Martin Storsjö via llvm-dev
wrote:
> On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote:
> 
>> October 30, 2019 5:58 AM, "Alex L via llvm-dev" <llvm-dev
at lists.llvm.org> wrote:
>>
>>> Oh, this explains it! Unfortunately one of our engineers made a
mistake, and pushed the ref to
>>> wrong remote while resolving a merge conflict on
https://github.com/apple/llvm-project (pushed to
>>> https://github.com/llvm/llvm-project instead of
https://github.com/apple/llvm-project). I just
>>> deleted the ref from the https://github.com/llvm/llvm-project.
It's weird that Phabricator decided
>>> to pick this up, since it's not in the usual refs/heads
namespace. Hopefully now it will stop going
>>> through those commits.
>>>
>>> We will work on improving the process on our end to avoid mistakes
like this in the future.
>>
>> What's a good way to avoid these mistakes?
> 
> One way that I use to avoid accidentally pushing to the wrong repo, is to
make sure that the "origin" remote (which is set as the upstream for
the master branch, where pushes would go implicitly) is set up via an url that
is (to me) read-only.
> 
> When dealing with github, I don't have a stored authenticated session
for https, so to me, https://github.com/llvm/llvm-project is read-only (or, if I
try to push there, it'd prompt me for username/password, which I'd
notice). When pushing to github, I use ssh as transport, with urls like git at
github.com:llvm/llvm-project, and add this as a separate remote that I only use
for pushing. That forces me to explicitly spell out e.g. "git push
<read-write-remote-name> master" to push there.
> 
> If access to github via https is authenticated already, one can choose to
set the origin remote to a git://github.com/llvm/llvm-project url instead, which
always is read only.
> 
Having origin be read-only and using another remote for pushing is a good idea.
The other recommendation I have is to always explicitly specify the remote and
the source and destination branches when pushing e.g.

git push origin master:master

or if you are using a separate remote for github as recommended above:

git push llvm-github master:master

This way it is always clear exactly what and where you are pushing.  It
seems like the a lot of the issues we've had so far with people pushing
extra tags and refs is that they are using `git push` with no arguments
and the default configuration is pushing things that aren't expected.

-Tom

> None of this helps against accidentally doing "git push
<accidentally wrong remote name> <other branch>" though.
> 
> // Martin
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Oct 30, 2019, at 5:51 PM, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 10/30/2019 12:56 AM, Martin Storsjö via llvm-dev wrote:
>> On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote:
>> 
>>> October 30, 2019 5:58 AM, "Alex L via llvm-dev"
<llvm-dev at lists.llvm.org> wrote:
>>> 
>>>> Oh, this explains it! Unfortunately one of our engineers made a
mistake, and pushed the ref to
>>>> wrong remote while resolving a merge conflict on
https://github.com/apple/llvm-project (pushed to
>>>> https://github.com/llvm/llvm-project instead of
https://github.com/apple/llvm-project). I just
>>>> deleted the ref from the https://github.com/llvm/llvm-project.
It's weird that Phabricator decided
>>>> to pick this up, since it's not in the usual refs/heads
namespace. Hopefully now it will stop going
>>>> through those commits.
>>>> 
>>>> We will work on improving the process on our end to avoid
mistakes like this in the future.
>>> 
>>> What's a good way to avoid these mistakes?
>> 
>> One way that I use to avoid accidentally pushing to the wrong repo, is
to make sure that the "origin" remote (which is set as the upstream
for the master branch, where pushes would go implicitly) is set up via an url
that is (to me) read-only.
>> 
>> When dealing with github, I don't have a stored authenticated
session for https, so to me, https://github.com/llvm/llvm-project is read-only
(or, if I try to push there, it'd prompt me for username/password, which
I'd notice). When pushing to github, I use ssh as transport, with urls like
git at github.com:llvm/llvm-project, and add this as a separate remote that I
only use for pushing. That forces me to explicitly spell out e.g. "git push
<read-write-remote-name> master" to push there.
>> 
>> If access to github via https is authenticated already, one can choose
to set the origin remote to a git://github.com/llvm/llvm-project url instead,
which always is read only.
>> 
> 
> Having origin be read-only and using another remote for pushing is a good
idea.
> The other recommendation I have is to always explicitly specify the remote
and
> the source and destination branches when pushing e.g.
> 
> git push origin master:master
> 
> or if you are using a separate remote for github as recommended above:
> 
> git push llvm-github master:master
> 
> This way it is always clear exactly what and where you are pushing.  It
> seems like the a lot of the issues we've had so far with people pushing
> extra tags and refs is that they are using `git push` with no arguments
> and the default configuration is pushing things that aren't expected.
FYI, the following configuration option is useful:

git config --global push.default nothing

It forces one to always be explicit when using git-push.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191031/264174f4/attachment.html>