Idea: advertise current tip of branch in refs/for/<branch> special refs

Gert van Dijk

unread,

Apr 8, 2018, 10:05:03 AM4/8/18

to Repo and Gerrit Discussion

Hi,

I've been thinking about the following feature request for a while, but I wanted to share/exchange some thoughts first here on the list.

When pushing your changes for review to any of the special remote refs (refs/for/*), it is always reported to be a completely new branch (and you cannot fetch from it). I see the point for this special ref, but my suggestion here is that we advertise the current branch' tip there, as if it's refs/heads/*. I presume it would help the Git client to ...:

understand what would have been pushed with a dry-run (git push -n).
Currently, a dry-run push is not functional with a special ref. You don't know upfront what commits would become a change in Gerrit. Accidentally pushing to the wrong special ref might create huge amounts of changes (only limited by receive.maxBatchChanges). Having the output of a dry-run push allows a user to prevent errors.
report a push of outdated changes before it's created a change in Gerrit.
Refuse a non-fast-forward update just like pushing to refs/heads/*. This would avoid unnecessary rebase patch sets if the user sees it later in the UI (might even see a Merge Conflict status directly after push).

(To not break current functionality, we could allow force pushing to still allow creating outdated changes.)

So, currently, I see only wins by implementing this, yet breaking the current behaviour a bit.

Would this be a valid feature request or am I asking something impossible?

Thanks,

Gert

Jonathan Nieder

unread,

Apr 8, 2018, 6:28:09 PM4/8/18

to Gert van Dijk, Repo and Gerrit Discussion

> Would this be a valid feature request or am I asking something impossible?

As you mentioned, this would interact poorly both with the ordinary compare-and-swap that is part of all pushes and with the fast-forward check that is part of non --force pushes. In an active project this makes it a non-starter.

That said, the Git project is working on allowing pushes for review to the refs/heads/master branch, which I think would yield the benefits you are talking about. This requires relaxing the compare-and-swap check so it is a protocol change.

Thanks and hope that helps,

Jonathan

вс, 8 апр. 2018 г. в 7:05, Gert van Dijk <gert...@gmail.com>:

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Darragh Bailey

unread,

Apr 9, 2018, 5:49:32 AM4/9/18

to Gert van Dijk, Repo and Gerrit Discussion

On 8 April 2018 at 15:05, Gert van Dijk <gert...@gmail.com> wrote:

Hi,

I've been thinking about the following feature request for a while, but I wanted to share/exchange some thoughts first here on the list.

When pushing your changes for review to any of the special remote refs (refs/for/*), it is always reported to be a completely new branch (and you cannot fetch from it). I see the point for this special ref, but my suggestion here is that we advertise the current branch' tip there, as if it's refs/heads/*. I presume it would help the Git client to ...:
understand what would have been pushed with a dry-run (git push -n).
Currently, a dry-run push is not functional with a special ref. You don't know upfront what commits would become a change in Gerrit. Accidentally pushing to the wrong special ref might create huge amounts of changes (only limited by receive.maxBatchChanges). Having the output of a dry-run push allows a user to prevent errors.

The openstack tool git-review does a log of the local changes from HEAD of anything 'not' in the remote as a approximate guess of what will be uploaded

https://github.com/openstack-infra/git-review/blob/master/git_review/cmd.py#L909-L910

Not completely accurate but it does serve as a useful baseline for the maximum number of changes that will be submitted if you need something until Gerrit/Git can tell you exactly what will be changed. Should be possible to build an alias if you don't want to use git-review.