4 ms·

GitLab team member here. And I totally agree - I forget to use them all the time! And thoughts on making it easier? Maybe a suggested set of git aliases or som

GitLab team member here. And I totally agree - I forget to use them all the time! And thoughts on making it easier? Maybe a suggested set of git aliases or some sort of wrapper?

andrewstuart2 5y ago
Spit out tips in the push shell output from time to time, maybe? Not sure if you have guidelines around what can go there but I definitely appreciate the helpful stuff GitLab has added there.
- boleary-gl 5y ago
  GitLab team member here. I like this option a lot and I added https://gitlab.com/gitlab-org/gitlab/-/issues/359271 https://gitlab.com/gitlab-org/gitlab/-/issues/359271
mdaniel 5y ago
The docs page linked have git alias suggestions, but perhaps "git push -o gitlab.help"? And that operation would be free to abort the push in the same way that "git commit -h" doesn't actually execute the commit. I'd guess returning like the 5 most common options and then the URL to the help page would be stellar I lot of my problem is that I don't recall how "-o ci.varables" get merged; I have to say: > now, is it "-o ci.variables=alpha=beta,charlie=delta" or "-o ci.variables=a=b -o ci.variables=c=d"? .. and then that syntax gets jumbled up in my head with the "&var[alpha]=beta" syntax from the "/-/pipelines/new" URL so that just makes it worse And all of this is a fantastic discussion for someone who knows that subsystem exists, but just can't recall offhand the specifics -- but as for how a new user to GitLab would know about such a thing -- maybe at the bottom of the "/-/pipelines/new" page, show the equivalent "git push -o" syntax that would reproduce the pipeline request with its variables? And maybe the same at the bottom of the "create merge request" page, although that could be super chatty when multiplied by the number of times that create merge request page must be visited Even if none of this sounds appealing, I do sincerely appreciate you asking. It's this level of customer-focus and strive for improvement that makes me absolutely love GitLab!
- boleary-gl 5y ago
  I like a lot of these ideas, I added these issues: - Add squash commits option in push options for merge requests [1] - Show equivalent push options at bottom of /-/pipelines/new [2] - Show equivalent push options at bottom of create merge request page [3] [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/324619 https://gitlab.com/gitlab-org/gitlab/-/issues/324619 [2]: https://gitlab.com/gitlab-org/gitlab/-/issues/359268 https://gitlab.com/gitlab-org/gitlab/-/issues/359268 [3]: https://gitlab.com/gitlab-org/gitlab/-/issues/359269 https://gitlab.com/gitlab-org/gitlab/-/issues/359269 (edited for line spacing)
ZeroGravitas 5y ago
When you push, perhaps it could print out the default values as a hint they can be overridden, e.g. ci.skip=false would perhaps indicate to users that this is a setting that can be changed from the push.

GitLab team member here. And I totally agree - I forget to use them all the time! And thoughts on making it easier? Maybe a suggested set of git aliases or some sort of wrapper?

andrewstuart2 5y ago

Spit out tips in the push shell output from time to time, maybe? Not sure if you have guidelines around what can go there but I definitely appreciate the helpful stuff GitLab has added there.

boleary-gl 5y ago
GitLab team member here. I like this option a lot and I added https://gitlab.com/gitlab-org/gitlab/-/issues/359271 https://gitlab.com/gitlab-org/gitlab/-/issues/359271

mdaniel 5y ago

The docs page linked have git alias suggestions, but perhaps "git push -o gitlab.help"? And that operation would be free to abort the push in the same way that "git commit -h" doesn't actually execute the commit. I'd guess returning like the 5 most common options and then the URL to the help page would be stellar I lot of my problem is that I don't recall how "-o ci.varables" get merged; I have to say: > now, is it "-o ci.variables=alpha=beta,charlie=delta" or "-o ci.variables=a=b -o ci.variables=c=d"? .. and then that syntax gets jumbled up in my head with the "&var[alpha]=beta" syntax from the "/-/pipelines/new" URL so that just makes it worse And all of this is a fantastic discussion for someone who knows that subsystem exists, but just can't recall offhand the specifics -- but as for how a new user to GitLab would know about such a thing -- maybe at the bottom of the "/-/pipelines/new" page, show the equivalent "git push -o" syntax that would reproduce the pipeline request with its variables? And maybe the same at the bottom of the "create merge request" page, although that could be super chatty when multiplied by the number of times that create merge request page must be visited Even if none of this sounds appealing, I do sincerely appreciate you asking. It's this level of customer-focus and strive for improvement that makes me absolutely love GitLab!

boleary-gl 5y ago
I like a lot of these ideas, I added these issues: - Add squash commits option in push options for merge requests [1] - Show equivalent push options at bottom of /-/pipelines/new [2] - Show equivalent push options at bottom of create merge request page [3] [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/324619 https://gitlab.com/gitlab-org/gitlab/-/issues/324619 [2]: https://gitlab.com/gitlab-org/gitlab/-/issues/359268 https://gitlab.com/gitlab-org/gitlab/-/issues/359268 [3]: https://gitlab.com/gitlab-org/gitlab/-/issues/359269 https://gitlab.com/gitlab-org/gitlab/-/issues/359269 (edited for line spacing)

ZeroGravitas 5y ago

When you push, perhaps it could print out the default values as a hint they can be overridden, e.g. ci.skip=false would perhaps indicate to users that this is a setting that can be changed from the push.