On Friday, March 13, 2015 at 2:57:04 AM UTC-5, Fredrik Gustafsson wrote: > On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote: > > And, Mercurial is a tool that makes it very hard to shoot yourself in > > the foot. Git makes it very easy to lose data permanently, even when > > you're doing something like a *push* which should *never* lose data in > > my opinion. Mercurial also is a lot easier to pick up with fewer > > concepts that need understanding. So I think people who occasionally > > need to dabble in Mercurial are probably better off than people who > > occasionally need to dabble in git. > > I don't care about if vim uses mercurial or git, but please don't use > FUD as an argument. > > It's _very hard_ to loose data with git, and you can't loose data with a > push. > > What you probably mean is that a push -f would move your branch pointer, > possible to a branch that does not contain all commits. Now this is > stupid to do if it's a public branch, so hopefully this will be denied > by the server (if the server is setup correctly). >
Yes, that's mostly what I was referring to. While long-time git users may find it obvious that push --force is a stupid thing to do, new git users may not realize that. I sure would not have thought of that; I certainly would never have thought that it could destroy commits on the public repository. 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. 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. -- -- 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.
