Re: Revision control

[Arne Babenhauserheide]

Am Freitag 20 Juni 2008 02:22:45 schrieb olafBuddenhagen@gmx.net:
> 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.