Open bowernite opened 3 years ago
I like that idea. If you want to send pr, I'd love to review it :)
Do you have any thoughts on what should be the default behavior (i.e. to
push or not)?
Having owned and used this code, you probably have more context than me
for what's more expected out-of-the-box. Though I understand if the project is still in its relative infancy and we just want to roll with
something and see what the feedback is like.
Also probably want to consider the "breaking change" it would be to change the default to not commit (though this isn't really a serious breaking change to many I'd imagine)
I'd say let's leave the default to push as the point at least for me of this tool is to commit & push without hassle whilst still keeping commits have some value.
For implementation, I'd add a flag --no-push or something similar that will only commit.
Just read Whether that means adding a CLI flag like -c
. -c
is nice flag too, I assume it stands for commit
and is easier to type than -no-push.
Although one thing I did read is to have more verbose flags, it's better UX. Spefically if one can autocomplete on flags, it's just much better.
p.s. this tool lacks --help
, ideally it gets added too.
👍 I'll go with --no-push
if I get around to tackling this
Feature ✨
Modify the command in some way to allow just the commit aspect, without pushing.
Rationale
Right now, the command takes 3-5 seconds, and I assume that's because
gitupdate
pushes no matter what.In cases where I don't really care to push right now, and just want a quick commit, it'd be nice to have it be quicker. Whether that means adding a CLI flag like
-c
or-n
, or changing the default and having consumers dogitupdate . && git push
and/or setting up a shell alias for it.Maybe I'll just get used to the behavior, but at least wanted to make an issue for it and bring it up for discussion.