Re: Revision control

[Arne Babenhauserheide]

Am Sonntag 22 Juni 2008 02:44:25 schrieb olafBuddenhagen@gmx.net:
> I said at the beginning of this discussion that I doubt any other system
> offers this kind of directness and flexibility, and you haven't
> convinced me in the course of it that Mercurial does. In fact, you
> haven't really tried. Rather, you are trying to convince me that this
> doesn't matter. But that's hopeless -- you won't succeed here; I can
> assure you of that.

I tried to get the point accross, that in my view the "unabstracted interface" 
doesn't really provide you with additional flexibility, but rather costs more 
that it brings. 

> I may not be able to argue this very well (I'm generally not very well
> at arguing my points, as others here can confirm); but it is
> nevertheless a very deeply held belief -- I am absolutely sure that this
> kind of flexibility *does* matter very much.

I don't have (and don't want) that luxury of such deeply held beliefs (at 
least I try to avoid them), so I checked out gits features and played with it 
while we were discussing here, and I saw things where it is really good, but 
happily went back to Mercurial afterwards each time. 

> > 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.
>
> So it introduces an additional concept to achieve the same effect?
> Sounds like something that actually complicates the interface and
> sacrifices flexibility...

It includes the concept of the patch quilt, which seems to have been rather 
standard before, so they built on that work. 

> I guess you are aware that it can be done the same way in Git?...

No. 

Can I use 
git commit -a -m "blah and foo" blah.c foo.py

? 

> Anyways, I don't quite understand what you are getting at. How is this
> related to large projects?

In a large project where you only maintain a small part of the whole tree, 
you're likely to want to commit only the parts 

> > # 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))
>
> Yes, Git exposes the index -- this is one of the concepts one needs to
> understand to use Git properly. And one of the reasons why Git is so
> powerful: Rather than using some hidden state magic during certain
> operations (merge, rebase etc.), everything is explicit and transparent.

It could just assume that someone who commits really wants to add the changes. 
That's a UI thing, not something of the backend. 

And here it optimizes: by default commit only what you explicitely added, 
instead of by default committing what you changed. 

> > # I want to see all changes in my working tree
> > git checkout .
>
> What do you mean by "seeing changes"? 

I mean seeing the changes done by others which I just pulled. 

> > # And now the same using the provided shorthands in Mercurial, saving
> > much typing.
>
> If the "efficiency" of Mercurial's interface is manifested mostly in
> saving a few characters here and there, I'm deeply unimpressed.

That's what is called "usability". Archieving the same, but more comfortably 
and easier to learn for new users. 

With git I have to type these "few characters" in every single version 
tracking action I do, and I do many of those, so it accounts for much lost 
time and effort. 

I commit every time I do an untrivial change, so I can later track what I did, 
so the few strokes become rather much on the long run. 

> > # And going back to a specific revision in your local tree
> > git checkout d3d7b2f9088b90f21d2dd92869078e7ad3a1724a
> >
> > hg up 35
>
> Or "git-checkout d3d7b2f". Admittedly, this is still more cryptic than
> "35", but I don't think it matters much -- you have to explicitely look
> up the ID in either case...

Good to know that git has a shorter version, too. 

> > Due to that optimization (track mostly your part, squash changes,
> > ...), Git requires people to learn a completely new set of commands
>
> No idea what you mean :-(

I mean: 

> > that it favors some and makes others slightly less efficient.

and for that it uses a new set of commands people have to learn. 

> > 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.
>
> Indeed, Git's UI makes a clean cut for the most part. The result is that
> aside from a few glitches, it is actually remarkably logical and
> consistent (once you ctake the trouble to learn it properly) in a way
> that nothing trying to resemble CVS can ever be -- CVS is already
> inconsistent in itself, and trying to preserve the interface in a
> distributed system can't really work very well IMHO.

You didn't yet try out Mercurial, yet you say it can't work well. 

Mercurial works very well, and it works instantly and without hassle. At least 
that's how it was for me. 

> As much as I generally insist on the importance of keeping familiar
> interfaces (like keeping UNIX interfaces in the Hurd), this only makes
> sense, if people can actually use them without relearning much. But
> that's not the case when switching from CVS to a distributed system --
> here you *always* have to relearn. Using similar commands will only
> create the *impression* that no relearning is necessary -- and that way
> probably do more harm than good.

Having similar commands will show that many concepts of distributed systems 
are very similar to centralized ones, and that's a good thing for me. 

"git checkout" updates your working files, so why not call it "git update"? 
Because what it does in technical terms is checkout the files from the local 
repository.
What it does for the user is update the working files, though, and asking for 
that is what people are used to. 

But the Git people didn't even include a command alias to make it easier for 
people to switch. 

> > Did you try out Mercurial now?
>
> No, didn't need it so far.
>
> As much as I'd like to know it to be able to have a better founded
> discussion, this is not really reason enough to learn it :-)

Just try it for 15 minutes. You might be surprised how quick you become 
familiar with it. 
Each single mail I wrote took more that 15 minues (and I assume it's similar 
for you), so the time will be well invested, if it will avoid only one 
unnecessary email :) 

Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

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

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