sugarjar 2.0.1 → 3.0.0
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 +28 -0
- data/README.md +151 -55
- data/bin/sj +96 -23
- data/examples/sample_config.yaml +6 -0
- data/examples/sample_repoconfig.yaml +19 -3
- data/lib/sugarjar/commands/bclean.rb +147 -17
- data/lib/sugarjar/commands/checks.rb +27 -8
- data/lib/sugarjar/commands/debuginfo.rb +1 -1
- data/lib/sugarjar/commands/feature.rb +25 -2
- data/lib/sugarjar/commands/pullsuggestions.rb +2 -15
- data/lib/sugarjar/commands/push.rb +4 -15
- data/lib/sugarjar/commands/smartclone.rb +47 -3
- data/lib/sugarjar/commands/smartpullrequest.rb +27 -5
- data/lib/sugarjar/commands/up.rb +57 -4
- data/lib/sugarjar/commands.rb +155 -25
- data/lib/sugarjar/config.rb +32 -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: '0359bbf05d9c9930fb303ddcba57fd651d00de7ce046a5640c77f596fa148531'
|
|
4
|
+
data.tar.gz: 6a505ebcdc042fb4e3b6bd6c4e55e85401787f748a1f8874b4fd18e7489600e7
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 88050a2cc342cac84d22ed6395f5fa36df8ff98361283408ae227611c4814b23881ae4a59eef276feb160bea04c9b84e81d6cd76d7eae0c8d8caac0e199dcdad
|
|
7
|
+
data.tar.gz: 932d4c9918a3eb50c078e6e3a7dd4728ea648cca222daa460954ec51ea7109fc374ea8a8517e9cf1b71d900ac5bb44c4a6120f0a7aaa581fee87d154a6be08f7
|
data/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,33 @@
|
|
|
1
1
|
# SugarJar Changelog
|
|
2
2
|
|
|
3
|
+
## 3.0.0 (2026-06-08)
|
|
4
|
+
|
|
5
|
+
* Add support for GitLab
|
|
6
|
+
* Add release-branch handling
|
|
7
|
+
* Fixes to `sync`/`fsync` to not leave repo in consistent state
|
|
8
|
+
* When in manual lint/unit, allow user to skip amending, and keep testing
|
|
9
|
+
* Fix typos in various messages
|
|
10
|
+
|
|
11
|
+
## 2.0.2 (2026-01-08)
|
|
12
|
+
|
|
13
|
+
* Fix `branchclean` logic to properly compare with the target branch
|
|
14
|
+
(might have refused to clean branches that could be cleaned)
|
|
15
|
+
* Add new commands to handle remote branch cleanup as well as rename
|
|
16
|
+
`bclean` (keeping backwards compatible aliases):
|
|
17
|
+
* `localbranchclean` / `lbclean` - local branch clean. aliased as
|
|
18
|
+
`bclean` for back-comat
|
|
19
|
+
* `localbranchcleanall` / `lbcleanall` - local all branch clean aliased
|
|
20
|
+
as `bcleanall` for back-compat
|
|
21
|
+
* `remotebranchclean` / `rbclean` - remote branch clean
|
|
22
|
+
* `remotebranchcleanall` / `rbcleanall` - remote all branch clean
|
|
23
|
+
* `globalbranchclean` / `gbclean` - local+remote branch clean
|
|
24
|
+
* `globalbranchcleanall` / `gbcleanall` - local+remote all branch clean
|
|
25
|
+
* Added new `sync` command to aid syncing branches across multiple workstations,
|
|
26
|
+
see help for details.
|
|
27
|
+
* Fix meta-ref handling which fixes crashes when using `smartlog` during rebases
|
|
28
|
+
* Handle worktress gracefully when doing branch cleans
|
|
29
|
+
* Make unittests work properly outside of git repos
|
|
30
|
+
|
|
3
31
|
## 2.0.1 (2025-05-12)
|
|
4
32
|
|
|
5
33
|
* Fix gemspec to include new library files
|
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,13 +33,19 @@ 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)
|
|
32
47
|
* [Smartlog](#smartlog)
|
|
48
|
+
* [Sync work across workstations](#sync-work-across-workstations)
|
|
33
49
|
* [Pulling in suggestions from the web](#pulling-in-suggestions-from-the-web)
|
|
34
50
|
* [And more!](#and-more)
|
|
35
51
|
* [Installation](#installation)
|
|
@@ -50,10 +66,14 @@ doesn't work. Git will tell you the branch isn't fully merged. You can, of
|
|
|
50
66
|
course `git branch -D <branch>`, but that does no safety checks at all, it
|
|
51
67
|
forces the deletion.
|
|
52
68
|
|
|
53
|
-
Enter `sj
|
|
54
|
-
and safely deletes if so.
|
|
69
|
+
Enter `sj lbclean` - it determines if the contents of your branch has been merge
|
|
70
|
+
and safely deletes if so. (Note: `lbclean` stands for "local branch clean", and
|
|
71
|
+
is aliased to `bclean` for both backwards-compatibility and also since it's the
|
|
72
|
+
most common branch-cleanup command).
|
|
55
73
|
|
|
56
|
-
|
|
57
77
|
|
|
58
78
|
Will delete a branch, if it has been merged, **even if it was squash-merged**.
|
|
59
79
|
|
|
@@ -63,7 +83,23 @@ You can pass it a branch if you'd like (it defaults to the branch you're on):
|
|
|
63
83
|
But it gets better! You can use `sj bcleanall` to remove all branches that have
|
|
64
84
|
been merged:
|
|
65
85
|
|
|
66
|
-
|
|
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).
|
|
92
|
+
|
|
93
|
+
There is also `sj rbclean` ("remote branch clean") (and `sj rbcleanall`) for
|
|
94
|
+
cleanup of remote branches. *Note*: This cannot differentiate between
|
|
95
|
+
PR/feature branches which have been merged and long-lived release branches that
|
|
96
|
+
have been merged (e.g. if '2.0-release' is a branch and has no commits not in
|
|
97
|
+
main, it will be deleted).
|
|
98
|
+
|
|
99
|
+
There is even `sj gbclean` ("global branch clean") (and `sj gbcleanall`) which
|
|
100
|
+
will do both the local and remote cleaning.
|
|
101
|
+
|
|
102
|
+
*NOTE*: Remote branch cleaning is still experimental, use with caution!
|
|
67
103
|
|
|
68
104
|
### Smarter clones and remotes
|
|
69
105
|
|
|
@@ -71,7 +107,9 @@ There's a pattern to every new repo we want to contribute to. First we fork,
|
|
|
71
107
|
then we clone the fork, then we add a remote of the upstream repo. It's
|
|
72
108
|
monotonous. SugarJar does this for you:
|
|
73
109
|
|
|
74
|
-
|
|
75
113
|
|
|
76
114
|
`sj` accepts both `smartclone` and `sclone` for this command.
|
|
77
115
|
|
|
@@ -98,7 +136,9 @@ First, and foremost, is `feature` and `subfeature`. Regardless of stacking, the
|
|
|
98
136
|
way to create a new feature bracnh with sugarjar is with `sj feature` (or `sj
|
|
99
137
|
f` for short):
|
|
100
138
|
|
|
101
|
-
|
|
102
142
|
|
|
103
143
|
A "feature" in SugarJar parlance just means that the branch is always created
|
|
104
144
|
from "most main" - this is usually `upstream/main`, but SJ will figure out
|
|
@@ -109,7 +149,9 @@ to fetch that remote first to make sure you're working on the latest HEAD.
|
|
|
109
149
|
When you want to create a stacked PR, you can create `subfeature`, which, at
|
|
110
150
|
its core is just a branch created from the current branch:
|
|
111
151
|
|
|
112
|
-
|
|
113
155
|
|
|
114
156
|
If you create branches like this then sugarjar can now make several things
|
|
115
157
|
much easier:
|
|
@@ -120,31 +162,41 @@ much easier:
|
|
|
120
162
|
|
|
121
163
|
There are two commands that will show you the state of your stacked branches:
|
|
122
164
|
|
|
123
|
-
* `sj binfo` - shows the current branch and its ancestors up to your primary
|
|
165
|
+
* `sj binfo` - shows the current branch and its ancestors up to your primary
|
|
166
|
+
branch
|
|
124
167
|
* `sj smartlog` (aka `sj sl`) - shows you the whole tree.
|
|
125
168
|
|
|
126
169
|
To continue with the example above, my `smartlog` might look like:
|
|
127
170
|
|
|
128
|
-
|
|
129
174
|
|
|
130
175
|
As you can see, `mynewthing` is derived from `main`, and `dependentnewthing` is
|
|
131
176
|
derived from `mynewthing`.
|
|
132
177
|
|
|
133
178
|
Now lets make a different feature stack:
|
|
134
179
|
|
|
135
|
-
|
|
136
183
|
|
|
137
184
|
The `smartlog` will now show us this tree, and it's a bit more interesting:
|
|
138
185
|
|
|
139
|
-
|
|
140
189
|
|
|
141
190
|
Here we can see from `main`, we have two branches: one going to `mynewthing`
|
|
142
191
|
and one going to `anotherfeature`. Each of those has their own dependent branch
|
|
143
192
|
on top.
|
|
144
193
|
|
|
145
|
-
Now, what happens if I make a change to `mynewthing` (the bottom of the first
|
|
194
|
+
Now, what happens if I make a change to `mynewthing` (the bottom of the first
|
|
195
|
+
stack)?
|
|
146
196
|
|
|
147
|
-
|
|
148
200
|
|
|
149
201
|
We can see here now that `dependentnewthing`, is based off a commit that _used_
|
|
150
202
|
to be `mynewthing` (`5086ee`), but `mynewthing` has moved. Both `mynewthing`
|
|
@@ -152,7 +204,9 @@ and `dependentnewthing` are derived from `5086ee` (the old `mynewthing`), but
|
|
|
152
204
|
`dependentnewthing` isn't (yet) based on the current `mynewthing`. But SugarJar
|
|
153
205
|
will handle this all correctly when we ask it to update the branch:
|
|
154
206
|
|
|
155
|
-
|
|
156
210
|
|
|
157
211
|
Here we see that SugarJar knew that `dependentnewthing` should be rebased onto
|
|
158
212
|
`mynewthing`, and it did the right thing - from main there's still the
|
|
@@ -163,7 +217,9 @@ including all 3 commits in the right order.
|
|
|
163
217
|
Now, lets say that `mynewthing` gets merged and we use `bclean` to clean it all
|
|
164
218
|
up, what happens then?
|
|
165
219
|
|
|
166
|
-
|
|
167
223
|
|
|
168
224
|
SugarJar detects that branch is gone and thus this branch should now be based
|
|
169
225
|
on the upstream main branch!
|
|
@@ -182,6 +238,24 @@ It looks like this is a subfeature, would you like to base this PR on mynewthing
|
|
|
182
238
|
...
|
|
183
239
|
```
|
|
184
240
|
|
|
241
|
+
### Smart release branch handling
|
|
242
|
+
|
|
243
|
+
You can tell sugar what release branches exist, and it will intelligently
|
|
244
|
+
handle them. So of you specify, in your repoconfig:
|
|
245
|
+
|
|
246
|
+
```yaml
|
|
247
|
+
release_branches: ['v1-branch', 'v2-branch']
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Then:
|
|
251
|
+
|
|
252
|
+
* `sj feature v1-backport-foo v2-branch` will automatically base this
|
|
253
|
+
branch on `upstream/v2-branch` (or `origin/v2-branch` as appropriate)
|
|
254
|
+
* `sj feature v2-branch` will checkout `v2-branch` with the upstream set
|
|
255
|
+
to `upstream/v2-branch` (or `origin/v2-branch` as appropriate)
|
|
256
|
+
* `sj lbclean`/`sj lbcleanall` (of all varieties) will never reap release
|
|
257
|
+
branches
|
|
258
|
+
|
|
185
259
|
### Have a better lint/unittest experience!
|
|
186
260
|
|
|
187
261
|
Ever made a PR, only to find out later that it failed tests because of some
|
|
@@ -262,8 +336,9 @@ Created feature branch dependent-feature based on test-branch
|
|
|
262
336
|
|
|
263
337
|
Additionally you can specify a `feature_prefix` in your config which will cause
|
|
264
338
|
`feature` to create branches prefixed with your `feature_prefix` and will also
|
|
265
|
-
cause `co` to checkout branches with that prefix. This is useful when
|
|
266
|
-
use branch-based workflows and branches need to be prefixed with
|
|
339
|
+
cause `co` to checkout branches with that prefix. This is useful when
|
|
340
|
+
organizations use branch-based workflows and branches need to be prefixed with
|
|
341
|
+
e.g. `$USER/`.
|
|
267
342
|
|
|
268
343
|
For example, if your prefix was `user/`, then `sj feature foo` would create
|
|
269
344
|
`user/foo`, and `sj co foo` would switch to `user/foo`.
|
|
@@ -273,11 +348,28 @@ For example, if your prefix was `user/`, then `sj feature foo` would create
|
|
|
273
348
|
Smartlog will show you a tree diagram of your branches! Simply run `sj
|
|
274
349
|
smartlog` or `sj sl` for short.
|
|
275
350
|
|
|
276
|
-
|
|
354
|
+
|
|
355
|
+
### Sync work across workstations
|
|
356
|
+
|
|
357
|
+
If you work on multiple workstations, keeping your branches in-sync can be a
|
|
358
|
+
pain. SugarJar provides `sync` to help with this.
|
|
359
|
+
|
|
360
|
+
For example, if you do some work on feature `foo` on machine1 and push to
|
|
361
|
+
`origin/foo` (intending to eventually merge to `upstream/main`), then on
|
|
362
|
+
machine2, you pull that branch, do more work, which you also push to
|
|
363
|
+
`origin/foo`, then on machine1, you can do `sj sync` to pull down the changes
|
|
364
|
+
from `origin/foo`. If you have local changes, that are not already on
|
|
365
|
+
`origin/foo`, those will be rebased on top of the changes from `origin/foo`.
|
|
366
|
+
|
|
367
|
+
It's very similar to `sj up`, but instead of rebasing on top of the tracking
|
|
368
|
+
branch, it rebases on top of the push target branch.
|
|
277
369
|
|
|
278
370
|
### Pulling in suggestions from the web
|
|
279
371
|
|
|
280
|
-
When someone 'suggests' a change in the
|
|
372
|
+
When someone 'suggests' a change in the GH/GL WebUI, once you choose to commit
|
|
281
373
|
them, your origin and local branches are no longer in-sync. The
|
|
282
374
|
`pullsuggestions` command will attempt to merge in any remote commits to your
|
|
283
375
|
local branch. This command will show a diff and ask for confirmation before
|
|
@@ -293,19 +385,22 @@ See `sj help` for more commands!
|
|
|
293
385
|
Sugarjar is packaged in a variety of Linux distributions - see if it's on the
|
|
294
386
|
list here, and if so, use your package manager (or `gem`) to install it:
|
|
295
387
|
|
|
296
|
-
[](https://repology.org/project/sugarjar/versions)
|
|
297
391
|
|
|
298
392
|
If you are using a Linux distribution version that is end-of-life'd, click the
|
|
299
393
|
above image, it'll take you to a page that lists unsupported distro versions
|
|
300
394
|
as well (they'll have older SugarJar, but they'll probably still have some
|
|
301
395
|
version).
|
|
302
396
|
|
|
303
|
-
Ubuntu users
|
|
304
|
-
|
|
305
|
-
|
|
397
|
+
**Ubuntu users**: You can use [this PPA](
|
|
398
|
+
https://launchpad.net/~michel-slm/+archive/ubuntu/sugarjar) to get newer
|
|
399
|
+
versions for all supported Ubuntu releases (as well as some older versions).
|
|
306
400
|
Ubuntu package maintainer.
|
|
307
401
|
|
|
308
|
-
|
|
402
|
+
**MacOS users**: We recommend using Homebrew - we keep SugarJar updated in
|
|
403
|
+
Homebrew Core.
|
|
309
404
|
|
|
310
405
|
Finally, if none of those work for you, you can clone this repo and run it
|
|
311
406
|
directly from there.
|
|
@@ -314,7 +409,7 @@ directly from there.
|
|
|
314
409
|
|
|
315
410
|
Sugarjar will read in both a system-level config file
|
|
316
411
|
(`/etc/sugarjar/config.yaml`) and a user-level config file
|
|
317
|
-
`~/.config/sugarjar/config.yaml
|
|
412
|
+
(`~/.config/sugarjar/config.yaml`), if they exist. Anything in the user config
|
|
318
413
|
will override the system config, and command-line options override both. The
|
|
319
414
|
yaml file is a straight key-value pair of options without their '--'.
|
|
320
415
|
|
|
@@ -322,8 +417,8 @@ See [examples/sample_config.yaml](examples/sample_config.yaml) for an example
|
|
|
322
417
|
configuration file.
|
|
323
418
|
|
|
324
419
|
In addition, the environment variable `SUGARJAR_LOGLEVEL` can be defined to set
|
|
325
|
-
a log level. This is primarily used as a way to turn debug on earlier in order
|
|
326
|
-
troubleshoot configuration parsing.
|
|
420
|
+
a log level. This is primarily used as a way to turn debug on earlier in order
|
|
421
|
+
to troubleshoot configuration parsing.
|
|
327
422
|
|
|
328
423
|
Deprecated fields will cause a warning, but you can suppress that warning by
|
|
329
424
|
defining `ignore_deprecated_options`, for example:
|
|
@@ -350,30 +445,31 @@ commit template by dropping a file in the repo. Users must do something like:
|
|
|
350
445
|
`git config commit.template <file>`. Making each developer do this is error
|
|
351
446
|
prone, so this setting will automatically set this up for each developer.
|
|
352
447
|
|
|
353
|
-
## Enterprise GitHub
|
|
448
|
+
## Enterprise GitHub/GitLab
|
|
354
449
|
|
|
355
|
-
Like `gh`, SugarJar supports
|
|
356
|
-
features just for it.
|
|
450
|
+
Like `gh` and `glab`, SugarJar supports Enterprise versions of GitHub and
|
|
451
|
+
GitLab. In fact, we provide extra features just for it.
|
|
357
452
|
|
|
358
|
-
|
|
453
|
+
In most cases, when using `sj smartclone`, pass in `--forge-host`, and
|
|
454
|
+
that's about all you need, everything else should be handlded automagically.
|
|
455
|
+
|
|
456
|
+
However, you can set `forge_host` in your global or user config, but since most
|
|
359
457
|
users will also have a few opensource repos, you can override it in the
|
|
360
458
|
Repository Config as well.
|
|
361
459
|
|
|
362
460
|
So, for example you might have:
|
|
363
461
|
|
|
364
462
|
```yaml
|
|
365
|
-
|
|
463
|
+
forge_host: gh.sample.com
|
|
366
464
|
```
|
|
367
465
|
|
|
368
466
|
In your `~/.config/sugarjar/config.yaml`, but if the `.sugarjar.yaml` in your
|
|
369
467
|
repo has:
|
|
370
468
|
|
|
371
469
|
```yaml
|
|
372
|
-
|
|
470
|
+
forge_host: github.com
|
|
373
471
|
```
|
|
374
472
|
|
|
375
|
-
Then we will configure `gh` to talk to github.com when in that repo.
|
|
376
|
-
|
|
377
473
|
## FAQ
|
|
378
474
|
|
|
379
475
|
**Why the name SugarJar?**
|
|
@@ -382,7 +478,7 @@ It's mostly a backronym. Like jellyfish, I wanted two letters that were on home
|
|
|
382
478
|
row on different sides of the keyboard to make it easy to type. I looked at the
|
|
383
479
|
possible options that where there and not taken and tried to find one I could
|
|
384
480
|
make an appropriate name out of. Since this utility adds lots of sugar to git
|
|
385
|
-
and github, it seemed appropriate.
|
|
481
|
+
and github/gitlab, it seemed appropriate.
|
|
386
482
|
|
|
387
483
|
**I'd like to package SugarJar for my favorite distro/OS, is that OK?**
|
|
388
484
|
|
|
@@ -397,18 +493,18 @@ it on Windows, but I'll happily accept patches for Windows compatibility.
|
|
|
397
493
|
|
|
398
494
|
**How do I get tab-completion?**
|
|
399
495
|
|
|
400
|
-
If the package for your OS/distro didn't set it up
|
|
401
|
-
that `sugarjar_completion.bash` is included in the package, and you can
|
|
402
|
-
source that in your dotfiles, assuming you are using bash.
|
|
496
|
+
If the package for your OS/distro didn't set it up automatically, you should
|
|
497
|
+
find that `sugarjar_completion.bash` is included in the package, and you can
|
|
498
|
+
simply source that in your dotfiles, assuming you are using bash.
|
|
403
499
|
|
|
404
500
|
**What happens now that Sapling is released?**
|
|
405
501
|
|
|
406
|
-
SugarJar isn't going anywhere
|
|
407
|
-
|
|
408
|
-
|
|
502
|
+
SugarJar isn't going anywhere. This was meant to replace arc/jf, which has now
|
|
503
|
+
been open-sourced as [Sapling](https://sapling-scm.com/), so I highly recommend
|
|
504
|
+
taking a look at that!
|
|
409
505
|
|
|
410
506
|
Sapling is a great tool and solves a variety of problems SugarJar will never be
|
|
411
|
-
able to. However, it is a significant workflow change
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
developed.
|
|
507
|
+
able to. However, it is a significant workflow change that won't be appropriate
|
|
508
|
+
for all users or use-cases. Similarly there are workflows and tools that
|
|
509
|
+
Sapling breaks. Further, we support some things Sapling does not. So worry not,
|
|
510
|
+
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
|
|
@@ -118,15 +134,6 @@ COMMANDS:
|
|
|
118
134
|
Same as "amend" but without changing the message. Alias for
|
|
119
135
|
"git commit --amend --no-edit".
|
|
120
136
|
|
|
121
|
-
bclean [<branch>]
|
|
122
|
-
If safe, delete the current branch (or the specified branch).
|
|
123
|
-
Unlike "git branch -d", bclean can handle squash-merged branches.
|
|
124
|
-
Think of it as a smarter "git branch -d".
|
|
125
|
-
|
|
126
|
-
bcleanall
|
|
127
|
-
Walk all branches, and try to delete them if it's safe. See
|
|
128
|
-
"bclean" for details.
|
|
129
|
-
|
|
130
137
|
binfo
|
|
131
138
|
Verbose information about the current branch.
|
|
132
139
|
|
|
@@ -157,14 +164,66 @@ COMMANDS:
|
|
|
157
164
|
branches. Very convenient for keeping the branch behind a pull-
|
|
158
165
|
request clean.
|
|
159
166
|
|
|
167
|
+
forcesync, fsync
|
|
168
|
+
See 'sync' below, but never tries to rebase, always does a
|
|
169
|
+
hard reset.
|
|
170
|
+
|
|
171
|
+
globalbranchclean, gbclean [<branch>] [<remote>]
|
|
172
|
+
WARNING: EXPERIMENTAL COMMAND.
|
|
173
|
+
|
|
174
|
+
Combination of "lbclean" and "rbclean". Cleans up
|
|
175
|
+
both local and remote branches safely. See those commands for
|
|
176
|
+
details.
|
|
177
|
+
|
|
178
|
+
globalbranchcleanall, gbcleanall [<remote>]
|
|
179
|
+
WARNING: EXPERIMENTAL COMMAND.
|
|
180
|
+
|
|
181
|
+
Safely clean all branches, both local and remote. See "gbclean"
|
|
182
|
+
for details.
|
|
183
|
+
|
|
160
184
|
lint
|
|
161
185
|
Run any linters configured in .sugarjar.yaml.
|
|
162
186
|
|
|
187
|
+
localbranchclean, lbclean [<branch>]
|
|
188
|
+
If safe, delete the current branch (or the specified branch).
|
|
189
|
+
Unlike "git branch -d", lbclean can handle squash-merged branches.
|
|
190
|
+
Think of it as a smarter "git branch -d".
|
|
191
|
+
|
|
192
|
+
Aliased to 'bclean' for backwards compatibility.
|
|
193
|
+
|
|
194
|
+
localbranchcleanall, lbcleanall
|
|
195
|
+
Walk all branches, and try to delete them if it's safe. See
|
|
196
|
+
"lbclean" for details.
|
|
197
|
+
|
|
198
|
+
Aliased to 'bcleanall' for backwards compatibility.
|
|
199
|
+
|
|
163
200
|
pullsuggestions, ps
|
|
164
201
|
Pull any suggestions *that have been committed* in the GitHub UI.
|
|
165
202
|
This will show the diff and prompt for confirmation before
|
|
166
203
|
merging. Note that a fast-forward merge will be used.
|
|
167
204
|
|
|
205
|
+
remotebranchclean, rbclean [<branch>] [<remote>]
|
|
206
|
+
WARNING: EXPERIMENTAL COMMAND.
|
|
207
|
+
|
|
208
|
+
Similar to lbclean, except safely cleans up remote branches.
|
|
209
|
+
Unlike many git commands, <remote> comes after <branch> so
|
|
210
|
+
that you can specify a branch and the remote defaults to 'origin'.
|
|
211
|
+
This means you can do "sj rclean" to clean the remote branch with
|
|
212
|
+
the same name as the local one. Note that you probably want
|
|
213
|
+
"sclean", which will do both local and remote cleaning in one
|
|
214
|
+
command.
|
|
215
|
+
|
|
216
|
+
WARNING: This command cannot differentiate release branches
|
|
217
|
+
that are fully merged but still need to be kept around for future
|
|
218
|
+
work. So if main contains everything that 2.0-devel and 3.0-devel
|
|
219
|
+
has, then those branches will be deleted. Use with caution.
|
|
220
|
+
|
|
221
|
+
remotebranchcleanall, rbcleanall [<remote>]
|
|
222
|
+
WARNING: EXPERIMENTAL COMMAND.
|
|
223
|
+
|
|
224
|
+
Walk all remote branches, and try to delete them if it's safe. See
|
|
225
|
+
"rbclean" for details.
|
|
226
|
+
|
|
168
227
|
smartclone, sclone
|
|
169
228
|
A smart wrapper to "git clone" that handles forking and managing
|
|
170
229
|
remotes for you.
|
|
@@ -190,6 +249,20 @@ COMMANDS:
|
|
|
190
249
|
subfeature, sf <feature>
|
|
191
250
|
An alias for 'sj feature <feature> <current_branch>'
|
|
192
251
|
|
|
252
|
+
sync
|
|
253
|
+
Similar to `up`, except instead of rebasing on a tracked branch
|
|
254
|
+
(usually `upstream` remote), rebases to wherever our remote push
|
|
255
|
+
target is (usually `origin` remote). Useful for syncing work
|
|
256
|
+
across different machines.
|
|
257
|
+
|
|
258
|
+
For example, if you do some work on feature `foo` on machine1 and
|
|
259
|
+
push to `origin/foo` (intending to eventually merge to
|
|
260
|
+
`upstream/main`), then on machine2, you pull that branch, do more
|
|
261
|
+
work, which you also push to `origin/foo`, then on machine1, you
|
|
262
|
+
can do `sj sync` to pull down the changes from `origin/foo`. If
|
|
263
|
+
you have local changes, that are not already on `origin/foo`,
|
|
264
|
+
those will be rebased on top of the changes from `origin/foo`.
|
|
265
|
+
|
|
193
266
|
unit
|
|
194
267
|
Run any unitests configured in .sugarjar.yaml.
|
|
195
268
|
|
|
@@ -253,6 +326,12 @@ end
|
|
|
253
326
|
|
|
254
327
|
SugarJar::Log.debug("Final config: #{options}")
|
|
255
328
|
|
|
329
|
+
# if the command is help, we don't bother to create the Commands obj
|
|
330
|
+
if subcommand == 'help'
|
|
331
|
+
puts parser
|
|
332
|
+
exit
|
|
333
|
+
end
|
|
334
|
+
|
|
256
335
|
sj = SugarJar::Commands.new(options)
|
|
257
336
|
valid_commands = sj.public_methods - Object.public_methods
|
|
258
337
|
is_valid_command = valid_commands.include?(subcommand.to_sym)
|
|
@@ -268,13 +347,7 @@ SugarJar::Log.debug("subcommand is #{subcommand}")
|
|
|
268
347
|
extra_opts += argv_copy
|
|
269
348
|
SugarJar::Log.debug("extra unknown options: #{extra_opts}")
|
|
270
349
|
|
|
271
|
-
|
|
272
|
-
when 'help'
|
|
273
|
-
puts parser
|
|
274
|
-
exit
|
|
275
|
-
when 'debuginfo'
|
|
276
|
-
extra_opts = [options]
|
|
277
|
-
end
|
|
350
|
+
extra_opts = [options] if subcommand == 'debuginfo'
|
|
278
351
|
|
|
279
352
|
unless is_valid_command
|
|
280
353
|
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
|