Re: Revision control

[Arne Babenhauserheide]

Am Samstag 07 Juni 2008 17:47:28 schrieb olafBuddenhagen@gmx.net:
> You are missing the point. With git, *it is not necessary* to extend --
> it's all there; git itself already allows doing pretty much anything
> conceivable!

Just to make sure I understand you correctly: Do you mean "with the basic 
commands of git"? 

These naturally are the base for any higher level scripts, just as it is the 
case with Mercurial, so you can also archieve everything using them - it just 
isn't very convenient to do so. 


There are a few things, which aren't yet possible with Mercurial, though. The 
ones I know about are: 
- 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 Mercurial has one disadvantage: 
- Branches are a bit "heavier" (though I didn't see the effect of that when 
working with repositories). 


At the moment, I don't see any other weaknesses (I might have forgotten some), 
but definite advantages in usability. 


> Which isn't surprising at all. git-checkout by default preserves local
> changes; and deleting a file is a change. "git-checkout -f" on the other
> hand would probably do what you want -- and a short look in the man page
> should tell you that.

Should, but didn't. 

And looking for the second time didn't either. 

And "preserves local changes" is only true, as long as I don't give the 
deleted file as argument. 

Now, as I look at it the third time, knowing the exact parameter I want to 
check, I found it: 

--- man ---
       -f     Proceed even if the index or the working tree differs from HEAD.
              This is used to throw away local changes.
--- /man ---

Knowing that git only tracks data, not files, it makes sense to do it that way 
(and to express it like that in the man page). But I didn't find it in two 
readings of the man page plus searching in google, and nothing in the output 
of git checkout told me that 'git checkout -f' might have solved the problem. 


If git isn't readily usable for me, then it is quite probable, that it is 
unusable for many programmers, including some who might be interested in 
contributing to the Hurd. 

And every git user will be a newbe at one time, so he will do newbe mistakes 
which will in turn lead to a time loss for the project, because someone will 
have to undo those mistakes. 


> Actually, the command was probably "git-checkout-index -a", which still
> works. It does something slightly different than "git-checkout -f" or
> "git-checkout .": It checks out deleted files, but doesn't overwrite
> modified ones.

That's what I mean with confusing. It's specified, but it isn't clear, at 
least to me. 

It seems that it does what 'hg up' aka 'hg update' does. 


> > If I don't pass any files to, it returns the status of all files.
>
> Actually, it does a bit more than only printing the status. It just
> happens in this specific situation that it has no other visible
> effect... I suggest reading the man page :-)

I tried quickly finding a solution to a specific problem. 

I might have found the solution reading the man page from beginning to end and 
doing it again afterwards. But in the end, it was much quicker to just delete 
the repo and clone it again, and that doesn't cast a good light on its 
documentation. 


> My experience (from what I saw in Xorg) is that people having *serious*
> problems with git usage (i.e. problems that can't be solved by looking
> at the man page(s) for a moment), are generally a result of not
> bothering to understand the basic concepts of git. This is just as
> appropriate as complaining about UNIX usability without understanding
> UNIX concepts...

Why do I _have to_ understand its basic concepts to use it without running 
into problems (as opposed to wanting to understand them, because they 
interest me)? 

UNIX usability is great. I didn't understand most of its basic concepts until 
I learned them in my informatics class at university, but I could use it 
quite well, because current tools provide a system which (mostly) just works. 

Besides: I can use git _now_ (and I mostly understand its concepts, I think), 
but it took a good deal of effort to get used to it, and I still stumble at 
times. 


> I'm not claiming that git is perfect. I'm only saying that learning to
> use git is worth a bit of trouble IMHO. I just can't agree that we
> should always go for the simpler tool, if the more powerful one is
> harder to handle at first...

I don't say, we should always go for the simpler tool (and I also don't think 
Mercurial is perfect). 

But I think going for the simpler tool is useful, if the more complex tool 
doesn't offer significant advantages for the project. 


The "power features" in git solve problems which I don't see in the Hurd, as I 
don't see them in most other projects. 

And in my eyes the potential of Mercurial and git is about the same. What 
mostly differs is the order in which their features were (and, I assume, will 
be) implemented. 

For Linux development, where (as I now know) 40% of the sourcefiles are 
changed from one version to the next, and where most people who dare touch 
the code are longterm kernel hackers, git is the better choice, I think.  
Almost half the files have to be touched for the change between two major 
versions, so opening a pack should be faster. 

In a project like the Hurd, whose development (I assume) will mostly be in its 
servers which won't change a lot after they reach a stable state (since its 
basic design is more stable, I think), and where every user can write, easily 
test and contribute new servers (and only needs to know the proper interfaces 
for doing so) Mercurial has an edge, I think. 


And then there's one other advantage in Mercurial which is easy to overlook 
(and which I overlooked in the beginning), since I got so used to it, I 
didn't even realize anymore that I use it: local revision numbers. 

While each revision has a unique ID, it also has a local revision number, so I 
can just do 

$ hg up 23

to get the revision 23 aka (for example) f7f129314465, instead of having to 
say

$ git checkout 5bdc29ebf0c06f43c1165c03273111b5090de3ca


Best wishes, 
Arne
PS: I just found another nice side by side feature comparision, also including 
many other VCSs: 
- http://versioncontrolblog.com/comparison/Git/Mercurial/index.html

PPS: Yes, I think that the VCS system matters for the Hurd, but maybe not in 
the proportion in which I invested time in the discussion. In the end their 
repositories can easily be converted for other systems. 
But I like using Mercurial, for code as well as for text files and many of my 
personal documents. 
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.