sugarjar 2.0.2 → 3.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +19 -0
- data/README.md +123 -52
- data/bin/sj +80 -19
- data/examples/sample_config.yaml +6 -0
- data/examples/sample_repoconfig.yaml +19 -3
- data/lib/sugarjar/commands/bclean.rb +28 -13
- data/lib/sugarjar/commands/checks.rb +25 -8
- data/lib/sugarjar/commands/debuginfo.rb +1 -1
- data/lib/sugarjar/commands/feature.rb +25 -2
- data/lib/sugarjar/commands/push.rb +1 -1
- data/lib/sugarjar/commands/smartclone.rb +64 -7
- data/lib/sugarjar/commands/smartpullrequest.rb +29 -6
- data/lib/sugarjar/commands/up.rb +42 -10
- data/lib/sugarjar/commands.rb +93 -25
- data/lib/sugarjar/config.rb +33 -4
- data/lib/sugarjar/log.rb +2 -0
- data/lib/sugarjar/util.rb +28 -14
- data/lib/sugarjar/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: a412f3091d9ce81db841098d46c0b74f5ccf210e7f62916db5f36f68d4f9218f
|
|
4
|
+
data.tar.gz: db6f60757390c2e8decf11cada9a423f4d61284304e9db43ef4785636f621fd3
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 550d6c2792dd3b800f8fcbb3ab0d34019ba59ae09596988fc31c92452270d220c6e0a8feead9f767750f2fb529f2e0c60421a8e5756bb5c80974a7329142404b
|
|
7
|
+
data.tar.gz: b723f16e4a2640777ebc8496afa635ff146f0a5de8e0359213aa0824e43b236a312fd199c5ddea047ff5acba604848e48ea94d9716a80ff4d280210b6dc32c83
|
data/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,24 @@
|
|
|
1
1
|
# SugarJar Changelog
|
|
2
2
|
|
|
3
|
+
## 3.0.1 (2026-06-19)
|
|
4
|
+
|
|
5
|
+
* Update tests for more resiliency in various package-building environments
|
|
6
|
+
* Better fallbacks for forge type
|
|
7
|
+
* Add config option to disable fork-based flows
|
|
8
|
+
* Fix false-positive for "primary branch doesn't match" error
|
|
9
|
+
* gitlab: Handle 3-level repos better
|
|
10
|
+
* gitlab: Fix `smartpullrequest` issues
|
|
11
|
+
* gitlab: significant improvement to `smartclone`
|
|
12
|
+
* Add `--fork-name` option to enable forking to a different repo name
|
|
13
|
+
|
|
14
|
+
## 3.0.0 (2026-06-08)
|
|
15
|
+
|
|
16
|
+
* Add support for GitLab
|
|
17
|
+
* Add release-branch handling
|
|
18
|
+
* Fixes to `sync`/`fsync` to not leave repo in consistent state
|
|
19
|
+
* When in manual lint/unit, allow user to skip amending, and keep testing
|
|
20
|
+
* Fix typos in various messages
|
|
21
|
+
|
|
3
22
|
## 2.0.2 (2026-01-08)
|
|
4
23
|
|
|
5
24
|
* Fix `branchclean` logic to properly compare with the target branch
|
data/README.md
CHANGED
|
@@ -1,11 +1,21 @@
|
|
|
1
1
|
# SugarJar
|
|
2
2
|
|
|
3
|
-
[](https://github.com/jaymzh/sugarjar/actions?query=workflow%3ALint)
|
|
6
|
+
[](https://github.com/jaymzh/sugarjar/actions?query=workflow%3AUnittests)
|
|
9
|
+
[](https://github.com/jaymzh/sugarjar/actions?query=workflow%3A%22DCO+Check%22)
|
|
12
|
+
[](https://github.com/jaymzh/sugarjar/actions/workflows/codeql.yml)
|
|
15
|
+
|
|
16
|
+
Welcome to SugarJar - a git + github/gitlab helper. The only requirements are
|
|
17
|
+
Ruby, `git`, and either [gh](https://cli.github.com/) or
|
|
18
|
+
[glab](https://docs.gitlab.com/cli/), depending on which forge you are using.
|
|
9
19
|
|
|
10
20
|
SugarJar is inspired by [arcanist](https://github.com/phacility/arcanist), and
|
|
11
21
|
its replacement at Facebook, JellyFish. Many of the features they provide for
|
|
@@ -23,9 +33,14 @@ Jump to what you're most interested in:
|
|
|
23
33
|
* [Common Use-cases](#common-use-cases)
|
|
24
34
|
* [Auto Cleanup Squash-merged branches](#auto-cleanup-squash-merged-branches)
|
|
25
35
|
* [Smarter clones and remotes](#smarter-clones-and-remotes)
|
|
26
|
-
* [Work with stacked branches more easily](
|
|
27
|
-
|
|
28
|
-
* [
|
|
36
|
+
* [Work with stacked branches more easily](
|
|
37
|
+
#work-with-stacked-branches-more-easily)
|
|
38
|
+
* [Creating Stacked PRs with subfeatures](
|
|
39
|
+
#creating-stacked-prs-with-subfeatures)
|
|
40
|
+
* [Smart release branch handling](
|
|
41
|
+
#smart-release-branch-handling)
|
|
42
|
+
* [Have a better lint/unittest experience!](
|
|
43
|
+
#have-a-better-lintunittest-experience)
|
|
29
44
|
* [Better push defaults](#better-push-defaults)
|
|
30
45
|
* [Cleaning up your own history](#cleaning-up-your-own-history)
|
|
31
46
|
* [Better feature branches](#better-feature-branches)
|
|
@@ -56,7 +71,9 @@ and safely deletes if so. (Note: `lbclean` stands for "local branch clean", and
|
|
|
56
71
|
is aliased to `bclean` for both backwards-compatibility and also since it's the
|
|
57
72
|
most common branch-cleanup command).
|
|
58
73
|
|
|
59
|
-
|
|
60
77
|
|
|
61
78
|
Will delete a branch, if it has been merged, **even if it was squash-merged**.
|
|
62
79
|
|
|
@@ -66,7 +83,12 @@ You can pass it a branch if you'd like (it defaults to the branch you're on):
|
|
|
66
83
|
But it gets better! You can use `sj bcleanall` to remove all branches that have
|
|
67
84
|
been merged:
|
|
68
85
|
|
|
69
|
-
|
|
89
|
+
|
|
90
|
+
*NOTE*: You can add long-lived release-branches to your RepoConfig to prevent
|
|
91
|
+
cleaning; see [Smart release branch handling](️#smart-release-branch-handling).
|
|
70
92
|
|
|
71
93
|
There is also `sj rbclean` ("remote branch clean") (and `sj rbcleanall`) for
|
|
72
94
|
cleanup of remote branches. *Note*: This cannot differentiate between
|
|
@@ -74,8 +96,8 @@ PR/feature branches which have been merged and long-lived release branches that
|
|
|
74
96
|
have been merged (e.g. if '2.0-release' is a branch and has no commits not in
|
|
75
97
|
main, it will be deleted).
|
|
76
98
|
|
|
77
|
-
There is even `sj gbclean` ("global branch clean") (and `sj gbcleanall`) which
|
|
78
|
-
do both the local and remote cleaning.
|
|
99
|
+
There is even `sj gbclean` ("global branch clean") (and `sj gbcleanall`) which
|
|
100
|
+
will do both the local and remote cleaning.
|
|
79
101
|
|
|
80
102
|
*NOTE*: Remote branch cleaning is still experimental, use with caution!
|
|
81
103
|
|
|
@@ -85,13 +107,16 @@ There's a pattern to every new repo we want to contribute to. First we fork,
|
|
|
85
107
|
then we clone the fork, then we add a remote of the upstream repo. It's
|
|
86
108
|
monotonous. SugarJar does this for you:
|
|
87
109
|
|
|
88
|
-
|
|
89
113
|
|
|
90
114
|
`sj` accepts both `smartclone` and `sclone` for this command.
|
|
91
115
|
|
|
92
116
|
This will:
|
|
93
117
|
|
|
94
|
-
* Fork the repo to your personal org (if you don't already have a fork
|
|
118
|
+
* Fork the repo to your personal org (if you don't already have a fork,
|
|
119
|
+
and if it's not already in your personal org)
|
|
95
120
|
* Clone your fork
|
|
96
121
|
* Add the original as an 'upstream' remote
|
|
97
122
|
|
|
@@ -102,6 +127,9 @@ Like `git clone`, `sj smartclone` will accept an additional argument as the
|
|
|
102
127
|
destination directory to clone to. It will also pass any other unknown options
|
|
103
128
|
to `git clone` under the hood.
|
|
104
129
|
|
|
130
|
+
If you don't work with fork-based workflows, you can set `use_forks: false`
|
|
131
|
+
in your config, or pass in `--no-use-forks` to `sj sclone`.
|
|
132
|
+
|
|
105
133
|
### Work with stacked branches more easily
|
|
106
134
|
|
|
107
135
|
It's important to break changes into reviewable chunks, but working with
|
|
@@ -112,7 +140,9 @@ First, and foremost, is `feature` and `subfeature`. Regardless of stacking, the
|
|
|
112
140
|
way to create a new feature bracnh with sugarjar is with `sj feature` (or `sj
|
|
113
141
|
f` for short):
|
|
114
142
|
|
|
115
|
-
|
|
116
146
|
|
|
117
147
|
A "feature" in SugarJar parlance just means that the branch is always created
|
|
118
148
|
from "most main" - this is usually `upstream/main`, but SJ will figure out
|
|
@@ -123,7 +153,9 @@ to fetch that remote first to make sure you're working on the latest HEAD.
|
|
|
123
153
|
When you want to create a stacked PR, you can create `subfeature`, which, at
|
|
124
154
|
its core is just a branch created from the current branch:
|
|
125
155
|
|
|
126
|
-
|
|
127
159
|
|
|
128
160
|
If you create branches like this then sugarjar can now make several things
|
|
129
161
|
much easier:
|
|
@@ -134,31 +166,41 @@ much easier:
|
|
|
134
166
|
|
|
135
167
|
There are two commands that will show you the state of your stacked branches:
|
|
136
168
|
|
|
137
|
-
* `sj binfo` - shows the current branch and its ancestors up to your primary
|
|
169
|
+
* `sj binfo` - shows the current branch and its ancestors up to your primary
|
|
170
|
+
branch
|
|
138
171
|
* `sj smartlog` (aka `sj sl`) - shows you the whole tree.
|
|
139
172
|
|
|
140
173
|
To continue with the example above, my `smartlog` might look like:
|
|
141
174
|
|
|
142
|
-
|
|
143
178
|
|
|
144
179
|
As you can see, `mynewthing` is derived from `main`, and `dependentnewthing` is
|
|
145
180
|
derived from `mynewthing`.
|
|
146
181
|
|
|
147
182
|
Now lets make a different feature stack:
|
|
148
183
|
|
|
149
|
-
|
|
150
187
|
|
|
151
188
|
The `smartlog` will now show us this tree, and it's a bit more interesting:
|
|
152
189
|
|
|
153
|
-
|
|
154
193
|
|
|
155
194
|
Here we can see from `main`, we have two branches: one going to `mynewthing`
|
|
156
195
|
and one going to `anotherfeature`. Each of those has their own dependent branch
|
|
157
196
|
on top.
|
|
158
197
|
|
|
159
|
-
Now, what happens if I make a change to `mynewthing` (the bottom of the first
|
|
198
|
+
Now, what happens if I make a change to `mynewthing` (the bottom of the first
|
|
199
|
+
stack)?
|
|
160
200
|
|
|
161
|
-
|
|
162
204
|
|
|
163
205
|
We can see here now that `dependentnewthing`, is based off a commit that _used_
|
|
164
206
|
to be `mynewthing` (`5086ee`), but `mynewthing` has moved. Both `mynewthing`
|
|
@@ -166,7 +208,9 @@ and `dependentnewthing` are derived from `5086ee` (the old `mynewthing`), but
|
|
|
166
208
|
`dependentnewthing` isn't (yet) based on the current `mynewthing`. But SugarJar
|
|
167
209
|
will handle this all correctly when we ask it to update the branch:
|
|
168
210
|
|
|
169
|
-
|
|
170
214
|
|
|
171
215
|
Here we see that SugarJar knew that `dependentnewthing` should be rebased onto
|
|
172
216
|
`mynewthing`, and it did the right thing - from main there's still the
|
|
@@ -177,7 +221,9 @@ including all 3 commits in the right order.
|
|
|
177
221
|
Now, lets say that `mynewthing` gets merged and we use `bclean` to clean it all
|
|
178
222
|
up, what happens then?
|
|
179
223
|
|
|
180
|
-
|
|
181
227
|
|
|
182
228
|
SugarJar detects that branch is gone and thus this branch should now be based
|
|
183
229
|
on the upstream main branch!
|
|
@@ -196,6 +242,24 @@ It looks like this is a subfeature, would you like to base this PR on mynewthing
|
|
|
196
242
|
...
|
|
197
243
|
```
|
|
198
244
|
|
|
245
|
+
### Smart release branch handling
|
|
246
|
+
|
|
247
|
+
You can tell sugar what release branches exist, and it will intelligently
|
|
248
|
+
handle them. So of you specify, in your repoconfig:
|
|
249
|
+
|
|
250
|
+
```yaml
|
|
251
|
+
release_branches: ['v1-branch', 'v2-branch']
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
Then:
|
|
255
|
+
|
|
256
|
+
* `sj feature v1-backport-foo v2-branch` will automatically base this
|
|
257
|
+
branch on `upstream/v2-branch` (or `origin/v2-branch` as appropriate)
|
|
258
|
+
* `sj feature v2-branch` will checkout `v2-branch` with the upstream set
|
|
259
|
+
to `upstream/v2-branch` (or `origin/v2-branch` as appropriate)
|
|
260
|
+
* `sj lbclean`/`sj lbcleanall` (of all varieties) will never reap release
|
|
261
|
+
branches
|
|
262
|
+
|
|
199
263
|
### Have a better lint/unittest experience!
|
|
200
264
|
|
|
201
265
|
Ever made a PR, only to find out later that it failed tests because of some
|
|
@@ -276,8 +340,9 @@ Created feature branch dependent-feature based on test-branch
|
|
|
276
340
|
|
|
277
341
|
Additionally you can specify a `feature_prefix` in your config which will cause
|
|
278
342
|
`feature` to create branches prefixed with your `feature_prefix` and will also
|
|
279
|
-
cause `co` to checkout branches with that prefix. This is useful when
|
|
280
|
-
use branch-based workflows and branches need to be prefixed with
|
|
343
|
+
cause `co` to checkout branches with that prefix. This is useful when
|
|
344
|
+
organizations use branch-based workflows and branches need to be prefixed with
|
|
345
|
+
e.g. `$USER/`.
|
|
281
346
|
|
|
282
347
|
For example, if your prefix was `user/`, then `sj feature foo` would create
|
|
283
348
|
`user/foo`, and `sj co foo` would switch to `user/foo`.
|
|
@@ -287,7 +352,9 @@ For example, if your prefix was `user/`, then `sj feature foo` would create
|
|
|
287
352
|
Smartlog will show you a tree diagram of your branches! Simply run `sj
|
|
288
353
|
smartlog` or `sj sl` for short.
|
|
289
354
|
|
|
290
|
-
|
|
291
358
|
|
|
292
359
|
### Sync work across workstations
|
|
293
360
|
|
|
@@ -306,7 +373,7 @@ branch, it rebases on top of the push target branch.
|
|
|
306
373
|
|
|
307
374
|
### Pulling in suggestions from the web
|
|
308
375
|
|
|
309
|
-
When someone 'suggests' a change in the
|
|
376
|
+
When someone 'suggests' a change in the GH/GL WebUI, once you choose to commit
|
|
310
377
|
them, your origin and local branches are no longer in-sync. The
|
|
311
378
|
`pullsuggestions` command will attempt to merge in any remote commits to your
|
|
312
379
|
local branch. This command will show a diff and ask for confirmation before
|
|
@@ -322,19 +389,22 @@ See `sj help` for more commands!
|
|
|
322
389
|
Sugarjar is packaged in a variety of Linux distributions - see if it's on the
|
|
323
390
|
list here, and if so, use your package manager (or `gem`) to install it:
|
|
324
391
|
|
|
325
|
-
[](https://repology.org/project/sugarjar/versions)
|
|
326
395
|
|
|
327
396
|
If you are using a Linux distribution version that is end-of-life'd, click the
|
|
328
397
|
above image, it'll take you to a page that lists unsupported distro versions
|
|
329
398
|
as well (they'll have older SugarJar, but they'll probably still have some
|
|
330
399
|
version).
|
|
331
400
|
|
|
332
|
-
Ubuntu users
|
|
333
|
-
|
|
334
|
-
|
|
401
|
+
**Ubuntu users**: You can use [this PPA](
|
|
402
|
+
https://launchpad.net/~michel-slm/+archive/ubuntu/sugarjar) to get newer
|
|
403
|
+
versions for all supported Ubuntu releases (as well as some older versions).
|
|
335
404
|
Ubuntu package maintainer.
|
|
336
405
|
|
|
337
|
-
|
|
406
|
+
**MacOS users**: We recommend using Homebrew - we keep SugarJar updated in
|
|
407
|
+
Homebrew Core.
|
|
338
408
|
|
|
339
409
|
Finally, if none of those work for you, you can clone this repo and run it
|
|
340
410
|
directly from there.
|
|
@@ -351,8 +421,8 @@ See [examples/sample_config.yaml](examples/sample_config.yaml) for an example
|
|
|
351
421
|
configuration file.
|
|
352
422
|
|
|
353
423
|
In addition, the environment variable `SUGARJAR_LOGLEVEL` can be defined to set
|
|
354
|
-
a log level. This is primarily used as a way to turn debug on earlier in order
|
|
355
|
-
troubleshoot configuration parsing.
|
|
424
|
+
a log level. This is primarily used as a way to turn debug on earlier in order
|
|
425
|
+
to troubleshoot configuration parsing.
|
|
356
426
|
|
|
357
427
|
Deprecated fields will cause a warning, but you can suppress that warning by
|
|
358
428
|
defining `ignore_deprecated_options`, for example:
|
|
@@ -379,30 +449,31 @@ commit template by dropping a file in the repo. Users must do something like:
|
|
|
379
449
|
`git config commit.template <file>`. Making each developer do this is error
|
|
380
450
|
prone, so this setting will automatically set this up for each developer.
|
|
381
451
|
|
|
382
|
-
## Enterprise GitHub
|
|
452
|
+
## Enterprise GitHub/GitLab
|
|
453
|
+
|
|
454
|
+
Like `gh` and `glab`, SugarJar supports Enterprise versions of GitHub and
|
|
455
|
+
GitLab. In fact, we provide extra features just for it.
|
|
383
456
|
|
|
384
|
-
|
|
385
|
-
|
|
457
|
+
In most cases, when using `sj smartclone`, pass in `--forge-host`, and
|
|
458
|
+
that's about all you need, everything else should be handlded automagically.
|
|
386
459
|
|
|
387
|
-
|
|
460
|
+
However, you can set `forge_host` in your global or user config, but since most
|
|
388
461
|
users will also have a few opensource repos, you can override it in the
|
|
389
462
|
Repository Config as well.
|
|
390
463
|
|
|
391
464
|
So, for example you might have:
|
|
392
465
|
|
|
393
466
|
```yaml
|
|
394
|
-
|
|
467
|
+
forge_host: gh.sample.com
|
|
395
468
|
```
|
|
396
469
|
|
|
397
470
|
In your `~/.config/sugarjar/config.yaml`, but if the `.sugarjar.yaml` in your
|
|
398
471
|
repo has:
|
|
399
472
|
|
|
400
473
|
```yaml
|
|
401
|
-
|
|
474
|
+
forge_host: github.com
|
|
402
475
|
```
|
|
403
476
|
|
|
404
|
-
Then we will configure `gh` to talk to github.com when in that repo.
|
|
405
|
-
|
|
406
477
|
## FAQ
|
|
407
478
|
|
|
408
479
|
**Why the name SugarJar?**
|
|
@@ -411,7 +482,7 @@ It's mostly a backronym. Like jellyfish, I wanted two letters that were on home
|
|
|
411
482
|
row on different sides of the keyboard to make it easy to type. I looked at the
|
|
412
483
|
possible options that where there and not taken and tried to find one I could
|
|
413
484
|
make an appropriate name out of. Since this utility adds lots of sugar to git
|
|
414
|
-
and github, it seemed appropriate.
|
|
485
|
+
and github/gitlab, it seemed appropriate.
|
|
415
486
|
|
|
416
487
|
**I'd like to package SugarJar for my favorite distro/OS, is that OK?**
|
|
417
488
|
|
|
@@ -432,12 +503,12 @@ simply source that in your dotfiles, assuming you are using bash.
|
|
|
432
503
|
|
|
433
504
|
**What happens now that Sapling is released?**
|
|
434
505
|
|
|
435
|
-
SugarJar isn't going anywhere
|
|
436
|
-
|
|
437
|
-
|
|
506
|
+
SugarJar isn't going anywhere. This was meant to replace arc/jf, which has now
|
|
507
|
+
been open-sourced as [Sapling](https://sapling-scm.com/), so I highly recommend
|
|
508
|
+
taking a look at that!
|
|
438
509
|
|
|
439
510
|
Sapling is a great tool and solves a variety of problems SugarJar will never be
|
|
440
|
-
able to. However, it is a significant workflow change
|
|
441
|
-
|
|
442
|
-
|
|
443
|
-
developed.
|
|
511
|
+
able to. However, it is a significant workflow change that won't be appropriate
|
|
512
|
+
for all users or use-cases. Similarly there are workflows and tools that
|
|
513
|
+
Sapling breaks. Further, we support some things Sapling does not. So worry not,
|
|
514
|
+
SugarJar will continue to be maintained and developed.
|
data/bin/sj
CHANGED
|
@@ -36,20 +36,36 @@ parser = OptionParser.new do |opts|
|
|
|
36
36
|
end
|
|
37
37
|
|
|
38
38
|
opts.on(
|
|
39
|
+
'--forge-host HOST',
|
|
39
40
|
'--github-host HOST',
|
|
40
|
-
'The host
|
|
41
|
-
'
|
|
42
|
-
'
|
|
43
|
-
'
|
|
44
|
-
'will be part of that repo until changed.',
|
|
41
|
+
'The host of your forge (github, gitlab, etc.). Generally only needed' +
|
|
42
|
+
' when cloning (smartclone), as we can usually figure out from within' +
|
|
43
|
+
' a cloned repo. Currently accepts --github-host for backwards' +
|
|
44
|
+
' compatibility.',
|
|
45
45
|
) do |host|
|
|
46
|
-
options['
|
|
46
|
+
options['forge_host'] = host
|
|
47
47
|
end
|
|
48
48
|
|
|
49
|
-
opts.on('--
|
|
49
|
+
opts.on('--forge-type TYPE', 'Forge type: github, gitlab') do |type|
|
|
50
|
+
options['forge_type'] = type
|
|
51
|
+
end
|
|
52
|
+
|
|
53
|
+
opts.on(
|
|
54
|
+
'--github-user USER',
|
|
55
|
+
'User for github repos, unless specified in the repoconfig.' +
|
|
56
|
+
' Defaults to your local username',
|
|
57
|
+
) do |user|
|
|
50
58
|
options['github_user'] = user
|
|
51
59
|
end
|
|
52
60
|
|
|
61
|
+
opts.on(
|
|
62
|
+
'--gitlab-user USER',
|
|
63
|
+
'User for gitlab repos, unless specified in the repoconfig.' +
|
|
64
|
+
' Defaults to your local username',
|
|
65
|
+
) do |user|
|
|
66
|
+
options['gitlab_user'] = user
|
|
67
|
+
end
|
|
68
|
+
|
|
53
69
|
opts.on('-h', '--help', 'Print this help message') do
|
|
54
70
|
puts opts
|
|
55
71
|
exit
|
|
@@ -87,6 +103,22 @@ parser = OptionParser.new do |opts|
|
|
|
87
103
|
options['pr_autofill'] = autofill
|
|
88
104
|
end
|
|
89
105
|
|
|
106
|
+
opts.on(
|
|
107
|
+
'--[no-]use-forks',
|
|
108
|
+
'Create (add a remote for) forks, when the organization does not match ' +
|
|
109
|
+
'the user. [default: true]',
|
|
110
|
+
) do |val|
|
|
111
|
+
options['use_forks'] = val
|
|
112
|
+
end
|
|
113
|
+
|
|
114
|
+
opts.on(
|
|
115
|
+
'--fork-name NAME',
|
|
116
|
+
'When forking a repo (in `smartclone`), fork the repo to a different ' +
|
|
117
|
+
'name. See the help for `smartclone` below.',
|
|
118
|
+
) do |val|
|
|
119
|
+
options['fork_name'] = val
|
|
120
|
+
end
|
|
121
|
+
|
|
90
122
|
opts.on(
|
|
91
123
|
'--[no-]pr-autostack',
|
|
92
124
|
'When creating a PR, if this is a subfeature, should we make it a ' +
|
|
@@ -148,6 +180,10 @@ COMMANDS:
|
|
|
148
180
|
branches. Very convenient for keeping the branch behind a pull-
|
|
149
181
|
request clean.
|
|
150
182
|
|
|
183
|
+
forcesync, fsync
|
|
184
|
+
See 'sync' below, but never tries to rebase, always does a
|
|
185
|
+
hard reset.
|
|
186
|
+
|
|
151
187
|
globalbranchclean, gbclean [<branch>] [<remote>]
|
|
152
188
|
WARNING: EXPERIMENTAL COMMAND.
|
|
153
189
|
|
|
@@ -204,15 +240,40 @@ COMMANDS:
|
|
|
204
240
|
Walk all remote branches, and try to delete them if it's safe. See
|
|
205
241
|
"rbclean" for details.
|
|
206
242
|
|
|
207
|
-
smartclone, sclone
|
|
243
|
+
smartclone, sclone <repo> [<dir>]
|
|
208
244
|
A smart wrapper to "git clone" that handles forking and managing
|
|
209
245
|
remotes for you.
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
246
|
+
|
|
247
|
+
If the org of the repository is not the same as your forge user
|
|
248
|
+
then it will fork the repo for you to your account (if not
|
|
249
|
+
already done), clone the repo, and then setup your remotes
|
|
214
250
|
so that "origin" is your fork and "upstream" is the upstream.
|
|
215
251
|
|
|
252
|
+
It is assumed that there will be at least one positional
|
|
253
|
+
argument, and it will be the repo in any format (git, ssh,
|
|
254
|
+
forge-style shortname [e.g. e.g. "$org/$repo"]). A second
|
|
255
|
+
positional argument will be interpreted as the directory to
|
|
256
|
+
clone into.
|
|
257
|
+
|
|
258
|
+
If you want to change the name of the repo in your fork of it,
|
|
259
|
+
you may pass in --fork-name to specify another.
|
|
260
|
+
|
|
261
|
+
Note that if you pass in additional options after ' -- ', they
|
|
262
|
+
will be passed to 'gh' in the case of GitHub, or 'git' in the
|
|
263
|
+
case of GitLab.
|
|
264
|
+
|
|
265
|
+
For example to clone foo/bar/docs on gitlab, but have the
|
|
266
|
+
repo named 'bar-docs' when it's cloned to your org, and to
|
|
267
|
+
have the directory be called 'bar-docs':
|
|
268
|
+
|
|
269
|
+
sj sclone foo/bar/docs bar-docs \
|
|
270
|
+
--forge-type glab --fork-name bar-docs
|
|
271
|
+
|
|
272
|
+
Or for GitHub:
|
|
273
|
+
|
|
274
|
+
sj sclone bar/docs bar-docs \
|
|
275
|
+
--forge-type github --fork-name bar-docs
|
|
276
|
+
|
|
216
277
|
smartlog, sl
|
|
217
278
|
Inspired by Facebook's "sl" extension to Mercurial, this command
|
|
218
279
|
will show you a tree of all your local branches relative to your
|
|
@@ -306,6 +367,12 @@ end
|
|
|
306
367
|
|
|
307
368
|
SugarJar::Log.debug("Final config: #{options}")
|
|
308
369
|
|
|
370
|
+
# if the command is help, we don't bother to create the Commands obj
|
|
371
|
+
if subcommand == 'help'
|
|
372
|
+
puts parser
|
|
373
|
+
exit
|
|
374
|
+
end
|
|
375
|
+
|
|
309
376
|
sj = SugarJar::Commands.new(options)
|
|
310
377
|
valid_commands = sj.public_methods - Object.public_methods
|
|
311
378
|
is_valid_command = valid_commands.include?(subcommand.to_sym)
|
|
@@ -321,13 +388,7 @@ SugarJar::Log.debug("subcommand is #{subcommand}")
|
|
|
321
388
|
extra_opts += argv_copy
|
|
322
389
|
SugarJar::Log.debug("extra unknown options: #{extra_opts}")
|
|
323
390
|
|
|
324
|
-
|
|
325
|
-
when 'help'
|
|
326
|
-
puts parser
|
|
327
|
-
exit
|
|
328
|
-
when 'debuginfo'
|
|
329
|
-
extra_opts = [options]
|
|
330
|
-
end
|
|
391
|
+
extra_opts = [options] if subcommand == 'debuginfo'
|
|
331
392
|
|
|
332
393
|
unless is_valid_command
|
|
333
394
|
SugarJar::Log.fatal("No such subcommand: #{subcommand}")
|
data/examples/sample_config.yaml
CHANGED
|
@@ -22,3 +22,9 @@ pr_autostack: true
|
|
|
22
22
|
# Don't warn about deprecated config file options if they are in this
|
|
23
23
|
# list
|
|
24
24
|
ignore_deprecated_options: [ 'gh_cli' ]
|
|
25
|
+
|
|
26
|
+
# User to use when cloning new github repos
|
|
27
|
+
github_user: c00ldude
|
|
28
|
+
|
|
29
|
+
# User to use when cloning new gitlab repos
|
|
30
|
+
gitlab_user: c00ldude
|
|
@@ -20,6 +20,16 @@ include_from: .sugarjar_local.yaml
|
|
|
20
20
|
|
|
21
21
|
overwrite_from: .sugarjar_local_overwrite.yaml
|
|
22
22
|
|
|
23
|
+
# `release_branches` tells SugarJar several things:
|
|
24
|
+
# 1. These branches should not be repead when running `bclean`/`bcleanall`.
|
|
25
|
+
# 2. When a feature-branch is made from a release branch (e.g. `2.x-branch`),
|
|
26
|
+
# it will actually track the release branch's upstream
|
|
27
|
+
# (e.g. `upstream/2.x-bramch`), allowing it to work the same as as a
|
|
28
|
+
# feature made off of main.
|
|
29
|
+
release_branches:
|
|
30
|
+
- 2.x-branch
|
|
31
|
+
- 3.x-branch
|
|
32
|
+
|
|
23
33
|
# `lint` is a list of scripts to run when `sj lint` is executed (or, if
|
|
24
34
|
# configured, to run on `sj spush`/`sj fpush` - see `on_push` below).
|
|
25
35
|
# Regardless of where `sj` is run from, these scripts will be run from the root
|
|
@@ -71,7 +81,13 @@ commit_template: .git_commit_template.txt
|
|
|
71
81
|
|
|
72
82
|
github_user: myuser
|
|
73
83
|
|
|
74
|
-
# `
|
|
75
|
-
#
|
|
84
|
+
# `gitlab_user` is the user to use when talking to GitLab. Overrides any such
|
|
85
|
+
# setting in the regular SugarJar config. Most useful when in the
|
|
86
|
+
# `include_from` file.
|
|
87
|
+
|
|
88
|
+
gitlab_user: myuser
|
|
89
|
+
|
|
90
|
+
# `forge_host` is the GitHub/GitLab host to use when talking to hosted versions
|
|
91
|
+
# of these services.
|
|
76
92
|
|
|
77
|
-
|
|
93
|
+
forge_host: github.sample.com
|
|
@@ -5,10 +5,11 @@ class SugarJar
|
|
|
5
5
|
name ||= current_branch
|
|
6
6
|
name = fprefix(name)
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
8
|
+
should_skip, why = skip_branch_info(name)
|
|
9
|
+
if should_skip
|
|
10
|
+
msg = "#{name}: #{color('skipped', :yellow)}"
|
|
11
|
+
msg << " (#{why})" if why
|
|
12
|
+
SugarJar::Log.warn(msg)
|
|
12
13
|
return
|
|
13
14
|
end
|
|
14
15
|
|
|
@@ -61,16 +62,17 @@ class SugarJar
|
|
|
61
62
|
def lbcleanall
|
|
62
63
|
assert_in_repo!
|
|
63
64
|
curr = current_branch
|
|
64
|
-
|
|
65
|
+
worktree_branches
|
|
65
66
|
all_local_branches.each do |branch|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
)
|
|
67
|
+
# skip_branch info will check for MAIN_BRANCHES, but we
|
|
68
|
+
# quietly skip them.
|
|
69
|
+
next if MAIN_BRANCHES.include?(branch)
|
|
70
|
+
|
|
71
|
+
should_skip, why = skip_branch_info(branch)
|
|
72
|
+
if should_skip
|
|
73
|
+
msg = "#{branch}: #{color('skipped', :yellow)}"
|
|
74
|
+
msg << " (#{why})" if why
|
|
75
|
+
SugarJar::Log.info(msg)
|
|
74
76
|
next
|
|
75
77
|
end
|
|
76
78
|
|
|
@@ -229,5 +231,18 @@ class SugarJar
|
|
|
229
231
|
# delete our temp branch
|
|
230
232
|
git('branch', '-D', tmp)
|
|
231
233
|
end
|
|
234
|
+
|
|
235
|
+
def skip_branch_info(name)
|
|
236
|
+
return true, 'main branch' if MAIN_BRANCHES.include?(name)
|
|
237
|
+
|
|
238
|
+
wt_branches = worktree_branches
|
|
239
|
+
rel_branches = release_branches
|
|
240
|
+
|
|
241
|
+
return true, 'worktree' if wt_branches.include?(name)
|
|
242
|
+
|
|
243
|
+
return true, 'release branch' if rel_branches.include?(name)
|
|
244
|
+
|
|
245
|
+
[false, nil]
|
|
246
|
+
end
|
|
232
247
|
end
|
|
233
248
|
end
|