Re: Revision control

[olafBuddenhagen]

Hi,

On Fri, Jun 20, 2008 at 12:00:42PM +0200, Arne Babenhauserheide wrote:
> 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.

These are differences in specific features. While I guess that Git is
pretty complete in this regard, it's not really what I'm talking about.

What I mean is that every project and every individual has a somewhat
different workflow; and that there are always situations where you have
to do something unusual. Most software is designed with specific
workflows in mind, and if they don't exactly cover your needs, you have
to adopt your workflow, kludge around it, or modify the software.

Git is exceptional in that with the very direct, unabstracted interface,
there are no restrictions what you can do -- untypical workflows and
actions are often as easily done, or only sligtly harder, than the
standard ones.

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 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.

> 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...

> And Gits more complex basic interface is specialized for big projects
> like Linux.

I fail to see anything specialized in Git's interface, for big projects
or otherwise.

> 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 guess you are aware that it can be done the same way in Git?...

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

> # 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.

> # I want to see all changes in my working tree
> git checkout .

What do you mean by "seeing changes"? If you mean just seeing what has
changed, "git-status" would be the right command. If you want to
integrate changes that happened on the branch in the mean time into your
working tree, "git-checkout -m" is probably the right command. (Didn't
have the need to do this so far... With a distributed system, the more
natural workflow usually is to merge or rebase only after committing --
though I can see situations where it will be different. As I said,
flexibility is important...)

> # 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.

> # 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...

> 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 :-(

> 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. 

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.

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.

> 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 :-)

-antrik-