Re: Revision control

[olafBuddenhagen]

Hi,

On Mon, Jun 30, 2008 at 09:24:29AM +0200, Arne Babenhauserheide wrote:
> Am Sonntag 29 Juni 2008 06:21:16 schrieb olafBuddenhagen@gmx.net:

> Just let your system look at the combined diff of all changesets the
> user added during the time he did a specific project, then you
> effectively have a cleaned version. 

Oh yeah, like in CVS... ;-)

Seriously, a large diff is not very useful. What we want is a clear list
of distinct changes, each in one patch, with a proper commit message
explaining what was done and why. Not less, and not more.

> But finding out which parts are garbage and which aren't might prove
> quite challenging to do before you need the information, since
> precognition isn't reliable enough, yet :) 

Actually, it's very clear usually. We want to know what changes were
applied in the end, and why -- but not how you arrived at them.

> Even seasoned scientists keep their working documents safe, so others
> can check them directly when they doubt the short papers produced from
> the results. 
> 
> And to me, rewriting history seems like locking away (and eventually
> burning) the working documents, once you created your papers. 

We are not talking about scientific work. It's not about drawing
conclusions from a large data set, and keeping the original data for
evidence. It's about keeping track of clear and specific changes to a
bunch of files.

> > abstract level, but on the actual object structure; always knows
> > what is possible, how things fit together, how to reach a desired
> > result; always has full confidence, knowing nothing unexpected can
> > happen.
> 
> As soon as he fully understands how the commands change it, yes.
> Before that: Sadly no. 

Yes, that's what I have been saying all along: You really need to take
to trouble to understand Git. Once you do, it is great.

> > This is so fundamental, because it means that no matter how much you
> > screw up your repository, you can always fix it; you never really
> > lose anything. Once users understand that, they never need to be
> > afraid of doing something wrong.
> 
> Until you garbage collect (It's about four commands in sequence,
> right?). 

One does not garbage collect by accident. You wouldn't do it if you
screwed up, before fixing stuff...

In fact, even if you do garbage collection, recent stuff is always kept
around for a while.

> > But luckily that's not the target audience for Git. Git users are
> > programmers -- people who already know how computers work, how
> > software
> 
> And the example was just one extreme end of the spectrum to illustrate
> the point. 
> 
> Anyone can get stuck there, even though the chance that a developer
> gets stuck is much lower than the chance of a computer-newbe to give
> up. 

I am convinced that every remotely capable developer can master Git, if
he takes the trouble. It is really not that complicated. (In fact, it's
beautifully simple IMHO...)

> > Learning the fundamentals of Git, gaining a deep understanding how
> > it works, shouldn't take more than a couple of hours. (If you start
> > reading at the right place at least...)
> 
> Please give me a pointer. 

   http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#git-concepts

and

   
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#low-level-operations

are a good start.

(I wish it would go a bit deeper in the same manner... In fact, IMHO the
manual should start with these things.)

There is also

   http://www.newartisans.com/blog_assets/git.from.bottom.up.pdf

for example, which mostly says the same as the above, in a bit more
prose.

(I don't like everything in that document, though... Especially the part
about stashes is rather stupid. With a deep understanding of Git, it
should be easy to write a proper "snapshot" script, rather than misusing
stashes for that...)

> > Git does change some things in the UI, forsaking CVS compatibility,
> > so it can make them better. "git-checkout" is a formidable example
> > of that.
> 
> For me, the change above is a change to the worse, but I can't comment
> on the rest yet, so I can't say if the overall usability improved. 
> 
> It could be easily fixed with simply adding a comment at the end. 

Indeed, a short explanation would be useful...

I'm just saying that the way the command works is very logical and
consistent. I'm not claiming the error reporting is perfect :-)

> The Hurd makes writing your own translators very easy, for example,
> and once it gets some serious traction, I expect many people to step
> up and write translators, just like people are much more likely to
> write plugins for other systems than to dabble with the core code. 

Well, that is what I hope as well :-)

Unfortunately, it's not really easy to write translators right now --
just looking at the time it took the GSoC students to get skeleton netfs
translators going, shows that quite clearly :-(

I only hope that this gets better when nice bindings for other
programming languages are available.

(I fact, I tend to think that it must be possible to create more
friendly translator bindings in C as well...)

But well, this is quite utterly off topic in this discussion :-)

> > Aside from such controversial features, I'd be much surprised to
> > learn that Git has *not* yet surpassed any proprietary VCS in every
> > aspect long time ago...
[...]
> But then, friendly competition by other free VCSs is even more
> important to keep people pushing limits (and to avoid projects getting
> crusty ;) ). 

Indeed. That's what happened with CVS: In lack of competition, lack of
inspiration, it it didn't move at all for over a decade, and although
everybody was annoyed by that, nobody cared to do anything about it...

It's a sad business, that it was in fact a proprietary product (anyone
still remembers BitKeeper?... ;-) ) which finally spured work on modern
(free) VCS:s -- producing more than half a dozen in a relatively short
timespan...

There are many other examples of projects that became "crusty" in lack
of serious competition: X, Mutt, Screen...

> I prefer using Mercurial, and I think that Mercurial is better than
> Git in some places, but that doesn't mean I'd say "noone should use
> Git". 

Indeed. As I already said, although I'm pretty convinced that Git is the
superior tool for serious programmers, I'd probably actually recommend
use of Mercurial in certain situations involving other audiences...

(Hah, I'm feeling so generous! ;-) )

-antrik-