But it's the workflow we've gone for, and there's quite a number of others that use this too () I think checking a box in Preferences to say "I want to see that option because I understand it" adds a little extra firewall that will make it more likely that it's only used by people that are fully aware of the consequences. I think if they got an error about creating new HEADs on the remote and the force button was right there, even with a warning they could quite happily click straight through just to get out of there even if they have absolutely no idea what it does. The reason? People often push in a rush (maybe as they try to get out the door at the end of the day!), and this is a perfect time for rushed decisions and 'warning blindness'. I still think that to support it, I'd like to make this an enableable option in preferences first rather than just always having the Force checkbox on the Push dialog with a warning behind that. The problem with GUIs is that they can give people a false sense of security when exposing things like this! If people fully understand that, it's no problem. OK, that's pretty much what I thought - it does require people to know what they're doing, and does require an occasional 'cooridination dance'. That should make it sufficently difficult for anyone to accidentally force push, and only give the option to people that know what they're doing.ĭo you have any more questions regarding my company's workflow? Perhaps not only have a warning on setting the option to display the feature, but also a disable-able warning when selecting the force option in the push dialog, and not remember the force option of course. All you're doing is giving them the choice to force push if they really, really, really want to. If people screw things up by force pushing, then that's their fault. It's also worth noting that git DOES allow you to rewrite history, and is one of the main reasons why it's such a powerful (yet potentionally dangerous) DVCS ) A simple archive and prune can do that for you. Yes, clean up is also required once the repo starts to get a little too hefty. ![]() If you can communicate with anyone who has a local copy of your branch-Which 9/10 you do not need to do, due to it being your feature/dev branch-then you can co-ordinate the merge process, which for them is simply to delete their local ref of your branch. It can be a lot of effort to maintain occasionally, but this is mostly down to communication. So there's a copy up on the cloud (Also handy for if you screw up your rebase and want to reset back, got a nice little ref sitting there) You're right with that, but although our company is only 25 people, we can frequently have people out and about, call in sick, lose their laptop, or simply want to share code, and therefore it's best to always push whenever possible. It simply means they should be difficult to access, or come with a couple of warning messages-As you say, just to make sure they really know what they're doing. I perfectly understand that a GUI should be easy to use, and make it hard to screw things up on, but that doesn't nessecarily mean that features should be cut out. It's worth noting that the default behaviour of Mercurial 2.2 is to not even allow you to rewrite changes you've pushed (via phases).Īssuming you're talking about git, what sort of setup you have to avoid the nasty consequnces of rewriting? I'm thinking that if I did allow this, I'd require people to explicitly opt-in to have it displayed on the push dialog, perhaps in Preferences with a "Yeah, I really understand what I'm doing" warning message. If anyone did pull, or did base their own commits on top of those which you've now rewritten, then it's a world of hurt. ![]() I guess if you have a situation where no-one ever pulls anyone elses branches (in git) then this might not be such an issue, barring having lots of orphaned commits which will eventually need cleaning up. If you have, and you then rebase them on top of someone elses branch, then anyone that pulled or fetched the commits before you rebased them now has dead lines of development. ![]() ![]() The way I see it is if you really understand these dangerous options, you'll find a way to do it.Ī rebase workflow is fine, and should not require a force push - so long as you haven't pushed those commits before. A GUI is supposed to guide you through potentially unfamiliar territory without leading you into a bear trap - that's why I've resisted having easy access to this. I've seen other people use tools which have an easy "Force" option that they reach for immediately without understanding the consequences, and they've deeply regretted it later. My problem with it is that every time I've seen force push done, it's been a mistake.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |