Gerrit refspec design question
Harry
I have a simple (and perhaps naive) question about a Gerrit design
decision: as a committer who's pushing their changes, why can't you
just push your branch?
What I mean is, if you have just made a commit to your local 'cool-
feature' branch, which is tracking the remote 'cool-feature' branch in
Gerrit, why is it not OK to just do 'git push origin cool-feature'?
Why the need to explicitly push to refs/for/cool-feature or refs/heads/
cool-feature?
The reason I ask is that I have a very positive attitude towards
Gerrit: over the last 6 months or so it's done a lot to help us
improve code quality on my team, and I'd like to extend that to
improve the quality of some other assets we keep under version
control, such as Cucumber feature files. However, feature files (for
example) are 'owned' by the whole team, not just the engineers, and
that means some of our less technical colleagues will be involved in
their improvement and review.
At the moment, the less- or non-technical team members they have just
about got to a point where they can use Git, although they don't
necessarily understand it. They are happiest using point-and-click
tools like TortoiseGit, and since the 'refs/for' prefix is not
standard Git, that means they have to start typing things in boxes and
they are likely to forget, get confused, type in the wrong box, and
generally get frustrated. So although there's obviously more to
consider than the refspecs in use, I just wondered what the root of
the decision not to allow a committer to push straight to a branch
was, because that's one of the significant things that is likely to
confuse people. If I were to imagine how I'd expect it to work, there
would be some configuration option for each project to choose whether
a push to the 'raw' branch is a push to refs/for/x, refs/heads/x or is
just not allowed at all.
Thanks.
Harry
Shawn Pearce
> I have a simple (and perhaps naive) question about a Gerrit design
> decision: as a committer who's pushing their changes, why can't you
> just push your branch?
Because a push to your branch would immediately update that branch.
So we needed to use a different namespace to imply "this should be a
code review".
> confuse people. If I were to imagine how I'd expect it to work, there
> would be some configuration option for each project to choose whether
> a push to the 'raw' branch is a push to refs/for/x, refs/heads/x or is
> just not allowed at all.
This is a good idea, and isn't something I considered before. It may
be a relatively simple change, but since it adds new project
configuration data might be something we should do after the git-store
topic gets merged, rather than before.
Although in Android it will break some of our tools. Google uses an
auto-merger robot that directly pushes merges into branches, while
developers are uploading to those branches for code review (and cannot
direct push). So this almost needs to be a bit more options:
- not allowed at all
- always makes code review
- makes code review if not allowed direct push; updates branch if
direct push allowed for user
- always update branch, fail if user not allowed to direct push
And our branches would want that 3rd option.