please add link / url to remote - when - git push

> When a feature branch is pushed, we get a link in the console to go to
> remote, however when I push directly to main/master, no such link, eg:
>
> ```
> alex.mills@alex node-be % git push
> Enumerating objects: 20, done.
> Counting objects: 100% (20/20), done.
> Delta compression using up to 12 threads
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (11/11), 1.56 KiB | 799.00 KiB/s, done.
> Total 11 (delta 7), reused 0 (delta 0), pack-reused 0
> remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
> remote: Bypassed rule violations for refs/heads/main:
> remote:
> remote: - Changes must be made through a pull request.
> remote:
> To github.com:elx-onlinx/beautychat-chatcards.git
>    ffe1e05..bb7b0ef  main -> main
> ```
>
> Having the link in the console saves me tremendous time and is
> extremely effective/efficient. Can we get links in the console plz?
>

> On Sun, Oct 29, 2023 at 06:15:35PM -0500, Alexander Mills wrote:
>> When a feature branch is pushed, we get a link in the console to go to
>> remote, however when I push directly to main/master, no such link, eg:
>>
>> ```
>> alex.mills@alex node-be % git push
>> Enumerating objects: 20, done.
>> Counting objects: 100% (20/20), done.
>> Delta compression using up to 12 threads
>> Compressing objects: 100% (10/10), done.
>> Writing objects: 100% (11/11), 1.56 KiB | 799.00 KiB/s, done.
>> Total 11 (delta 7), reused 0 (delta 0), pack-reused 0
>> remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
>> remote: Bypassed rule violations for refs/heads/main:
>> remote:
>> remote: - Changes must be made through a pull request.
>> remote:
>> To github.com:elx-onlinx/beautychat-chatcards.git
>>    ffe1e05..bb7b0ef  main -> main
>> ```
>>
>> Having the link in the console saves me tremendous time and is
>> extremely effective/efficient. Can we get links in the console plz?
>>
>
> If we look very carfully at the log, we see that all the messages prefixed
> with "remote:" come from the remote (git server).
> In your case github. Other "Git repo servers" like gitlab or bitbucket have
> the same feature.
>
> Git itself, running on your local computer, does not produce this links.
> If you really want to push directly to the main branch and want to see the
> a link, then you better talk to the gihub folks.

> On Sun, Oct 29, 2023 at 06:15:35PM -0500, Alexander Mills wrote:
> > When a feature branch is pushed, we get a link in the console to go to
> > remote, however when I push directly to main/master, no such link, eg:
> >
> > ```
> > alex.mills@alex node-be % git push
> > Enumerating objects: 20, done.
> > Counting objects: 100% (20/20), done.
> > Delta compression using up to 12 threads
> > Compressing objects: 100% (10/10), done.
> > Writing objects: 100% (11/11), 1.56 KiB | 799.00 KiB/s, done.
> > Total 11 (delta 7), reused 0 (delta 0), pack-reused 0
> > remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
> > remote: Bypassed rule violations for refs/heads/main:
> > remote:
> > remote: - Changes must be made through a pull request.
> > remote:
> > To github.com:elx-onlinx/beautychat-chatcards.git
> >    ffe1e05..bb7b0ef  main -> main
> > ```
> >
> > Having the link in the console saves me tremendous time and is
> > extremely effective/efficient. Can we get links in the console plz?
> >
> 
> If we look very carfully at the log, we see that all the messages prefixed
> with "remote:" come from the remote (git server).
> In your case github. Other "Git repo servers" like gitlab or bitbucket have
> the same feature.
> 
> Git itself, running on your local computer, does not produce this links.
> If you really want to push directly to the main branch and want to see the
> a link, then you better talk to the gihub folks.

> > If we look very carfully at the log, we see that all the messages prefixed
> > with "remote:" come from the remote (git server).
> > In your case github. Other "Git repo servers" like gitlab or bitbucket have
> > the same feature.
> > 
> > Git itself, running on your local computer, does not produce this links.
> > If you really want to push directly to the main branch and want to see the
> > a link, then you better talk to the gihub folks.
> 
> On the other hand, option to NOT display those remote messages is also
> missing. At least with git 2.35 they are displayed even when -q argument
> is given.

> On Mon, Oct 30, 2023 at 09:52:05AM +0100, Michal Suchánek wrote:
> 
> > > If we look very carfully at the log, we see that all the messages prefixed
> > > with "remote:" come from the remote (git server).
> > > In your case github. Other "Git repo servers" like gitlab or bitbucket have
> > > the same feature.
> > > 
> > > Git itself, running on your local computer, does not produce this links.
> > > If you really want to push directly to the main branch and want to see the
> > > a link, then you better talk to the gihub folks.
> > 
> > On the other hand, option to NOT display those remote messages is also
> > missing. At least with git 2.35 they are displayed even when -q argument
> > is given.
> 
> That is also up to GitHub to fix on the server side:
> 
>   https://lore.kernel.org/git/20230519090559.GA3515410@coredump.intra.peff.net/

> > > On the other hand, option to NOT display those remote messages is also
> > > missing. At least with git 2.35 they are displayed even when -q argument
> > > is given.
> > 
> > That is also up to GitHub to fix on the server side:
> > 
> >   https://lore.kernel.org/git/20230519090559.GA3515410@coredump.intra.peff.net/
> 
> If the server did not reject the push the messages it returns could be
> considered informational.

> On Mon, Oct 30, 2023 at 10:30:23AM +0100, Michal Suchánek wrote:
> 
> > > > On the other hand, option to NOT display those remote messages is also
> > > > missing. At least with git 2.35 they are displayed even when -q argument
> > > > is given.
> > > 
> > > That is also up to GitHub to fix on the server side:
> > > 
> > >   https://lore.kernel.org/git/20230519090559.GA3515410@coredump.intra.peff.net/
> > 
> > If the server did not reject the push the messages it returns could be
> > considered informational.
> 
> Hmm, yeah, I could perhaps buy that line of argument. Though it's
> possible they are "warnings" of the sort that should still be emitted
> with "--quiet"; really only the server knows. And note that even "reject
> the push" is not necessarily all-or-nothing. The server may accept some
> subset of the refs.
> 
> But...
> 
> > Not sure if the final status of the push is available or of the
> > rejection is only noted in these messages, though.
> 
> Yes, this is a problem. Those messages are streamed out as we receive
> them from the server, and before we get any status report back. I don't
> think we'd want to buffer them, as they can be arbitrarily large (and
> may even be progress reports that are meant to be shown in real-time).

> > Yes, this is a problem. Those messages are streamed out as we receive
> > them from the server, and before we get any status report back. I don't
> > think we'd want to buffer them, as they can be arbitrarily large (and
> > may even be progress reports that are meant to be shown in real-time).
> 
> Not when the user asked to not show progress.

> On Mon, Oct 30, 2023 at 10:45:56AM +0100, Michal Suchánek wrote:
> 
> > > Yes, this is a problem. Those messages are streamed out as we receive
> > > them from the server, and before we get any status report back. I don't
> > > think we'd want to buffer them, as they can be arbitrarily large (and
> > > may even be progress reports that are meant to be shown in real-time).
> > 
> > Not when the user asked to not show progress.
> 
> Sure, if you make the buffering behavior dependent on the presence of
> "-q". I guess that is not that hard to do, but it does increase the
> complexity of the code (you have both a streaming and a buffering code
> path).
> 
> Anyway, I am not all that convinced this is a fruitful path versus just
> fixing the server side. But if you want to look into writing a patch, go
> for it.