@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Describe how to process big checkins
Summary:
I was asked question about this twice this week.
I will link the section from [[ https://secure.phabricator.com/diffusion/ARC/browse/master/src/workflow/ArcanistDiffWorkflow.php;13b64da47aff0752$853-856 | ArcanistDiffWorkflow ]] afterwards.
NOTE: I believe that I read these instructions somewhere but I couldn't find it.
Test Plan: Read.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D3313
+10
-7
+3
src/docs/flavortext/writing_reviewable_code.diviner
+3
src/docs/flavortext/writing_reviewable_code.diviner
···
74
74
We generally follow these practices in Phabricator. The median change size for
75
75
Phabricator is 35 lines.
76
76
77
+
See @{article:Differential User Guide: Large Changes} for information about
78
+
reviewing big checkins.
79
+
77
80
= Write Sensible Commit Messages =
78
81
79
82
There are lots of resources for this on the internet. All of them say pretty much
+7
-7
src/docs/userguide/differential_large_changes.diviner
+7
-7
src/docs/userguide/differential_large_changes.diviner
···
16
16
you can fork it or link against it.
17
17
- Committing an enormous text datafile, like a list of every English word or a
18
18
dump of a database.
19
-
- Making a trivial (e.g., find/replace) edit to 10,000 files.
19
+
- Making a trivial (e.g., find/replace or codemod) edit to 10,000 files.
20
20
21
21
You can still try submitting these kinds of changes, but you may encounter
22
22
problems getting them to work (database or connection timeouts, for example).
···
36
36
name on the review?". This is best for straightforward changes. The reviewer
37
37
is not going to review MySQL's source itself, instead they are reviewing the
38
38
change metadata: which version are you checking in, why are you checking it
39
-
in, and where are you putting it?
39
+
in, and where are you putting it? You won't be able to use "arc commit" or
40
+
"arc amend" to actually push the change. Just use "svn" or "git" and
41
+
manually edit the commit message instead. (It is normally sufficient to add
42
+
a "Reviewed By: <username>" field.)
40
43
- Create a Differential revision with only the metadata, like the script you
41
44
used to make automated changes or a text file explaining what you're doing,
42
45
and maybe a sample of some of the changes if they were automated. Include a
43
46
link to where the changes are staged so reviewers can look at the actual
44
47
changeset if they want to. This is best for more complicated changes, since
45
48
Differential can still be used for discussion and provide a permanent record
46
-
others can refer to.
47
-
48
-
In both cases, you won't be able to use "arc commit" or "arc amend" to actually
49
-
push the change. Just use "svn" or "git" and manually edit the commit message
50
-
instead. (It is normally sufficient to add a "Reviewed By: <username>" field.)
49
+
others can refer to. Once the revision is accepted, amend your local commit
50
+
(e.g. by `git commit --amend`) with the real change and push as usual.
51
51
52
52
These kinds of changes are generally rare and don't have much in common, which
53
53
is why there's no explicit support for them in Differential. If you frequently