Why only Google and Facebook engineers?
I use both Mercurial and Git, and honestly, they aren't that different. Unless you're doing something very specific I don't see why you would choose one over the other.
I use both Mercurial and Git, and honestly, they aren't that different. Unless you're doing something very specific I don't see why you would choose one over the other.
I don't know much about mercurial. I use git because somebody said it is easier to rewrite history in git.
I may also rebase my work onto the latest head at the end (not to be confused with git HEAD).
And all of this with a very nice interface. It's always --interactive, not sometimes --patch and sometimes --interactive.
Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.
Git allows you to push commits to other people and then rewrite history, which is different
I knew that pushing a rewritten history was possible, but I can't think of any situation where I would ever want to do that.
http://michaeldehaan.net/post/116465000577/understanding-whe...
Is this really interesting for you that it took me 10 commits to do sO ? Even if one of the commits was just a "I have to switch an fix a bug and want to commit before switching to another branch" - commit ?
I think there is nothing wrong with rebasing and to merge commits before pusing them.
AFAIK rebase is the only operation that happily destroys your history without any --force or --hard option. It always disturbed me.
There is a legitimate usage of rebase though: you really want something removed from history. Like you accidentally committed a secret, inappropriate message or you just want to fix a typo in the last commit.
This is SUPREMELY valuable for OSS patch workflow and I absolutely love git for having it.
source: http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_a...
Sounds like you should be using Subversion then.
Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it?
Personal beliefs don't advance computing, hard facts do.
Note that there's a lot of social problems around DVCS, and the thing Ben worried about is still a _real problem_. I get potential contributors showing up with months of work, and it's an enormous pain in the ass (both for them to rewrite and for me to beg them to work with me) when they did something architecturally unacceptable early in the process that a simple 2 minute review could have caught.
I just envision someone insecure (like I feel at times) saying, well, I'll just clone this and play around on my own machine. Then after making some commits and building up courage, saying, OK, I'll try and go public with this. With centralized VCS that seems less likely to me. The insecure programmer just won't even try. I don't know, it's probably different for different people.
I do not. Could you please explain?
At work I learned to use mercurial and never felt the need to pick up git since I can use the hg-git plugin.
Using VCS's other than git and mercurial people still end up doing essentially the same thing, they are simply required to do all the cleanup outside of the VCS before they commit. Almost nobody commits every sloppy, intermediate, untested edit of their files to svn or perforce. Users of those VCS's "rewrite" and "throw away" history just the same.
Footnote:
1. They both keep the original commits around after they are replaced by "rewritten" or "edited" commits. git does eventually delete the old history with its garbage collection, but it takes a number of weeks for that to happen. Mercurial saves backup bundle files (or obsolete changesets if using the evlove plugin) indefinitely. You have to manually delete them.