Re: Revision control

[Arne Babenhauserheide]

Am Sonntag 29 Juni 2008 06:21:16 schrieb olafBuddenhagen@gmx.net:
> I'll try to keep it in mind... But no promises :-)

Thanks anyway :-) 

> Sanitizing history is about purging stuff that doesn't matter for the
> end result; not about dropping important information. If people don't
> understand the importance of proper commit messages, you are screwed, no
> matter what workflow.

How do you know now what will be important later on? 

> > You just let your system search through a batch changesets at once,
> > then it looks the same for the reviewers as modified history,

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. 

> > - Enable me to put changesets into a group. - Hide all grouped
> > changesets from the log and show their groups instead. - Only look at
> > groups. - Also group groups.
>
> This is an interesting feature :-)
>
> But it doesn't alleviate the fact that garbage in the history is a bad
> thing, period.

Sure, garbage in history is bad. 

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

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. 

People often disappear from view, especially in free software projects, and so 
I wouldn't want to have to rely on them to keep their personal history. 

Still the size of the tree and speed is to be considered - the only reason for 
me to rewrite history. 

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

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

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

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

(I didn't yet find the right place, it seems, since I don't think I really 
have a deep understanding how to interact with its internals)

> So the same nonsense as in CVS.
>
> (Don't tell me "update" makes more sense than "checkout" when going back
> in history or switching branches... It just doesn't.)

I only said: It's consistent with SVN and it has a shorter alias :) 

And that "git checkout ." and "git checkout" confused me badly. 

> The pitfalls only exist if you are coming with wrong assumptions based
> on other systems. There are no pitfalls if you actually understand what
> "checkout" does in Git -- it's different than other systems, but
> perfectly logical and consistent in itself.

But since most of us come from other systems, the pitfalls are there for us. 
Especially when we want to check a projects source, first. 

> Wrong. It told you that it can't check out, because some files are
> locally modified (by deletion).

Well, the output looked similar to this, just with far more files: 

------
$ git checkout
D       Rakefile
------

No information which said "can't check out". It rather looked like "svn 
status" to me. 

There was no information about an error. 

For an error, I'd at least have expected to see

------
$ git checkout
D       Rakefile
# Can't checkout, because there are local modifications. 
# Use "git checkout -f" to throw away local changes. 
------

or the like. 

> The result of an error condition is always vastly different from
> successful operation...

> The point is that without change, things can never get better.
>
> 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. 

> > Could you create a different list, so we can merge (or get two lists
> > for different sets or priorities)?
>
> Not without some serious consideration... Perhaps I will think about it
> some time over the next few days, or perhaps I won't. No promises.

No problem. 

It would just be interesting for me (and maybe also to create a unified 
viewpoint we could put into the wiki as soon as we found a solution). 

> That's not entirely true. Certain design choices make some things easier
> and some things harder. If something is too hard, it likely won't be
> implemented, or very late, or only half-heartedly...
>
> There is for example nothing that can be done on the Hurd, which
> couldn't be also done on Linux *somehow*. But some things are just much
> much simpler to do on the Hurd...

But the design choices were taken for a reason, and if the reasoning goes 
deep, then they are based on the projects philosophy. 

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. 

this is partly due to the philosophy of the Hurd to give users freedom in 
their working environment, even when they aren't its admins. 

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

I don't know all proprietary VCSs, so I was careful about making that 
statement, for Git just as well as for Mercurial :) 

But then, friendly competition by other free VCSs is even more important to 
keep people pushing limits (and to avoid projects getting crusty ;) ). 

So if anyone would come to me and say "Noone should ever use Git!" (while it 
is still in active development) he'd likely get a (verbal) knock on the head. 
If he'd say the same about Mercurial, the knock might be a bit harder (I'm 
not free of emotions, and I just like the feel of using Mercurial ;) ), but 
the reason to knock would be the same: Don't just bash another system, which 
is useful to the general development of systems. Talk reason instead. 

Well, maybe the knock would also be a series of "why"s ;) 

Why do you think so? Why that? Could you explain your reasoning below that 
thought? And why do you think it is like that? ... 

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

And if I should ever say it (while Git is still actively developer), I hope 
there'll be someone to give me the verbal knock :) 

Best wishes, 
Arne
-- 
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.