On Fri, Mar 13, 2015 at 07:43:57AM -0700, Ben Fritz wrote: > As for the server disallowing it, consider when you are pushing to > something that might not even BE a server; perhaps it is a backup > repository, or some intermediate repository, or a repository you set up to > share your work with others, or perhaps your team just doesn't use GitHub.
This has nothing to do with github. You can't push to a non-bare repo and public bare repos you should always consider denying force-push to. > > I was reading an article (I can't find it now) where the author LIKES git, > and uses it more than other systems, but warned about destroying *other* > people's work by using push -f. I think these are valid things to worry > about with git; you need to LEARN to never use push -f. In Mercurial it is > very hard to remove commits by design. Git removes commits all by itself > in some situations, also by design. > > I was missing a key concept, which Erik kindly provided me in his link: > git is designed to forget things that need forgetting. Mercurial is > designed to keep everything unless told to do otherwise. Coming from > Mercurial, git's behavior here seems dangerous. I'm sure that if I had > learned git first, I'd find Mercurial's behavior at least mildly annoying. > > > Second, if a commit become unrefered by any branch or tag, it will be > > garbage collected, but first after 2 weeks. > > > > Yes, this was another thing I was referring to. Coming from Mercurial, > that actually seems like a very big danger, because in Mercurial you can > have dangling heads all over the place and they will stay there forever > unless you intentionally delete them. I understand now that in Git, > unnamed branches are WEIRD things that rarely (if ever) get used. > > I think calling this FUD is unfair; it's not FUD, it's a matter of > familiarity. If you're familiar with Git, sure, these things are > understood and probably don't ever happen. But if you only use git > occasionally, you don't know these things *can* bite you, so they probably > will sometime. > > I'm not going to get into other things I like/don't like about the two > systems, because I don't want to get into a long discussion about it. I > know I'm not going to change anyone's mind who already prefers git over > Mercurial. And I now understand *why* git does these things, due to it > being designed for use on a huge, distributed project. I think you described the differences pretty well and objective(!). Mercurial thinking that everything you ever tell it should be there forever and git thinking that you should be able to prepare something nice and change it until it's ready to be public, and then it should never be changed. Two different views, and in my opinion it boils down to that you should know your tools. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: [email protected] website: http://www.iveqy.com -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
