| Age | Commit message (Collapse) | Author |
|---|
|
For the git-codereview commands to works on any Go's repositories, the
remote name for "origin" must be pointed to the Go original repository URL
(in most cases the one with go.googlesource.com domain).
The problem is when the "origin" is from the fork, all of the
git-codereview commands then will not works.
For example, in computer X, I clone the this repository from
"https://go.googlesource.com/review" (the origin) and then push my
changes on "git@git.sr.ht:~shulhan/go-x-review" (the fork).
In another computer Y, I then clone from the fork to continue my works.
The fork become origin.
One of the solution is to rename the remote names manually each time we
clone the fork.
The only cons using this solution is every time new branch created we need
to remember to pass "--set-upstream" during git push.
This changes introduce "remote" configuration in codereview.cfg.
When one first working on fork of Go repository, they set the "remote"
key, commit it, and push it.
When they cloned the fork, they did not needs to changes anything except
adding new remote using the pre-defined name.
Change-Id: I335d08fd8b7efe17ba07b3c0a3794f9ccf59b339
|
|
The codereview binary referred to the sync subcommand as merely "git
sync" in a number of places in user surfaces. This was wrong and
misleading, so the code now refers to it with the codereview parent
subcommand in the name (i.e., a "git codereview sync").
Change-Id: Icf3f96a8c76b57319bc3101b3e9fd0cbd8cecea9
Reviewed-on: https://go-review.googlesource.com/c/review/+/685855
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: David Chase <drchase@google.com>
|
|
Fixes golang/go#45734
Change-Id: I20ebc9fb728c5e91a3d71d3a6290ccf27ceb14cf
Reviewed-on: https://go-review.googlesource.com/c/review/+/496775
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Some projects (CUE, https://cuelang.org, is one such example) use the
Developer Certificate of Origin (https://developercertificate.org) as an
alternative to a CLA. For such projects, all commit messages must
contain the Signed-off-by trailer, with an email address that matches
the commit author. This requires the -s flag to be passed to git commit.
This change adds a -s flag to git-codereview's change command, which is
then simply passed through to git commit.
Change-Id: I6aeac37a1bcdc6e260ae822d3a03117fb87f846f
Reviewed-on: https://go-review.googlesource.com/c/review/+/334750
Trust: Paul Jolly <paul@myitcv.org.uk>
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
A sync + merge conflict + git rebase --continue can leave behind
a REBASE_HEAD even though it really should not. So don't use that
as the signal that there's an active rebase.
The rebase-merge directory is a better signal and seems to be
cleaned up more diligently than REBASE_HEAD.
Change-Id: Ie5bc20156e19fc7ce3e32333babea784242dc770
Reviewed-on: https://go-review.googlesource.com/c/review/+/293838
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
|
|
This CL adds a new command, "git codereview sync-branch",
which does the appropriate git merge for the current branch.
This CL also fixes a bug in "git codereview branchpoint",
and therefore also commands like "git codereview pending",
which was getting the branchpoint wrong for merges,
with the effect that a merge showed too many pending CLs.
This CL also fixes a bug in "git codereview change", which was
formerly willing to run "git checkout" with a pending merge,
which had the effect of flattening the merge mysteriously.
Now it detects the merge and refuses to run.
All of this should make merges easier and less error-prone
as we use dev branches more often.
With the earlier CL in this stack that allows working directly
on local branches, this is now a great way to run a merge
updating dev.regabi:
git change dev.regabi
git sync-branch
(with appropriate aliases to avoid typing "codereview").
Fixes golang/go#26201.
Change-Id: Ic24603123ca5135a72004309f5bb208ff149c9eb
Reviewed-on: https://go-review.googlesource.com/c/review/+/279772
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: Iab0417d14a29dce1a43f30f1f357d3f71dfdb51f
Reviewed-on: https://go-review.googlesource.com/c/review/+/279721
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
The only reason not to allow work on branches named for the
origin branches is to preserve them for "git change main; git change new"
to make a new branch tracking main. But we can still do that and
allow commits on main - we just have to use the branchpoint
as the root of the new branch.
Now people can work on "main" (or "dev.regabi") if that suits them.
In particular, if you're doing merges, it's nice to be on "dev.regabi"
and know for sure that's the branch you're working on.
Change-Id: I8e9458793c30857a5c00e6bfd4f1cb41adbbe637
Reviewed-on: https://go-review.googlesource.com/c/review/+/279874
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>
|
|
Change-Id: I17ad065e8b4c1eb00cdd2f17af82be76bae4fc09
Reviewed-on: https://go-review.googlesource.com/c/review/+/279717
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: I634a9d47401c1000bcb38e9dd7e84296a3de00e6
Reviewed-on: https://go-review.googlesource.com/c/review/+/254746
Trust: Russ Cox <rsc@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
The -m option allows a user to specify an inline commit
message. This is useful for a few reasons; primary among
them are the ability to easily automate a `git change`
flow (e.g. in a CI/CD workflow) and the ease of creating
one-liner commits (e.g. "regen protos").
Fixes golang/go#24912
Change-Id: Ie06886c74552ec615623c2faac285a1896bdac06
Reviewed-on: https://go-review.googlesource.com/c/107625
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Yury Smolsky <yury@smolsky.by>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
|
|
Change-Id: If9b3494162311743d9ea84dc9dc26163d6563c9c
Reviewed-on: https://go-review.googlesource.com/131055
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
It's `git codereview sync`.
Change-Id: Ia55db061d0cf35cb56c6faba7bb1569e621f9b57
GitHub-Last-Rev: 539f4d0750845686c1b0d3720f598f489dc3530f
GitHub-Pull-Request: golang/review#11
Reviewed-on: https://go-review.googlesource.com/128075
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Right now 'git fetch -q' takes about one second because of Gerrit
advertising far too many refs. Overlap the fetch with all the other
work, to at least reduce the overall time for 'git pending'.
The Gerrit team is aware of the refs advertisement problem and
a fix is planned for the next few months. That fix will speed things
up even further.
Change-Id: Iad57da9f1af1c6eae144fe28e5f96f79234bf3cd
Reviewed-on: https://go-review.googlesource.com/67572
Reviewed-by: Austin Clements <austin@google.com>
|
|
Now 'git change NNNN/PP' can be used to checkout (detached) the git
commit corresponding to the patchset PP of the change NNNN. If the
patchset is omitted, the current (latest) will be used.
Branch names that are only numbers or numbers separated by a slash will
always be understood as refering to CL. This break workflows that were
using numbers as branch names, but this is expected to be uncommon. The
workaround in this case is to use checkout directly.
It gets the commit fetching the specific reference inside origin's
refs/changes/ and check it out. It uses the gerrit API only if
querying the current patchset is needed.
Given that it's easy to mistype the number, change to a CL will show the
subject of the commit it just checked out.
Fixes golang/go#9255.
Change-Id: I01b98f4672051a52b8b9110a41d93f3ffefebaf1
Reviewed-on: https://go-review.googlesource.com/20101
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This enables passing -v to
'git codereview hooks'
to see what commands are being run.
It also means that automatic installation of
hooks should respect -n.
Change-Id: I812685b43e9ea678641f64b2182b957342a4e43c
Reviewed-on: https://go-review.googlesource.com/24002
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
When using 'git change' to amend the current change, it will fail
if there are multiple pending changes. The previous behavior (amending
the latest) wasn't always what the user intended.
$ git change
git-codereview: cannot amend change: multiple changes pending:
fc60fd5 test: dummy change
6440cdc git-codereview: make change fail with multiple pending changes
$
Unlike mail and submit, change doesn't support explicitly telling
which commit to work on. Either 'git commit --amend' (for updating
the topmost change) or a combination of 'git commit' and 'git rebase'
must be used.
Fixes golang/go#10443.
Change-Id: I2f6ea1b0e302b66b627761d72d031a3b6aa0fba2
Reviewed-on: https://go-review.googlesource.com/20049
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Detection of Rietveld-style fix messages is already in place as a warning,
but was broken when we added feature to rewrite issue references in commit edbdf1a7 .
To fix this, we automatically reformat the fix message into the GitHub style.
We also forget to write the change to the fix message back,
if we do not also need to write Change-Id and origin branch.
This change also fixes this.
Fixes golang/go#11472
Change-Id: Ie77358867e38cf976a0688b6e2f80525dae3891e
Reviewed-on: https://go-review.googlesource.com/15754
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
The name space is getting a bit crowded.
These words are too easy to use for other variables or functions.
Change-Id: Iedbccb82f85627fe422a029a6b45ad39a2e18dd0
Reviewed-on: https://go-review.googlesource.com/3627
Reviewed-by: Rob Pike <r@golang.org>
|
|
nonBlankLines
This CL separates the "run the command and gather output" from
the "process output" operations. Doing so makes the desired
processing clearer, makes the processing available for use on
other text sources.
Also, add cmdOutputDir, for running a command in a different
directory. This is needed by the gofmt command to work around
a bug in Git, and it's made much easier by the above separation.
Change-Id: I2addd8b79dab2d4aa8a24c94a8d7b3a16a8e3484
Reviewed-on: https://go-review.googlesource.com/2906
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Otherwise the git change error is a bit confusing.
Change-Id: I8bacac175417231284a238a078e5ea9513866943
Reviewed-on: https://go-review.googlesource.com/2786
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Gerrit supports multiple-change branches, and we'd like to make
git-codereview useful for people using this mode of work.
This CL is the first step.
- remove error message on detecting a multiple-change branch
- require 'git submit hash' in multiple-change branch
- make git submit, git sync cleanup safe for multiple-change branch
- adjust git pending output to show full information about multiple-change branch
- add pending -c to show only current branch, since output is getting long
We're not advertising or supporting this mode yet. For now the only
way to enter it is to run 'git commit' to create the second commit.
Perhaps eventually we will support something like 'git change -new'.
Change-Id: I8284a7c230503061d3e6d7cce0be7d8d05c9b2a3
Reviewed-on: https://go-review.googlesource.com/2110
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
- make it clearer what the random git command at the end of failures means
- avoid some problems with detached HEAD mode in hooks run during git rebase
- redirect all stdout/stderr into test buffers
Change-Id: I102f22fc870f69c884728eaa46ecc95792d5b795
Reviewed-on: https://go-review.googlesource.com/2011
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
Change-Id: I42601f47b318ab0be388480e17f627a757965486
Reviewed-on: https://go-review.googlesource.com/1992
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Mostly trivial search and replace, except for hooks.go which
includes a special case to remove the old git-review hooks.
Change-Id: Ic0792bb3e26607e5e0ead88958e46c3ac08288cd
Reviewed-on: https://go-review.googlesource.com/1741
Reviewed-by: Russ Cox <rsc@golang.org>
|
