|
yah that's a really dumb footgun with git to be fair you should be able to set up force push permissions on the git server though
|
#
?
Dec 15, 2017 14:28
|
|
|
|
| # ? Jun 8, 2024 14:12 |
|
|
comedyblissoption posted:yah that's a really dumb footgun with git you can e: https://coderwall.com/p/wo3kng/git-disable-force-push
|
|
#
?
Dec 15, 2017 14:35
|
|
|
the f in push -f is actually short for gently caress you
|
|
#
?
Dec 15, 2017 15:01
|
|
|
Compare the mercurial approach to destructive updates like rebasing, where they will allow rebasing a local changeset onto a published (immutable) one, but not the opposite (which would result in duplicate commits and conflicting histories). You can even set your config to show the phase in a graph: code:- Changesets exchanged with the outside are public and immutable. - Changesets committed locally are draft until exchanged with the outside. - Phases move transparently and you don't have to track poo poo. If you have a repo server instance that is usable for dev or a project only, you can mark it as non-publishing to keep poo poo mutable, but the moment your changeset is posted to the canonical one for the team, they could become immutable. The strictest form is always kept. You can also mark some branches as secret so that they never get pushed by accident: hg phase --force --secret <local-commit> You can also decide to want to mark all commits that should be publishable at first by just defaulting to secret commits, but that would likely confuse the newcomers as a default config: code:This whole setup basically forces you to do reasonable non-dangerous rebases if you want them. Git just lets you wreck whatever. MononcQc fucked around with this message at 15:08 on Dec 15, 2017 |
|
#
?
Dec 15, 2017 15:04
|
|
|
St Evan Echoes posted:tfw your dipshit coworker does a push -f on a branch you’re both working on lol if you let destructive changes happen on your repos
|
|
#
?
Dec 15, 2017 15:19
|
|
|
St Evan Echoes posted:the f in push -f is actually short for gently caress you alias gityolo='git commit -am "DEAL WITH IT" && git push -f origin master'
|
|
#
?
Dec 15, 2017 15:49
|
|
|
push -f onto your fork branch is literally the policy here you have to rebase on the integration branch before you open your pull request but after all development is done
|
|
#
?
Dec 15, 2017 16:32
|
|
|
CRIP EATIN BREAD posted:alias gityolo='git commit -am "DEAL WITH IT" && git push -f origin master'
|
|
#
?
Dec 15, 2017 17:10
|
|
|
immutable changesets are great assuming you trust all of your coworkers to never gently caress up
|
|
#
?
Dec 15, 2017 17:27
|
|
|
CRIP EATIN BREAD posted:alias gityolo='git commit -am "DEAL WITH IT" && git push -f origin master' theres at least 3 things wrong here that would get blocked by our commit hooks * commit message without a valid JIRA identifier * pushing to master without a pull request * force pushing is disabled
|
|
#
?
Dec 15, 2017 17:56
|
|
|
users shouldn’t be able to push to master imo, it should be an automated thing when a pull request completes
|
|
#
?
Dec 15, 2017 18:02
|
|
|
St Evan Echoes posted:users shouldn’t be able to push to master imo, it should be an automated thing when a pull request completes and a good build of the integration branch is achieved
|
|
#
?
Dec 15, 2017 18:06
|
|
|
alternatively, master should be whatever code you have in production at any given time. i guess it depends on your ~#!##==-- GIT FLOW --==##!#~
|
|
#
?
Dec 15, 2017 18:07
|
|
|
Valeyard posted:alternatively, master should be whatever code you have in production at any given time. i guess it depends on your ~#!##==-- GIT FLOW --==##!#~ we support versions of the product going back 5 years, so those live in service branches which support generating interim fixes
|
|
#
?
Dec 15, 2017 18:10
|
|
|
Valeyard posted:alternatively, master should be whatever code you have in production at any given time. i guess it depends on your ~#!##==-- GIT FLOW --==##!#~ I got so confused reading one of those git flow articles until I realized that it was mostly the same as my last job was doing, except there, master always had the latest code and hotfixes were made by branching off of the latest release tag, while most git flow advocates have master track the currently released version and have the separate release branch for the latest integrated stuff. I bet flows like that are a lot easier to manage when you have CI and stuff, which we didn't!
|
|
#
?
Dec 15, 2017 18:22
|
|
|
uncurable mlady posted:immutable changesets are great assuming you trust all of your coworkers to never gently caress up lol if you think people loving up have fewer chances of doing damage with a mutable history than an immutable one
|
|
#
?
Dec 15, 2017 19:00
|
|
|
also everyone shits themselves when someone fucks up git history
|
|
#
?
Dec 15, 2017 19:52
|
|
|
our git history is a steaming pile of poo poo, good luck trying to figure out where a change came from lol it means its easy to manage since you dont have to care (y)
|
|
#
?
Dec 15, 2017 19:55
|
|
|
ive been in current job for ugh... 2 years and 3 months since leaving uni wondering when its time for a change
|
|
#
?
Dec 15, 2017 20:00
|
|
|
no time like the present
|
|
#
?
Dec 15, 2017 20:10
|
|
|
im going to wait till promotion time in mid january, wont get the salary i want, and then start looking ive been speaking to some random linkedin recruiters passively, but might ramp it up time to start the yospos cv thunderdome
|
|
#
?
Dec 15, 2017 20:12
|
|
|
idk i flatten branches all the time so i don't have to pick through multiple commits to see my first shot and the testing/review changes, and that requires deleting "pushed" commits before they land in master. but the alternative workflow would be making a new branch and starting a new PR, which is a hit but a minor one
|
|
#
?
Dec 15, 2017 20:25
|
|
|
JawnV6 posted:idk i flatten branches all the time so i don't have to pick through multiple commits to see my first shot and the testing/review changes, and that requires deleting "pushed" commits before they land in master. but the alternative workflow would be making a new branch and starting a new PR, which is a hit but a minor one you have feature branch you finish your change raise pull request code gets reviewed you make changes to fix review comments (lol as if) in same branch pull request gets approved and you hit "merge + squash" option 1 commit makes it into master/dvelop/whatever branch youre merging the change into
|
|
#
?
Dec 15, 2017 20:28
|
|
|
Valeyard posted:pull request gets approved and you hit "merge + squash" option
|
|
#
?
Dec 15, 2017 20:33
|
|
|
our workflow is merge + squash and i don’t like it! esp when we have awful oversized tickets that have 3 weeks of solid dev work in them. way too much to squash into 1 commit
|
|
#
?
Dec 15, 2017 21:30
|
|
|
learn to interactive rebase u scrubs
|
|
#
?
Dec 15, 2017 21:44
|
|
|
People obsessed with commit history janitoring are bad people. Like make reasonable commits, fix-up/rebase interactive extra garbage stash/wip commits, and move on.
|
|
#
?
Dec 15, 2017 21:47
|
|
|
St Evan Echoes posted:oversized tickets theres your problem. i hate this. i hate opening a pull request and having to review some loving massive change (that could have been split up into different branches probably) if it couldnt, then at least raise the PR at some point and let someone review it as you go, rather than letting it build up to some big bang
|
|
#
?
Dec 15, 2017 21:52
|
|
|
https://twitter.com/Crypto_Lizard/status/941686238213369856 see you in six hours motherfuckers
|
|
#
?
Dec 15, 2017 21:54
|
|
|
sounds like maybe git's good if you git gud
|
|
#
?
Dec 15, 2017 22:06
|
|
|
i love when teammates screenshare their screen to me, and i can see they have 20+ seperate git checkouts, one for each branch they use
|
|
#
?
Dec 15, 2017 22:11
|
|
|
Valeyard posted:i love when teammates screenshare their screen to me, and i can see they have 20+ seperate git checkouts, one for each branch they use if they found a workflow that avoids obliterating their works in progress, that's good, ok better that they look dumb on a screenshare than that they lose hours of time because they didn't fully understand the consequences of `git reset` in a particular context
|
|
#
?
Dec 15, 2017 22:19
|
|
|
yeah git-reset is probably one of the worst-designed human-computer interaction constructs since for-else
|
|
#
?
Dec 15, 2017 22:24
|
|
|
deleting a remote tag, favorite git pet peeve
|
|
#
?
Dec 15, 2017 22:28
|
|
|
Notorious b.s.d. posted:if they found a workflow that avoids obliterating their works in progress, that's good, ok i get what you mean but when they refuse to learn how git works, and just sledgehammer approach use it the same way they would subversion, this leads to problems with people not understanding what they are doing or why they are doing it
|
|
#
?
Dec 15, 2017 22:30
|
|
|
people leaving merge conflict chevrons in their commits is ownage people actually approving this during code """""""""""""reviews"""""""""""" is even more ownage
|
|
#
?
Dec 15, 2017 22:34
|
|
|
pangstrom posted:sounds like maybe git's good if you git gud it’s not tho, which is a real shame for this joke
|
|
#
?
Dec 15, 2017 23:43
|
|
|
Valeyard posted:people leaving merge conflict chevrons in their commits is ownage git: 'gud' is not a git command. See 'git --help'. Did you mean this? gui
|
|
#
?
Dec 16, 2017 00:32
|
|
|
carry on then posted:git: 'gud' is not a git command. See 'git --help'. git config --global alias.gud 'push -f'
|
|
#
?
Dec 16, 2017 00:41
|
|
|
|
| # ? Jun 8, 2024 14:12 |
|
|
The git docs are super clear, I don't know why this is so difficult. https://git-man-page-generator.lokaltog.net/
|
|
#
?
Dec 16, 2017 00:49
|
|
