Am Freitag 20 Juni 2008 02:22:45 schrieb [EMAIL PROTECTED]: > Every project has a different workflow -- both small and large. Git is > nice because it serves *all* kinds of workflows; it is extremely > flexible in this way. Again, that's what I like about it...
I already wrote about the three things (i remembered at that time) in which Mercurial is weaker than Git: - Simple rebasing. (You can rebase, but that includes some effort; there isn't yet a simple script doing it, except using Mercurial queues instead of branches) - Simple cherry-picking (same here). - Using an unrelated repository as base for changesets. And the workflow of having local branches and rebasing them can be archieved with mercurial queues. That's about the same workflow, but a different way of realizing it. It enables you to do most workflows with greater ease and less command typing overhead, though. And Gits more complex basic interface is specialized for big projects like Linux. Just look at the things which take the least amount of time/typing compared to Mercurial. # I only want to commit blah.c and foo.py in their current state. git add blah.c foo.py git commit -m "blah and foo shine now" -> commit can also be done later. hg commit -m "blah and foo shine now" blah.c foo.py -> not much more efficient, but the files can't be selected incrementally. I'd recommend using the record extension in this case, where you can select the exact data to commit. # I want to commit all changes (which are only blah.c and foo.py). git commit -a -m "blah and foo shine now" hg commit -m "blah and foo shine now" -> Somewhat more efficient (one parameter less to type (or forget)) # I want to see all changes in my working tree git checkout . hg update # And now the same using the provided shorthands in Mercurial, saving much typing. hg ci -m "blah and foo shine now" blah.c foo.py hg ci -m "blah and foo shine now" hg up # And going back to a specific revision in your local tree git checkout d3d7b2f9088b90f21d2dd92869078e7ad3a1724a hg up 35 Due to that optimization (track mostly your part, squash changes, ...), Git requires people to learn a completely new set of commands and to garbage collect from time to time (yes, I know that this doesn't matter to you, but it does to me - I don't want to have to care for my tools, they should take care of themselves, so i can worry about more important matters, like the code I write). That doesn't mean, it doesn't allow certain workflows, it only means, that it favors some and makes others slightly less efficient. The same is true for Mercurial, just with a different focus and with a command set which people who know CVS and SVN can understand with ease. Did you try out Mercurial now? Best wishes, Arne -- Weblog: http://blog.draketo.de -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software.
signature.asc
Description: This is a digitally signed message part.
