| 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>
|
|
commands
If a user does not have the recommended aliases in their .gitconfig, the suggested
command will not work. Several suggestions have the codereview subcommand already;
this change updates all suggestions to include it.
Change-Id: I3613f24172c2d90a7038f263cad93cbdcddbbbca
Reviewed-on: https://go-review.googlesource.com/c/review/+/681176
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
|
|
When working with dev branches, it is possible that a branch
needed to be sync'd can be fast-forworded. For example, there is
no new commit since the last sync. Or this could happen with
multi-release-cycle branches, where we reverse-sync'd to master
for one release cycle, later try to sync master to branch for the
next cycle. Fast-forwording is generally not what we want (and it
confuses the git-codereview tool when trying to craft the CL
description). Pass --no-ff to ensure we create a merge commit.
Change-Id: Ic204882d0304ec538c2e219d34e370ba98db9374
Reviewed-on: https://go-review.googlesource.com/c/review/+/319069
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
io/ioutil is now deprecated. Use non-deprecated equivalents.
Change-Id: Iad1cc9c14dbdad3a6f9ada25072bc194bace4081
Reviewed-on: https://go-review.googlesource.com/c/review/+/543615
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: I8a3bcad53eae3273dc498ba94d53fe2d50b58520
Reviewed-on: https://go-review.googlesource.com/c/review/+/290212
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Sync very frequently is done to zero out submitted CLs.
New git versions print
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks false"
This message is noise more often than signal, so disable it during sync.
Change-Id: Ida8867cbd614027f43bbbe6e6389a8920aae5293
Reviewed-on: https://go-review.googlesource.com/c/review/+/351209
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
When doing a merge, it's unlikely that someone
would want to run gofmt for files they didn't
edit, so turn that off by default.
Change-Id: I6c95b866740d5deda575feda256eee35dba3d9d1
Reviewed-on: https://go-review.googlesource.com/c/review/+/320269
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Dev branches come to an end.
Making sync-branch help that process instead of forcing
people to follow a playbook will help avoid mistakes.
The flag name was chosen to be very unlikely to be used
accidentally, and the commit subject and message both
are distinct to make clear to reviewers what they are being
asked to +2.
The Merge List is also included in full and is likely to be
quite large, yet another signal for everyone involved about
the magnitude and weight of the change.
Change-Id: I91cdda2b85cd3811711a339f4f3290fee109022e
Reviewed-on: https://go-review.googlesource.com/c/review/+/282534
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Long ago I decided to return origin/HEAD from b.OriginBranch
in detached HEAD mode, thinking it would cause obvious failures.
But the joke was on me - origin/HEAD is a real thing in git,
and HEAD tracking origin/HEAD is not the right answer on dev branches.
Now that each branch's codereview.cfg typically has the branch info
we need, we can use that in detached HEAD mode to be able to provide
useful displays in commands like "git pending". And we can be careful
not to do that when we don't know the actual branch.
This commit cleans all that up.
Change-Id: I0e59bcb6f9b61e0cdce7a27299b7f29fef8e7048
Reviewed-on: https://go-review.googlesource.com/c/review/+/282616
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
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>
|
|
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>
|
|
The -v flag in review is already used to signal more verbose output.
With one -v, git sync shows the git commands. After this change,
two -vs (or -v=2) causes git sync to pass -v to git pull as well.
Also mention that -v is a counter not a boolean in the documentation.
Change-Id: I584068f05c2298be6ae2e6ae17a0b817dc6a092f
Reviewed-on: https://go-review.googlesource.com/88875
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
When deciding whether to discard the commit info for
the final commit, it was using the first commit instead of
the final one.
Change-Id: I2304fba6fa82a1d21600c3caa08b6b119edcdb7f
Reviewed-on: https://go-review.googlesource.com/3628
Reviewed-by: Rob Pike <r@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>
|
|
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>
|
|
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>
|
