base

base

[Alan Mackenzie]

Hi, Emacs!

Both here and in other contexts I keep reading the term "rebase".  I
don't think I had heard it at all a few months back.

Would somebody please tell me exactly what "rebase" means.  I have an
idea that it means this; when working on a branch, sometimes the
upstream is enhanced; to "rebase" is getting the enhancements into the
branch one is working in, together with all the administrivia.

Thanks in advance!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: base

[Eli Zaretskii]

> Date: Sun, 22 Aug 2010 12:06:42 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Would somebody please tell me exactly what "rebase" means.

Typing "define:rebase" into Google brings this definition:

    To clean a branch by starting from the head of the main line of
    development ("master"), and reapply the (possibly cherry-picked)
    changes from that branch.

Re: base

[Alan Mackenzie]

Hi, Eli,

On Sun, Aug 22, 2010 at 08:20:58AM -0400, Eli Zaretskii wrote:
> > Date: Sun, 22 Aug 2010 12:06:42 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Would somebody please tell me exactly what "rebase" means.

> Typing "define:rebase" into Google brings this definition:

>     To clean a branch by starting from the head of the main line of
>     development ("master"), and reapply the (possibly cherry-picked)
>     changes from that branch.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: base

[Teemu Likonen]

* 2010-08-22 12:06 (UTC), Alan Mackenzie wrote:

> Would somebody please tell me exactly what "rebase" means.

Here's a pretty good illustrated explanation:

    http://book.git-scm.com/4_rebasing.html

Re: base

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Date: Sun, 22 Aug 2010 15:50:22 +0300
> Cc: emacs-devel@gnu.org
> 
> * 2010-08-22 12:06 (UTC), Alan Mackenzie wrote:
> 
> > Would somebody please tell me exactly what "rebase" means.
> 
> Here's a pretty good illustrated explanation:
> 
>     http://book.git-scm.com/4_rebasing.html

The bzr docs include a section on rebasing as well:

  http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/adv_merging.html

(look near the end).

Re: base

[Uday S Reddy]

Eli Zaretskii wrote:

> The bzr docs include a section on rebasing as well:
> 
>   http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/adv_merging.html
> 
> (look near the end).

Indeed, the last paragraph explains the attitude of Bazaar developers:

   Note: Some _users coming from central VCS tools_ with poor merge tracking
   like rebasing because it’s similar to how they are use to working in older
   tools, or because _“perfectly clean” history seems important_. Before
   rebasing in Bazaar, think about whether a normal merge is a better choice.
   [Emphasis added]

I don't have any trouble with the next sentence:

   In particular, rebasing a private branch before sharing it is OK but rebasing
   after sharing a branch with someone else is strongly discouraged.


Here is Linus Torlvalds explaining this point in more detail:

   http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

Cheers,
Uday

Re: base

[Leo]

On 2010-08-23 11:38 +0100, Uday S Reddy wrote:
> Indeed, the last paragraph explains the attitude of Bazaar developers:
>
>   Note: Some _users coming from central VCS tools_ with poor merge tracking
>   like rebasing because it’s similar to how they are use to working in older
>   tools, or because _“perfectly clean” history seems important_. Before
>   rebasing in Bazaar, think about whether a normal merge is a better choice.
>   [Emphasis added]
>

I start to think that there is a group of idiots on the Bazaar team.

It is socially nearly impossible to rewrite shared history. So the
warning is pretty much spurious.

Leo

Re: base

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Mon, 23 Aug 2010 12:03:35 +0100
> 
> I start to think that there is a group of idiots on the Bazaar team.

Don't.

Re: base

[Richard Stallman]

If you disagree with some of the recommendations written by the Bzr
developers, please don't discuss it here.  Your criticism might be
valid, but this is the wrong place for it.  In order for it to be
constructive criticism, you need to present it in a Bzr discussion
group or as a Bzr bug report, so that the Bzr developers will
see it.

Re: base

[Stephen J. Turnbull]

Leo writes:

 > It is socially nearly impossible to rewrite shared history.

True as you mean it.  However, it is technically possible (especially
in git) to change *pointers* to shared history in a way that can
really confuse the tool.  And in Bazaar and Mercurial it's even worse;
they don't provide reflogs or rerere, so you can really wedge things
if the rebase involves conflicts and the original branches have been
deleted.

 > So the warning is pretty much spurious.

I disagree, strongly.  It's one of those things where most people most
of the time will quickly learn to do things safely, but it will save a
few people a lot of trouble.

Re: base

[Leo]

On 2010-08-24 07:01 +0100, Stephen J. Turnbull wrote:
> True as you mean it. However, it is technically possible (especially
> in git) to change *pointers* to shared history in a way that can
> really confuse the tool. And in Bazaar and Mercurial it's even worse;
> they don't provide reflogs or rerere, so you can really wedge things
> if the rebase involves conflicts and the original branches have been
> deleted.

But the minute you publish your screwed-up history to the shared repo,
you can not escape being caught (in git it will happen as soon as
someone does a fetch) and as a result you lose the trust of your peer
developers. The history will then be reset to the correct one (push -f)
and possibly also an apology for the screwup.

Leo

Re: base

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> But the minute you publish your screwed-up history to the shared repo,
> you can not escape being caught (in git it will happen as soon as
> someone does a fetch) and as a result you lose the trust of your peer
> developers. The history will then be reset to the correct one (push -f)
> and possibly also an apology for the screwup.

There are situations where it is agreed upon by the developers that a
shared branch is rebased from time to time.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: base

[Stephen J. Turnbull]

Leo writes:

 > But the minute you publish your screwed-up history to the shared
 > repo, you can not escape being caught (in git it will happen as
 > soon as someone does a fetch) and as a result you lose the trust of
 > your peer developers. The history will then be reset to the correct
 > one (push -f) and possibly also an apology for the screwup.

Well, sure.  But that kind of punishment is a poor motivator in
general, and certainly not desirable in volunteer projects.

This kind of thing is one reason why git has a poor reputation.  I
believe it is undeserved, but it's real.  Just today there was a post
on bazaar@canonical to the effect of "Please please please don't tell
me I can't do X and will have to use git."

Re: base

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> This kind of thing is one reason why git has a poor reputation.  I
> believe it is undeserved, but it's real.

It is?  The only poor reputation I'm aware of git having is "OMG it's
too hard for newbies" (plus a little "OMG it won't work on windows.")

[There's a clear streak of anti-git paranoia/sour-grapes/something in
the bzr docs, but I've never seen that anywhere else.]

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 11:10, Miles Bader <miles@gnu.org> wrote:

> It is?  The only poor reputation I'm aware of git having is "OMG it's
> too hard for newbies" (plus a little "OMG it won't work on windows.")

Then you haven't heard of "OMG its documentation is ridiculously long
and unreadable".

Which, I readily admit, is not worse than Bzr's reputation of "OMG its
documentation is full of vagueness and lacking detailed explanations
and even clear definitions of basic concepts".

    Juanma

Re: base

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Which, I readily admit, is not worse than Bzr's reputation of "OMG
 > its documentation is full of vagueness and lacking detailed
 > explanations and even clear definitions of basic concepts".

Try Bazaar For Git Users,
http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html.
(It helps to be familiar with git; specialized git terms like "ref"
are used without definition.)

There are a couple of inaccuracies there.  The important one is that
bzr update is *not* an alias for bzr pull.  Rather, bzr pull
synchronizes the current branch to the remote branch if and only if
the local branch is a subset of the remote.  It normally updates the
workspace as well.  In a bound branch or checkout, the current branch
is the master branch it's bound to; because of the binding, of course
the local branch gets synchronized too.  bzr update synchronizes the
workspace to its (master) branch; in the case of a bound branch, this
has the side effect of synchronizing the local branch bound to the
master.

Other than that, IMHO :-) it's pretty good, as far as it goes.

Re: base

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> It is?  The only poor reputation I'm aware of git having is "OMG it's
>> too hard for newbies" (plus a little "OMG it won't work on windows.")
>
> Then you haven't heard of "OMG its documentation is ridiculously long
> and unreadable".

Hmm, nope.  Git's builtin documentation is actually pretty decent
(reasonably complete, includes examples, etc), but it's a reference, not
a tutorial -- it's designed to help somebody already familiar with the
basic operation of git remember the details.

There are _tons_ of tutorials for git around though, if that's what you
want.

-miles

-- 
x
y
Z!

Re: base

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>>> It is?  The only poor reputation I'm aware of git having is "OMG it's
>>> too hard for newbies" (plus a little "OMG it won't work on windows.")
>>
>> Then you haven't heard of "OMG its documentation is ridiculously long
>> and unreadable".
>
> Hmm, nope.  Git's builtin documentation is actually pretty decent
> (reasonably complete, includes examples, etc), but it's a reference, not
> a tutorial -- it's designed to help somebody already familiar with the
> basic operation of git remember the details.
>
> There are _tons_ of tutorials for git around though, if that's what you
> want.

Including one bundled with git (gittutorial(7)).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 16:05, Miles Bader <miles@gnu.org> wrote:

> Hmm, nope.  Git's builtin documentation is actually pretty decent

Well, I disagree.

> but it's a reference, not a tutorial

With that, I agree.

> There are _tons_ of tutorials for git around though, if that's what you
> want.

Yes. They are not git's documentation, though they are documentation for git.

    Juanma

Re: base

[Stephen J. Turnbull]

Miles Bader writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > > This kind of thing is one reason why git has a poor reputation.
 > > I believe it is undeserved, but it's real.

 > It is?

I should have added "in some circles, especially newbies."  But not
just them; a couple of Python programmers I respect a lot made
comments like "git command lines look like perl code" (which may not
bother you but it's a low blow on Python lists).  And that reputation
certainly did hurt git in the early discussion on emacs-devel.  I
thought git was a shoo-in for this crowd (except maybe Eli because of
the Windows issues), but the UI badmouthing kept the discussion going
long enough for other candidates to get serious consideration.

 > The only poor reputation I'm aware of git having is "OMG it's too
 > hard for newbies" (plus a little "OMG it won't work on windows.")

Yes, that's most of what I'm talking about.  Plus a little bit of
"OMG, it's dangerous and it lets you *change history*.  What if you
kill your Grandma before your Mom was born?"

Re: base

[Leo]

On 2010-08-24 13:32 +0100, Stephen J. Turnbull wrote:
> "git command lines look like perl code"

That's what they say to people who want to learn emacs.

Leo

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 14:32, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> (except maybe Eli because of the Windows issues)

The "Windows issues" are quite real. Basically, there's no support at
all. You practically cannot go to ask about a problem with the Windows
port unless you're ready to fix it yourself (which would be fine,
except that we're developing Emacs, not git); otherwise the
probability of getting a harsh rebuke is almost 100%.

And I frankly wouldn't be the least surprised if someday the people
involved in the port jus simply walked away (which they are entirely
in their right to do, of course, I hasten to add).

So Bzr, with all its problems, at least has some compromise of
supporting Windows users, while on git it seems like we're barely
tolerated :-)

> but the UI badmouthing kept the discussion going
> long enough for other candidates to get serious consideration.

My English isn't good enoug to know whether "badmouthing" implies
falsehood or bad intention. That the UI is bad is IMHO entirely true.

    Juanma

Re: base

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> The "Windows issues" are quite real. Basically, there's no support at
> all. You practically cannot go to ask about a problem with the Windows
> port unless you're ready to fix it yourself (which would be fine,
> except that we're developing Emacs, not git); otherwise the
> probability of getting a harsh rebuke is almost 100%.
>
> And I frankly wouldn't be the least surprised if someday the people
> involved in the port jus simply walked away (which they are entirely
> in their right to do, of course, I hasten to add).

From time to time I read the git ml and Windows users are well tolerated
there. I see no resistance to include patches for Windows compatibility
either. Actually, it is not rare at all to see commentaries about the
implications for Windows on discussions of technical issues.

Ironically, things are not so good on the msys-git ml. Too many jerks
around ("too many" = just two or so, but with a prominent ascendancy on
the msys-git project)

> So Bzr, with all its problems, at least has some compromise of
> supporting Windows users, while on git it seems like we're barely
> tolerated :-)

Since the line-ending mess that prevented me to use git on Windows was
fixed, I'm using it without a single issue. That's more that 6
months. OTOH, bzr keeps reporting exceptions and showing stack traces
from time to time, on Windows and GNU/Linux. Maybe I'm (un)lucky.

[snip]

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 16:25, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Ironically, things are not so good on the msys-git ml. Too many jerks
> around ("too many" = just two or so, but with a prominent ascendancy on
> the msys-git project)

That's why I spoke of "the people involved in the Windows port".

> Since the line-ending mess that prevented me to use git on Windows was
> fixed, I'm using it without a single issue.

I use it. Works fine. Hate the docs (yes, including the tutorial).
Hate most of the interface, too.

> OTOH, bzr keeps reporting exceptions and showing stack traces
> from time to time, on Windows and GNU/Linux. Maybe I'm (un)lucky.

I see stack traces (on Windows), but only rarely. Hate its speed. Hate
its docs. Seem to be having a hateful day today.

    Juanma

Re: base

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Aug 24, 2010 at 14:32, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
>> (except maybe Eli because of the Windows issues)
>
> The "Windows issues" are quite real. Basically, there's no support at
> all. You practically cannot go to ask about a problem with the Windows
> port unless you're ready to fix it yourself (which would be fine,
> except that we're developing Emacs, not git); otherwise the
> probability of getting a harsh rebuke is almost 100%.

The maintainer of the Windows port hates Windows AFAIR.  I believe that
he is doing quite a good job but does not radiate happiness all the
while.  That is somewhat different than the Windows port maintainers of
Emacs.

-- 
David Kastrup

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 16:37, David Kastrup <dak@gnu.org> wrote:

> The maintainer of the Windows port hates Windows AFAIR.  I believe that
> he is doing quite a good job but does not radiate happiness all the
> while.

I can understand that.

I cannot understand his unwillingness to accept that many people are
just *users*, not developers, and his propension to give them a bad
time when they report bugs and ask (politely, often) about status of
features, etc.  "Fix it yourself" is good advice (if the person can
follow), but it shouldn't be a battle cry.

> That is somewhat different than the Windows port maintainers of Emacs.

I think I've missed the irony. Care to elaborate?

    Juanma

Re: base

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Aug 24, 2010 at 16:37, David Kastrup <dak@gnu.org> wrote:
>
>> The maintainer of the Windows port hates Windows AFAIR.  I believe that
>> he is doing quite a good job but does not radiate happiness all the
>> while.
>
> I can understand that.
>
> I cannot understand his unwillingness to accept that many people are
> just *users*, not developers, and his propension to give them a bad
> time when they report bugs and ask (politely, often) about status of
> features, etc.  "Fix it yourself" is good advice (if the person can
> follow), but it shouldn't be a battle cry.
>
>> That is somewhat different than the Windows port maintainers of Emacs.
>
> I think I've missed the irony. Care to elaborate?

I did not intend any irony.  If you want to go looking for it, it may be
that git/Schindelin are doing a better job convincing people that
Windows is just not worth the trouble than Emacs/Stallman are.

A previous girlfriend of mine once was what one might call a party
smoker.  The last time I ever remember her smoking was at a party where
I picked up a cigarette for company or whatever.  That turned out not
pretty.

-- 
David Kastrup

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 18:38, David Kastrup <dak@gnu.org> wrote:

> I did not intend any irony.

Ah, sorry. Sometimes it's hard to be sure (not you, I mean in e-mail).

> If you want to go looking for it

Not specially, but

> it may be
> that git/Schindelin are doing a better job convincing people that
> Windows is just not worth the trouble than Emacs/Stallman are.

I'm not so sure. Schindelin is convincing people of something, that's
for sure. I just think it's not polite to say of what.

> That turned out not pretty.

Understatement? :-)

    Juanma

Re: base

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Tue, Aug 24, 2010 at 14:32, Stephen J. Turnbull
 > <stephen@xemacs.org> wrote:
 > 
 > > (except maybe Eli because of the Windows issues)

 > The "Windows issues" are quite real.

Granted.  However, they're real for *all* DVCSes.

 > So Bzr, with all its problems, at least has some compromise of
 > supporting Windows users, while on git it seems like we're barely
 > tolerated :-)

I can't speak to the git side; I've never *ever* had enough trouble
with git to need to get in touch with their MLs.  ISTM that while the
Bazaar devs pay lip service to Windows issues, they don't go much
beyond that (and some issues like SSH configuration on Windows just
don't ever seem to go away).

 > > but the UI badmouthing kept the discussion going
 > > long enough for other candidates to get serious consideration.

 > My English isn't good enoug to know whether "badmouthing" implies
 > falsehood or bad intention.

It implies both.

 > That the UI is bad is IMHO entirely true.

You are of course welcome to your opinion, and there's no need to be
humble about it.

I find your opinion hard to understand, however, because in basic,
everyday usage git is *simpler* than bzr.  You have essentially the
same number of commands, they do mostly the same things: init, clone
(missing in bzr), add, rm, mv (optional in git), commit, status, diff,
log, pull, push, branch, checkout (optional with different semantics
in bzr), reset (no single equivalent in bzr), merge: total 15
commands.  Except that that's not enough to use bzr efficiently; bzr
needs at least init-repo, and for many workflows update and switch
(and checkout becomes required).  That need is not obvious.

It's true that specification of revisions in git is unfamiliar.  But
both hg and bzr have been forced to add git notation by popular
demand.  And I think it would be very odd for someone who's familiar
with operators like "nthcdr" (which is "~" in git revision notation)
to complain about it.  It's rare to need any other notation (except in
quite specialized situations).

Re: base

[Frank Schmitt]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Juanma Barranquero writes:
>  > On Tue, Aug 24, 2010 at 14:32, Stephen J. Turnbull
>  > <stephen@xemacs.org> wrote:
>  > 
>  > > (except maybe Eli because of the Windows issues)
>
>  > The "Windows issues" are quite real.
>
> Granted.  However, they're real for *all* DVCSes.

I don't think this is fair. Mercurial, which seems to be one of the
two top DVCS at the moment, has great Windows support.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: base

[Stephen J. Turnbull]

Frank Schmitt writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Juanma Barranquero writes:
 > >  > On Tue, Aug 24, 2010 at 14:32, Stephen J. Turnbull
 > >  > <stephen@xemacs.org> wrote:
 > >  > 
 > >  > > (except maybe Eli because of the Windows issues)
 > >
 > >  > The "Windows issues" are quite real.
 > >
 > > Granted.  However, they're real for *all* DVCSes.

 > I don't think this is fair. Mercurial, which seems to be one of the
 > two top DVCS at the moment, has great Windows support.

Python's transition to Mercurial is blocked on Windows support, and
only that.  How do you claim that as "great" support?  The proponent
of the implementation PEP 385 was Dirkjan Ochtman, so you can't claim
that somebody lacking the needed skills (or access to people with
them, if he doesn't have them personally) was running the transition.

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 25 Aug 2010 13:33:46 +0900
> Cc: emacs-devel@gnu.org
> 
> Frank Schmitt writes:
> 
>  > I don't think this is fair. Mercurial, which seems to be one of the
>  > two top DVCS at the moment, has great Windows support.
> 
> Python's transition to Mercurial is blocked on Windows support, and
> only that.  How do you claim that as "great" support?

This seems to be about the EOL conversion issue?  If so, I can hardly
see how that could be used to rebuff the claim of "great Windows
support": EOL conversion by a VCS is one of the greater evils of all
times, in my book.  I was so happy to hear that bzr doesn't by
default.  You don't want even to begin learning how much trouble that
conversion caused me when we used CVS.

I don't use Mercurial except to clone an occasional repository, so I
really have no idea whether its support of Windows is "great".  But it
sounds extreme to me to say that EOL conversion (which AFAIU is
already solved in latest hg) is evidence that this support is not good
enough.

Anyway, the EOL conversion doesn't seem to be relevant to Emacs, which
happily supports Unix EOLs.  I have no idea why EOL conversion support
was so important to Python developers, but that's their funeral.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Wed, 25 Aug 2010 13:33:46 +0900
 > > Cc: emacs-devel@gnu.org
 > > 
 > > Frank Schmitt writes:
 > > 
 > >  > I don't think this is fair. Mercurial, which seems to be one
 > >  > of the two top DVCS at the moment, has great Windows support.

 > > Python's transition to Mercurial is blocked on Windows support,
 > > and only that.  How do you claim that as "great" support?

 > This seems to be about the EOL conversion issue?

About half.  The conversion issue is how to ensure that CRLF doesn't
get checked in by people who use autoconverting Windows software, not
Emacs, to edit code.  (Or maybe the problem only appears with new
files.)  It's *not* about trying to do something sane with automatic
conversion.

The other half isn't documented in the PEP.  It's SSH.  You could say
that this isn't the VCS's job to support, but then, whose job is it?
Python is just going to pass it on to the Windows developers.  I'm not
sure whether it will turn out to be a real problem or not in the end.

 > Anyway, the EOL conversion doesn't seem to be relevant to Emacs,

Neither is Mercurial. ;-)

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ich@frank-schmitt.net,
>     emacs-devel@gnu.org
> Date: Wed, 25 Aug 2010 17:48:02 +0900
> 
> The other half isn't documented in the PEP.  It's SSH.

What is the problem?  Doesn't Mercurial work with PuTTY's plink and
pageant, like Bazaar does?

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: ich@frank-schmitt.net,
 > >     emacs-devel@gnu.org
 > > Date: Wed, 25 Aug 2010 17:48:02 +0900
 > > 
 > > The other half isn't documented in the PEP.  It's SSH.
 > 
 > What is the problem?  Doesn't Mercurial work with PuTTY's plink and
 > pageant, like Bazaar does?

Sometimes, and sometimes not.  Like Bazaar.  It appears that many
Windows users have great difficulty getting SSH connections to work
right.  As I say, I don't know that this is the VCS's job.

Personally the only time I used SSH on Windows was for CVS and rsync,
I installed Cygwin's OpenSSH, imported my key files and config file
from a nearby Debian box, both CVS and rsync worked the first time,
and then I forgot about SSH on Windows.  So it's not obvious to me
that it's a real problem, but some people worry about it (and there's
a thread on it on bazaar@canonical every couple of months).

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ich@frank-schmitt.net,
>     emacs-devel@gnu.org
> Date: Wed, 25 Aug 2010 22:17:30 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
>  > > Cc: ich@frank-schmitt.net,
>  > >     emacs-devel@gnu.org
>  > > Date: Wed, 25 Aug 2010 17:48:02 +0900
>  > > 
>  > > The other half isn't documented in the PEP.  It's SSH.
>  > 
>  > What is the problem?  Doesn't Mercurial work with PuTTY's plink and
>  > pageant, like Bazaar does?
> 
> Sometimes, and sometimes not.  Like Bazaar.  It appears that many
> Windows users have great difficulty getting SSH connections to work
> right.

I use SSH from Windows for many years, both to log into GNU machines
and with CVS, and now with Bazaar.  I never had any problems
whatsoever with PuTTY.  So I cannot understand how this could be a
problem, and a blocking one at that.

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Sometimes, and sometimes not.  Like Bazaar.  It appears that many
>> Windows users have great difficulty getting SSH connections to work
>> right.
>
> I use SSH from Windows for many years, both to log into GNU machines
> and with CVS, and now with Bazaar.  I never had any problems
> whatsoever with PuTTY.  So I cannot understand how this could be a
> problem, and a blocking one at that.

bzr does not use PuTTY (plink, to be more precise) by default.

I had problems with bzr & ssh too and had to learn about the existence
of the environment variable BZR_SSH to fix them.

Re: base

[Bernardo Barros]

Is rebase *that* important? Mercurial has rebase and it's also made
with python, does not have issues with windows as fas as I know

2010/8/25 Óscar Fuentes <ofv@wanadoo.es>:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Sometimes, and sometimes not.  Like Bazaar.  It appears that many
>>> Windows users have great difficulty getting SSH connections to work
>>> right.
>>
>> I use SSH from Windows for many years, both to log into GNU machines
>> and with CVS, and now with Bazaar.  I never had any problems
>> whatsoever with PuTTY.  So I cannot understand how this could be a
>> problem, and a blocking one at that.
>
> bzr does not use PuTTY (plink, to be more precise) by default.
>
> I had problems with bzr & ssh too and had to learn about the existence
> of the environment variable BZR_SSH to fix them.
>
>
>

Re: base

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 25 Aug 2010 22:34:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I use SSH from Windows for many years, both to log into GNU machines
> > and with CVS, and now with Bazaar.  I never had any problems
> > whatsoever with PuTTY.  So I cannot understand how this could be a
> > problem, and a blocking one at that.
> 
> bzr does not use PuTTY (plink, to be more precise) by default.

That's right, and neither do I, with Bazaar.  But pageant, the PuTTY
agent, _is_ used by Bazaar.

> I had problems with bzr & ssh too and had to learn about the existence
> of the environment variable BZR_SSH to fix them.

I know about BZR_SSH, but never had to use it.  The default setup
works just fine for me.

Re: base

[Leo]

On 2010-08-24 18:35 +0100, Stephen J. Turnbull wrote:
> It's true that specification of revisions in git is unfamiliar. But
> both hg and bzr have been forced to add git notation by popular
> demand. And I think it would be very odd for someone who's familiar
> with operators like "nthcdr" (which is "~" in git revision notation)
> to complain about it. It's rare to need any other notation (except in
> quite specialized situations).

Most of time the revision notations can be ignored. I didn't know any
revision notations for a long time but still productive thanks to magit.
A ~200 lines of document is there ('git help revisions' to see it) so I
feel confident because I can just look it up whenever I need it.

Leo

Re: base

[Juanma Barranquero]

On Tue, Aug 24, 2010 at 19:35, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Granted.  However, they're real for *all* DVCSes.

No, I don't think so. Perhaps Windows support on Bzr is not good, but
at least you don't need to be afraid of being insulted when you have
to report a bug.

> ISTM that while the
> Bazaar devs pay lip service to Windows issues, they don't go much
> beyond that (and some issues like SSH configuration on Windows just
> don't ever seem to go away).

I agree Bzr's Windows support could be better, but at least there are
regular updates and some attempt at fixing bugs.

> It implies both.

Thanks.

> I find your opinion hard to understand, however, because in basic,
> everyday usage git is *simpler* than bzr.  You have essentially the
> same number of commands, they do mostly the same things: init, clone
> (missing in bzr), add, rm, mv (optional in git), commit, status, diff,
> log, pull, push, branch, checkout (optional with different semantics
> in bzr), reset (no single equivalent in bzr), merge: total 15
> commands.

config, tag, remote, stash, reflog...

But the complain is not about the number of commands. It's about the
miriad options. "git help log" is a good example. Every time I have to
use one of the non-obvious command options and I have to check the
documentation I have a sudden urge of shooting someone.

> It's true that specification of revisions in git is unfamiliar.  But
> both hg and bzr have been forced to add git notation by popular
> demand.  And I think it would be very odd for someone who's familiar
> with operators like "nthcdr" (which is "~" in git revision notation)
> to complain about it.

Terseness is sometimes an advantage, sometimes no. A..B versus A...B. nuff said.

    Juanma

Re: base

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
> Terseness is sometimes an advantage, sometimes no. A..B versus
> A...B. nuff said.

haha, "bzr"..."terse"

This is all very silly, because however bad git's UI may be, bzr's
seems far worse -- this is perhaps most evident in the constant and
continuing confusion over even basic usage of bzr on this list
... after how many months of Emacs using bzr...?

-miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: base

[Juanma Barranquero]

On Wed, Aug 25, 2010 at 01:44, Miles Bader <miles@gnu.org> wrote:

> This is all very silly, because however bad git's UI may be, bzr's
> seems far worse

I don't think it is worse (not by a long shot), though I do agree it
is not good. But that's hardly an argument in favor of git's UI.

> -- this is perhaps most evident in the constant and
> continuing confusion over even basic usage of bzr on this list
> ... after how many months of Emacs using bzr...?

IMO that's more related to imprecise documentation that bad UI.

    Juanma

Re: base

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> -- this is perhaps most evident in the constant and
>> continuing confusion over even basic usage of bzr on this list
>> ... after how many months of Emacs using bzr...?
>
> IMO that's more related to imprecise documentation that bad UI.

I think it's related to bzr being inconsistent, complicated, and
confusing, with no simple mental model for users to latch onto, and
multiple operating modes poorly stitched together (it's not really clear
what bzr wants to be; sometimes it seems like its trying to be
everything at once -- and, predictably, failing at all as a result).

-miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: base

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Wed, 25 Aug 2010 09:19:37 +0900
> 
> I think it's related to bzr being inconsistent, complicated, and
> confusing, with no simple mental model for users to latch onto, and
> multiple operating modes poorly stitched together (it's not really clear
> what bzr wants to be; sometimes it seems like its trying to be
> everything at once -- and, predictably, failing at all as a result).

I think you simply don't like bzr, so you are inventing imaginary
problems that are present in it, but absent in other dVCSs.

Re: base

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I think you simply don't like bzr, so you are inventing imaginary
> problems that are present in it, but absent in other dVCSs.

I don't like bzr -- but it's not for no reason.  These problems are
certainly not "imaginary."

-miles

-- 
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Re: base

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: emacs-devel@gnu.org
> Reply-To: Miles Bader <miles@gnu.org>
> System-Type: x86_64-unknown-linux-gnu
> Blat: Foop
> Date: Wed, 25 Aug 2010 12:44:23 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > I think you simply don't like bzr, so you are inventing imaginary
> > problems that are present in it, but absent in other dVCSs.
> 
> I don't like bzr -- but it's not for no reason.  These problems are
> certainly not "imaginary."

In that case, we will have to disagree.  I don't find bzr fitting the
description of "being inconsistent, complicated, and confusing, with
no simple mental model for users to latch onto", any more than other
dVCSs out there.  I can understand how it could be confusing if you
come from another dVCS with similar commands that have subtly
different semantics, but that problem exists no matter what tools you
are switching from and to.  Other than that, the most popular commands
are neither inconsistent, nor complicated or confusing.  You will need
to work hard to convince me otherwise, because I became a happy user
(well, except for the speed...) just a couple of months after
installing bzr.

For that matter, I don't find the bzr docs worse than that of git or
others.  They are both essentially a collection of man pages with
little or no glue to bind them into a coherent manual that could be
read and understood by a relative novice.  You may say that git man
pages are well written, and I might agree, but since when well-written
man pages are accepted as good documentation?  That could pass in
1980s, but its IMO ridiculous to claim that this is "documentation" in
the year 2010.  (Yes, I know about user-manual.html, but it's
(a) generally unavailable as part of the installation, and (b) is
again a cookbook style hodgepodge of recipes without any explanations
to glue them together.  It doesn't even define its terms -- and no,
the Glossary doesn't count.)

Of course, the bzr docs are no better -- which is precisely my point:
there's nothing better or worse in usability in either dVCS.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Miles Bader <miles@gnu.org> Date: Wed, 25 Aug 2010 09:19:37
 > > +0900
 > > 
 > > I think it's related to bzr being inconsistent, complicated, and
 > > confusing,

Yep.  bzr violates about half the maxims in The Zen of Python (aka
"python -m this").  That's not a crime, exactly, but it's indicative.

 > > with no simple mental model for users to latch onto,
 > > and multiple operating modes poorly stitched together (it's not
 > > really clear what bzr wants to be; sometimes it seems like its
 > > trying to be everything at once -- and, predictably, failing at
 > > all as a result).
 > 
 > I think you simply don't like bzr, so you are inventing imaginary
 > problems that are present in it, but absent in other dVCSs.

No.  Miles exaggerates; some of the things bzr tries to do it does
quite well.  But the lack of a teachable mental model is a real
problem, regularly visible on the bazaar list.  People who like bzr a
lot rarely have any idea how it works; they just happen to have
workflows that fit well with a short list of bzr commands.  That's
nice, of course, but it is *not* easy to figure out, or explain, how
to do the occasional things that don't fit one of those workflows.

And it shows up in the bugs and problems that are posted to the bazaar
list.  Eg, I have never seen a wedged git or hg repository or branch;
it is *always* possible to get back to where you started from (unless
the content storage itself is corrupted).  The worst that can ever
happen (unless you explicitly type "git commit" to make the mess
permanent) is that you've wasted hours trying to resolve an insane
merge conflict.  But people post regularly (recently, I'd say about
once a month) asking how to get some previous version (in some cases,
any version at all) checked out of their bzr branch.  And in some
cases the answers are very non-trivial (writing a plugin for bzr that
replaces buggy functionality, for example).

These are bugs, of course, but they're unimaginable in git or hg,
because the history data is wedged, not the content storage.  With the
history data used by git, at least, wedging the history would be as
criminal as wedging a list in Emacs LISP would be.  But wedged history
*is* occasionally reported for bazaar.

Re: base

[Uday S Reddy]

On 8/25/2010 9:15 AM, Stephen J. Turnbull wrote:

> And it shows up in the bugs and problems that are posted to the bazaar
> list.  Eg, I have never seen a wedged git or hg repository or branch;
> it is *always* possible to get back to where you started from (unless
> the content storage itself is corrupted).  The worst that can ever
> happen (unless you explicitly type "git commit" to make the mess
> permanent) is that you've wasted hours trying to resolve an insane
> merge conflict.  But people post regularly (recently, I'd say about
> once a month) asking how to get some previous version (in some cases,
> any version at all) checked out of their bzr branch.  And in some
> cases the answers are very non-trivial (writing a plugin for bzr that
> replaces buggy functionality, for example).
>
> These are bugs, of course, but they're unimaginable in git or hg,
> because the history data is wedged, not the content storage.  With the
> history data used by git, at least, wedging the history would be as
> criminal as wedging a list in Emacs LISP would be.  But wedged history
> *is* occasionally reported for bazaar.

Gosh, I don't know what you mean by "wedged".  Stuck?  Corrupted?

Doing a Google search took me to this page

   http://ww2.samhart.com/node/47

where git is being blamed as being the worst culprit in this regard.

Uday

Re: base

[Juanma Barranquero]

On Wed, Aug 25, 2010 at 11:35, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> Doing a Google search took me to this page
>
>  http://ww2.samhart.com/node/47
>
> where git is being blamed as being the worst culprit in this regard.

Three years is like, you know, forever.

    Juanma

Re: base

[Stephen J. Turnbull]

Uday S Reddy writes:

 > > But wedged history *is* occasionally reported for bazaar.
 > 
 > Gosh, I don't know what you mean by "wedged".  Stuck?  Corrupted?

Stuck, like in the Southeast Asian monkey trap.  Data is in there,
probably not corrupt, but the program can't handle it and just throws
errors back at you for all high-level commands (commit, merge, maybe
even log).  Like the problems alluded to here:

 >    http://ww2.samhart.com/node/47
 > 
 > where git is being blamed as being the worst culprit in this
 > regard.

Sure, but if you do the arithmetic, the wedging incidents happened in
the summer of 2005.  git was a product whose first versions were coded
in early April of that year, whose first real test was in June, and
which didn't get released as "1.0" until December.

When Linus handed it over to Junio in July 2005, he considered it
ready for "technical users", ie, people ready to dive in and patch the
thing if it didn't work.  Sam Hart explicitly washes his hands of
responsibility to know about git, that was some other developer's job.
Not what Linus had in mind as the users git was ready for, eh?

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Miles Bader <miles@gnu.org>,
>     emacs-devel@gnu.org
> Date: Wed, 25 Aug 2010 17:15:35 +0900
> 
> Miles exaggerates

That is all that I wanted to convey.

> But the lack of a teachable mental model is a real problem,
> regularly visible on the bazaar list.

I'm not sure I understand what is a ``teachable mental model'', and
where do you see such a model explained in, e.g., git's or hg's docs.
If you can point me to such an explanation, then I could compare that
to bzr's docs and see if there are any significant differences.

Of course, I don't want to claim that the bzr docs are good; you
yourself watched me many times on the Bazaar list complaining about
its quality and filing bug reports.  So that's not the point;
exaggeration is.

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> But the lack of a teachable mental model is a real problem,
>> regularly visible on the bazaar list.
>
> I'm not sure I understand what is a ``teachable mental model'', and
> where do you see such a model explained in, e.g., git's or hg's docs.
> If you can point me to such an explanation, then I could compare that
> to bzr's docs and see if there are any significant differences.

The teachable mental model was something you insistently asked for on
the first weeks of the transition to bzr. It is like the Principles of
Physics that, once mastered, are extremely useful while working with
everything else on the field. Git has simple foundations and those are
explained on several places on the net. See for example

http://www.newartisans.com/blog_files/git.from.bottom.up.php

There is no such thing for bzr. There was some failed attempt of writing
an equivalent document, which tells lots about the "simplicity" of bzr.

Git is a simple model wrapped on a complex UI. Bzr is a complex model
wrapped on a deceptively simple UI. Changing the UI is easy (and there
are lots for git.) Changing the underlying model is almost impossible.

[snip]

Re: base

[Harald Hanche-Olsen]

+ Óscar Fuentes <ofv@wanadoo.es>:

> Git has simple foundations and those are explained on several places
> on the net. See for example [...]

I found this very useful:

  http://eagain.net/articles/git-for-computer-scientists/

And I am not even a computer scientist.

- Harald

Re: base

[Eli Zaretskii]

> Date: Wed, 25 Aug 2010 17:11:13 +0200 (CEST)
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> 
> + Óscar Fuentes <ofv@wanadoo.es>:
> 
> > Git has simple foundations and those are explained on several places
> > on the net. See for example [...]
> 
> I found this very useful:
> 
>   http://eagain.net/articles/git-for-computer-scientists/
> 
> And I am not even a computer scientist.

Why should anyone need to pretend being one to use a tool?

Re: base

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 25 Aug 2010 15:13:41 +0200
> 
> The teachable mental model was something you insistently asked for on
> the first weeks of the transition to bzr.

I may be misremembering, but I think I was asking something entirely
different.

> It is like the Principles of Physics that, once mastered, are
> extremely useful while working with everything else on the field.

Careful! I majored in Physics.

> Git has simple foundations and those are explained on several places
> on the net. See for example
> 
> http://www.newartisans.com/blog_files/git.from.bottom.up.php

Once again, this is internals, not something users should need to
grasp to use the tool effectively.  We use dozens of programs every
day without any comparable knowledge of how they work and what are the
data structures they manipulate.  Take any example you like: Make,
GCC, GDB, you name it.  Unless you happened to hack them at some
point, the "mental model" each of us has about these tools generally
has nothing to do with the data structures and algorithms you will
find if you study the code.

IOW, a "mental model" is rules of the game, they have nothing to do
with the under the hood machinery that actually makes the game tick.

> There is no such thing for bzr. There was some failed attempt of writing
> an equivalent document, which tells lots about the "simplicity" of bzr.

I rather think it speaks volumes about the (in)ability of Bazaar
developers to write good documentation.  The user guide reads like it
was written by someone whose first language is not English and who
cannot explain herself in _any_ language.

> Git is a simple model wrapped on a complex UI. Bzr is a complex model
> wrapped on a deceptively simple UI. Changing the UI is easy (and there
> are lots for git.) Changing the underlying model is almost impossible.

I have no idea what is the underlying model in Bazaar, and I don't
really care how complex it is, as long as its UI is simple enough for
me to build my own mental model.  And as long as the UI is simple
enough, I see no reason to change the underlying model.

I can also tell you that after spending a year studying the display
engine of Emacs, I think nothing can ever seem complex to me ;-).
What I did learn during this year is that complex models are not
necessarily bad or ugly or not extensible: look what I was able to do
with the display engine without changing anything in its basic
architecture and design.

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The teachable mental model was something you insistently asked for on
>> the first weeks of the transition to bzr.
>
> I may be misremembering, but I think I was asking something entirely
> different.

I will not be so foolish to argue with you about what you had in mind at
the time, but it looked like "I want to obtain the necessary knowledge
to *decide* what is the most effective way of working with bzr for me."
A good answer for that sort of request is pointing to a document
explaining the foundations of the tool, from which everything else
derives. If the foundations are simple and shallow enough, making easy
to draw conclusions applicable to real practice, it is a plus for the
tool.

[snip]

>> Git has simple foundations and those are explained on several places
>> on the net. See for example
>> 
>> http://www.newartisans.com/blog_files/git.from.bottom.up.php
>
> Once again, this is internals, not something users should need to
> grasp to use the tool effectively.

You can use git effectively (for some reasonable definition of
effectiveness) without knowing those details. Knowing them helps a lot,
though. And they are not internal details, for the same reason that the
point, the mark, etc are not internal details for the Emacs user,
although you can use Emacs without knowing them.

[snip]

> IOW, a "mental model" is rules of the game, they have nothing to do
> with the under the hood machinery that actually makes the game tick.

That document explains, precisely, the rules of the game, i.e. the model
that every git implementation must follow. If the actual implementation
resembles so much the model, is because it is so simple that the
implementation is almost immediate once you know the model.

[snip]

>> Git is a simple model wrapped on a complex UI. Bzr is a complex model
>> wrapped on a deceptively simple UI. Changing the UI is easy (and there
>> are lots for git.) Changing the underlying model is almost impossible.
>
> I have no idea what is the underlying model in Bazaar, and I don't
> really care how complex it is, as long as its UI is simple enough for
> me to build my own mental model.  And as long as the UI is simple
> enough, I see no reason to change the underlying model.

And if a merge causes unexpected results, what would you do? Blame the
UI?

It seems that by "underlying model" you are referring to the
implementation. For me, the underlying model and the mental model are
the same.

> I can also tell you that after spending a year studying the display
> engine of Emacs, I think nothing can ever seem complex to me ;-).
> What I did learn during this year is that complex models are not
> necessarily bad or ugly or not extensible: look what I was able to do
> with the display engine without changing anything in its basic
> architecture and design.

I guess that most part of that year was consumed by the study of the
*implementation* of the display engine, not its model (unless you
learned the model by reading the implementation.)

Re: base

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 25 Aug 2010 23:06:59 +0200
> 
> I will not be so foolish to argue with you about what you had in mind at
> the time, but it looked like "I want to obtain the necessary knowledge
> to *decide* what is the most effective way of working with bzr for me."
> A good answer for that sort of request is pointing to a document
> explaining the foundations of the tool, from which everything else
> derives.

That wasn't the answer I was expecting.  I expected to see several
possible workflows with some analysis of their merits and demerits.
There's no need to know how a repository stores its info for that.

> >> http://www.newartisans.com/blog_files/git.from.bottom.up.php
> >
> > Once again, this is internals, not something users should need to
> > grasp to use the tool effectively.
> 
> You can use git effectively (for some reasonable definition of
> effectiveness) without knowing those details. Knowing them helps a lot,
> though. And they are not internal details, for the same reason that the
> point, the mark, etc are not internal details for the Emacs user,
> although you can use Emacs without knowing them.

Mark and point _are_ internal details.  Most users don't have a clue
about their implementation, not even about the fact that their API is
a function (as opposed to a variable, for instance).  What users are
told is some "model" of mark and point, and the model actually has
more to do with _what_ these do than how they do it.

> > IOW, a "mental model" is rules of the game, they have nothing to do
> > with the under the hood machinery that actually makes the game tick.
> 
> That document explains, precisely, the rules of the game, i.e. the model
> that every git implementation must follow.

I meant the rules of the game for the user, not for the
implementation.  Users should not be bothered by implementation
details.

> > I have no idea what is the underlying model in Bazaar, and I don't
> > really care how complex it is, as long as its UI is simple enough for
> > me to build my own mental model.  And as long as the UI is simple
> > enough, I see no reason to change the underlying model.
> 
> And if a merge causes unexpected results, what would you do? Blame the
> UI?

I'd say there's a bug that needs to be fixed.

> > I can also tell you that after spending a year studying the display
> > engine of Emacs, I think nothing can ever seem complex to me ;-).
> > What I did learn during this year is that complex models are not
> > necessarily bad or ugly or not extensible: look what I was able to do
> > with the display engine without changing anything in its basic
> > architecture and design.
> 
> I guess that most part of that year was consumed by the study of the
> *implementation* of the display engine, not its model (unless you
> learned the model by reading the implementation.)

Of course! because I needed to _extend_ the display engine.  But as a
bzr user, I do not need to extend it, so I shouldn't need to bother
about such details.

Re: base

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> That wasn't the answer I was expecting.  I expected to see several
> possible workflows with some analysis of their merits and demerits.
> There's no need to know how a repository stores its info for that.

The "list some workflows" method quickly breaks down except for
extremely simple tools (which few tools are), because it would entail
enumerating a huge number of possible scenarios; not only is this hard
for the developer, but it's very hard for the user to remember and use
beyond a certain point.

A model does _not_ need to be the same as the actual implementation --
rather it's a highly efficient and usable way for the user to understand
the tool.

Since you said you had a degree in physics, think of it in those terms:
people do lots of experiments, but people don't teach physics as a rote
series of "if you do X, then Y happens" -- that would be madness.
Instead, they use experiments to develop a model of how things work,
which can be much more easily taught, and is much more useful once
learned.  Our model of physics (and of course there are multiple
co-existent models representing different levels of details) necessarily
"real" of course, but represents our best effort in encoding what we
observe in a way that allows us to make predictions about unobserved
behavior.

For software of course, often the user-model can be based on the
implementation (though almost always simplifying it), especially if the
implementation is relatively simple and consistent.

It sometimes takes a little extra effort for the user to learn a model
instead of a rote list of actions, but it pays back hugely in giving the
user power over his tool.

-Miles

-- 
Patience, n. A minor form of despair, disguised as a virtue.

Re: base

[Miles Bader]

whoops:

Miles Bader <miles@gnu.org> writes:
...
> Our model of physics (and of course there are multiple
> co-existent models representing different levels of details) necessarily
> "real" of course
...

should be:  _aren't_ necessarily "real" of course

-miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: base

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Thu, 26 Aug 2010 12:27:04 +0900
> System-Type: x86_64-unknown-linux-gnu
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > That wasn't the answer I was expecting.  I expected to see several
> > possible workflows with some analysis of their merits and demerits.
> > There's no need to know how a repository stores its info for that.
> 
> The "list some workflows" method quickly breaks down except for
> extremely simple tools (which few tools are), because it would entail
> enumerating a huge number of possible scenarios

You are pushing a simple request ad absurdum.  I wasn't asking for an
exhaustive list of _all_possible_ workflows, only for a few
representative ones.  And please don't tell me that's impossible, or
even hard, because today I can easily do that for Bazaar.

> A model does _not_ need to be the same as the actual implementation --
> rather it's a highly efficient and usable way for the user to understand
> the tool.

Exactly right!  So a document that describes to me how bzr stores its
metadata in a repository is not the only or necessarily the best way
of letting me form a model of bzr that is useful enough to guide me in
day-to-day operations.  For complex and unconventional workflows, it
_might_ be necessary to use the history DAG to explain them, but for
the common workflows even that should not be necessary.  And _none_ of
the workflows really need any description of how the data is stored
and what algorithms are used to process that data.

> Since you said you had a degree in physics, think of it in those terms:

Physics is an inappropriate analogy here, because physics is not a
device to be used.  Physics is essentially a body of knowledge and a
set of rules to extend that knowledge.  Therefore, a physicist is much
more like a software developer than a software user, and there's
little surprise that physicist's activities do require the kind of
under the hood information akin to what the cited Web pages provide
for git and hg.

> people do lots of experiments, but people don't teach physics as a rote
> series of "if you do X, then Y happens" -- that would be madness.
> Instead, they use experiments to develop a model of how things work,
> which can be much more easily taught, and is much more useful once
> learned.

The models developed by physicists are supposed to be how the nature
actually works.  They are not "mental models" by a user who can be
ignorant of the internals, they pretend to be the laws of the nature
itself, which _are_ the "internals".  IOW, in physics, the model and
the actual implementation details are indistinguishable, at least in
practice.  Therefore, this analogy is not useful in the context of
this discussion.

A more useful analogy would be the use of a TV set.  Most people have
no idea how it works, and yet they can use it very efficiently--until
something breaks.  Because I know quite a bit about how it works, I
can sometimes fix simple problems or at least analyze them, whereas my
wife would just call the tech support.

So if we were discussing ways to debug bzr problems or work around
bugs, then yes, some inside knowledge would be extremely helpful.  But
as long as I don't want to debug bzr and will settle for asking "the
technicians" for work-arounds on the bzr list rather than look for
them myself, I have no need for such knowledge.

> For software of course, often the user-model can be based on the
> implementation (though almost always simplifying it)

Only if you want to study or hack the tool.  Most of us never do that
with the majority of the tools we use.

> It sometimes takes a little extra effort for the user to learn a model
> instead of a rote list of actions, but it pays back hugely in giving the
> user power over his tool.

Agreed; however, existence of such an information should not be
declared as a fatal blow to the ability of users to learn to use a
tool safely and efficiently.  It is a bonus, but not a necessity.

Re: base

[Leo]

On 2010-08-26 06:37 +0100, Eli Zaretskii wrote:
> You are pushing a simple request ad absurdum. I wasn't asking for an
> exhaustive list of _all_possible_ workflows, only for a few
> representative ones. And please don't tell me that's impossible, or
> even hard, because today I can easily do that for Bazaar.

This might be of interest:

  http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt

Note that is a project with much much more development activities than
emacs.

Leo

Re: base

[Uday S Reddy]

On 8/26/2010 6:37 AM, Eli Zaretskii wrote:

> Exactly right!  So a document that describes to me how bzr stores its
> metadata in a repository is not the only or necessarily the best way
> of letting me form a model of bzr that is useful enough to guide me in
> day-to-day operations.  For complex and unconventional workflows, it
> _might_ be necessary to use the history DAG to explain them, but for
> the common workflows even that should not be necessary.  And _none_ of
> the workflows really need any description of how the data is stored
> and what algorithms are used to process that data.

Eli, I agree with the general thrust of your argument.  The conceptual model 
you present to the users can be quite divorced from the implementation.  But 
different conceptual models can have different levels of conceptual efficiency. 
  One model might lead you to draw the right conclusions and another might 
mislead you.  This kind of thing is called "representation bias" in Computer 
Science.

I believe that the DAG view is the right conceptual model for version 
management, not the linearized history with time travel as presented by 'bzr 
log'.  When you look at a history like

    429
       326.1.2
       326.1.1
    428

you are not supposed to think "what has changed from 428 to 326.1.1?"  You are 
really supposed to think "what has changed from 326 to 326.1.1?"  The fact that 
326.1.1 is a successor to 326, and *not* a successor to 428, is quite 
important.  The fact that there isn't a single Bazaar document that mentions 
DAG is astonishing.  And, I didn't think of it either until Stephen put a DAG 
in front of me and said "look".  Problem solved.

>> Since you said you had a degree in physics, think of it in those terms:
>
> Physics is an inappropriate analogy here, because physics is not a
> device to be used.  Physics is essentially a body of knowledge and a
> set of rules to extend that knowledge.  Therefore, a physicist is much
> more like a software developer than a software user, and there's
> little surprise that physicist's activities do require the kind of
> under the hood information akin to what the cited Web pages provide
> for git and hg.

This is open to question.  I might argue that a physicist is a user of nature, 
not a developer of nature.  And, the physicist's models ("theories" in their 
terminology) are just conceptually-efficient models of nature.  They are not 
necessarily how things work.  In Quantum Mechanics, for instance, we have no 
real idea how things work, and there are two conceptual models one might use. 
Since it is incoherent to talk about two conceptual models, standard Quantum 
Mechanics text books present neither, which drives the Physics students nuts 
just like the Bazaar documentation drives us nuts.  Physics teachers help out 
by telling students their favorite model, which might appeal to some students 
and not to others.  My teachers always seemed to prefer the particle model.  I 
prefer the wave model myself.  I think it is conceptually efficient.

>> It sometimes takes a little extra effort for the user to learn a model
>> instead of a rote list of actions, but it pays back hugely in giving the
>> user power over his tool.
>
> Agreed; however, existence of such an information should not be
> declared as a fatal blow to the ability of users to learn to use a
> tool safely and efficiently.  It is a bonus, but not a necessity.

Without a good conceptual model, it is doubtful if they can use it "safely and 
efficiently."

Cheers,
Uday

Re: base

[Eli Zaretskii]

> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Date: Thu, 26 Aug 2010 09:23:28 +0100
> 
> different conceptual models can have different levels of conceptual efficiency. 
>   One model might lead you to draw the right conclusions and another might 
> mislead you.  This kind of thing is called "representation bias" in Computer 
> Science.

A "good" model will leave only an insignificant bias.  I am talking
only about good models.  I submit that a good model does not need to
be based on implementation details.  I can understand why programmers
tend to base such models on the actual implementation, but I don't
agree that a good model must be based on that.  Moreover, I actually
think that the best models should _not_ be based on implementation
details.

> I believe that the DAG view is the right conceptual model for version 
> management, not the linearized history with time travel as presented by 'bzr 
> log'.  When you look at a history like
> 
>     429
>        326.1.2
>        326.1.1
>     428

No one said that the DAG representation by "bzr log" should be the
basis for the model that we all agree users need to form.  (I could
argue in good faith that this output can be interpreted in a way that
is conducive to correct understanding of the history, but that would
take us too far from the subject.)

> The fact that there isn't a single Bazaar document that mentions DAG
> is astonishing.

(For the record, I wrote such a document a few months ago and
submitted it to the bzr developers.  I have no idea when it will
become part of the official docs.)

As I said elsewhere in this thread, the quality of documentation in
the bzr project leaves a lot to be desired.  But we should distinguish
between inadequacy of the existing documentation and the basis upon
which to create a coherent mental model that should be presented to
users.  This subthread started with an assertion that such a model
does not exist for bzr, but does exist for other dVCSs.  This is the
issue here, not whether bzr documenters did a good job.

> > Physics is an inappropriate analogy here, because physics is not a
> > device to be used.  Physics is essentially a body of knowledge and a
> > set of rules to extend that knowledge.  Therefore, a physicist is much
> > more like a software developer than a software user, and there's
> > little surprise that physicist's activities do require the kind of
> > under the hood information akin to what the cited Web pages provide
> > for git and hg.
> 
> This is open to question.  I might argue that a physicist is a user of nature, 
> not a developer of nature.  And, the physicist's models ("theories" in their 
> terminology) are just conceptually-efficient models of nature.  They are not 
> necessarily how things work.

This borders on theology, and I won't enter that argument.  But
however you see this, what's important is that these theories are
_the_only_models_ used in physics, there's no "mental model" on the
one hand and the actual "implementation" OTOH.  Only meta-physicists
argue about the latter, but it's out of scope of physics as a
scientific discipline.

> In Quantum Mechanics, for instance, we have no 
> real idea how things work, and there are two conceptual models one might use. 
> Since it is incoherent to talk about two conceptual models, standard Quantum 
> Mechanics text books present neither, which drives the Physics students nuts 
> just like the Bazaar documentation drives us nuts.  Physics teachers help out 
> by telling students their favorite model, which might appeal to some students 
> and not to others.

Well, your ideas about QM are slightly outdated, and I hear hints that
you didn't like physics very much ;-) So I doubt whether this analogy
is worth pursuing, especially since I think it was inappropriate to
begin with.

> My teachers always seemed to prefer the particle model.  I 
> prefer the wave model myself.  I think it is conceptually efficient.

For some problems, yes.  For others, no.  What's important is that
where it does describe the world correctly, there's no
"implementation" known to us that describes things better.  If such a
better description were to appear, it would immediately replace the
existing one.  That's not the relations between a mental model of a
user and the actual implementation known to developers.  For example,
a mental model could stay even when the implementation is radically
changed.

> > Agreed; however, existence of such an information should not be
> > declared as a fatal blow to the ability of users to learn to use a
> > tool safely and efficiently.  It is a bonus, but not a necessity.
> 
> Without a good conceptual model, it is doubtful if they can use it "safely and 
> efficiently."

100% agreement.

Re: base

[Uday S Reddy]

On 8/26/2010 10:16 AM, Eli Zaretskii wrote:

> (For the record, I wrote such a document a few months ago and
> submitted it to the bzr developers.  I have no idea when it will
> become part of the official docs.)

I found it on the Bazaar list.  It is a good start.  I don't see why there is 
any idea that DAGs are supposed to be avoided.  The only thing technical about 
DAGs is their name.  Everybody that can read a map knows DAGs.

> As I said elsewhere in this thread, the quality of documentation in
> the bzr project leaves a lot to be desired.  But we should distinguish
> between inadequacy of the existing documentation and the basis upon
> which to create a coherent mental model that should be presented to
> users.  This subthread started with an assertion that such a model
> does not exist for bzr, but does exist for other dVCSs.  This is the
> issue here, not whether bzr documenters did a good job.

Well, isn't this kind of "existence" meta-physical?  If it hasn't been written 
down, and generally agreed upon by all the participants, what sense does it 
exist in?  Sure, many of us users possibly form some mental model based on our 
narrow experience.  (And, perhaps, some users don't.)  But those models may or 
may not explain all aspects of the software.  To really exist, they have to be 
used and validated by practice.

>> Without a good conceptual model, it is doubtful if they can use it "safely and
>> efficiently."
>
> 100% agreement.

Ok, glad to be in agreement.  But, note that simplified models are only 
starting points.  Good models have to explain everything that happens.  You can 
start by ignoring air resistance to understand gravity.  But, don't start 
flying airplanes without understanding air resistance.

Cheers,
Uday

Re: base

[Eli Zaretskii]

> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Date: Thu, 26 Aug 2010 13:25:03 +0100
> 
> Well, isn't this kind of "existence" meta-physical?  If it hasn't been written 
> down, and generally agreed upon by all the participants, what sense does it 
> exist in?

I don't need to write down my mental model in order for it to exist.

> To really exist, they have to be used and validated by practice.

My models are used by me, and validated by my practice.

> But, note that simplified models are only starting points.  Good
> models have to explain everything that happens.

No, they only need to explain what I need to do for the job at hand.
That's hardly "everything".

> You can start by ignoring air resistance to understand gravity.
> But, don't start flying airplanes without understanding air
> resistance.

Life is short.  Not everyone will want or need to fly airplanes.
Those who won't don't need to understand drag.

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> I submit that a good model does not need to be based on implementation
> details.

In the case of git, you got this backwards. As the model is so simple,
the implementation is immediate, so when the model is explained it is
easy to get the impression that they are explained the
implementation. And vice-versa: unlike the Emacs redisplay code, it is
easy to describe the model by describing the implementation. They are
almost the same.

Down the thread you say:

>> Well, isn't this kind of "existence" meta-physical?  If it hasn't
>> been written down, and generally agreed upon by all the participants,
>> what sense does it exist in?
>
> I don't need to write down my mental model in order for it to exist.

If you have a mental model, I have my own and the bzr developers each
have theirs... it is a recipe for confussion when we need to
communicate, don't you think? And as your model may not fit the reality
(because it is your creation based on incomplete sources) you may get
upset from time to time because the tool does not act as you expect and
the developers refuse to consider those deviations as bugs.

[snip]

Re: base

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 26 Aug 2010 15:27:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [snip]
> 
> > I submit that a good model does not need to be based on implementation
> > details.
> 
> In the case of git, you got this backwards. As the model is so simple,
> the implementation is immediate, so when the model is explained it is
> easy to get the impression that they are explained the
> implementation. And vice-versa: unlike the Emacs redisplay code, it is
> easy to describe the model by describing the implementation. They are
> almost the same.

So you are saying that there's no way a user can understand how to use
git efficiently without knowing about SHA1, hashes, blobs, index
files, and how they all live happily in disk files and point to one
another?

> If you have a mental model, I have my own and the bzr developers each
> have theirs... it is a recipe for confussion when we need to
> communicate, don't you think?

Good documentation should cause you and me form models that are very
similar if not identical.  The models of the developers I don't care
about, as long as they care about mine (the documentation should tell
them what my model should be).

> And as your model may not fit the reality
> (because it is your creation based on incomplete sources) you may get
> upset from time to time because the tool does not act as you expect and
> the developers refuse to consider those deviations as bugs.

Models need to be updated from time to time.  It's inevitable.

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> So you are saying that there's no way a user can understand how to use
> git efficiently without knowing about SHA1, hashes, blobs, index
> files, and how they all live happily in disk files and point to one
> another?

It is perfectly possible to use git without knowing its model, in the
sense that you can store your changes on the repo, see logs, etc. More
or less like CVS or Subversion (or Bazaar!) where the user knows recipes
for dealing with a restricted, mostly simplistic, set of
requirements. On the long term (or not so long) it is not the most
cost-effective approach.

For any dVCS, revision IDs are a core concept. A user that doesn't
understand revision IDs eventually will suffer the consequences of his
ignorance. That applies to git's SHA1 hashes and to whatever bzr uses as
IDs. Blobs and trees are on the foundations of git and defines how it
stores information. Having some knowledge about them makes easy to
understand why git does not track empty directories, how file renaming
is (un)supported, why some operations are blazingly fast but others
(`annotate') are not, etc. The index is one of the most useful
innovations of git. If you insist on ignoring its existence you are
missing a really good feature. Almost every operation in git is about
creating trees, blobs and updating pointers (refs). Do you want to see a
file on another branch without switching to it? If you know about refs,
trees and blobs, it is straightforward. Want to temporaly reset your
working copy to some point on the past? If you know what a git ref is
then you already know that it is possible. Refs are arranged on the file
system on the same way you can name them (i.e. "git log
refs/remotes/origin/master" will work fine)

You will agree that having an insight on how a tool is designed
increases your effectiveness while using it. Some tools makes easy to
gain that insight, because its design is simple enough, or because its
documentation is very good. Such a tool has an advantage over its
competitors.

[snip]

Re: base

[David Robinow]

On Thu, Aug 26, 2010 at 10:42 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>...
> For any dVCS, revision IDs are a core concept. A user that doesn't
> understand revision IDs eventually will suffer the consequences of his
> ignorance. That applies to git's SHA1 hashes and to whatever bzr uses as
> IDs. Blobs and trees are on the foundations of git and defines how it
> stores information. Having some knowledge about them makes easy to
> understand why git does not track empty directories, how file renaming
> is (un)supported, why some operations are blazingly fast but others
> (`annotate') are not, etc. The index is one of the most useful
> innovations of git. If you insist on ignoring its existence you are
> missing a really good feature. Almost every operation in git is about
> creating trees, blobs and updating pointers (refs). Do you want to see a
> file on another branch without switching to it? If you know about refs,
> trees and blobs, it is straightforward. Want to temporaly reset your
> working copy to some point on the past? If you know what a git ref is
> then you already know that it is possible. Refs are arranged on the file
> system on the same way you can name them (i.e. "git log
> refs/remotes/origin/master" will work fine)
> ...

Do you realize you are making an effective argument against using a
Distributed Version Control System?  If I had to go to auto mechanic
school to learn to drive, I'd probably take the bus.

Re: base

[Óscar Fuentes]

David Robinow <drobinow@gmail.com> writes:

> Do you realize you are making an effective argument against using a
> Distributed Version Control System?  If I had to go to auto mechanic
> school to learn to drive, I'd probably take the bus.

Do you think that investing half an hour (or maybe a full hour depending
on the document used) to know a key tool for your daily work is too
much? Having such knowledge will save you lots of time.

Unless you are not a programmer. In such case the git model can look
inaccessible. One of the reasons why the bzr developers are so reluctant
to give a sound technical foundation to their documentation is to avoid
shooing non-technical users, as it seems that they reached the
conclusion that being attractive to that audience is the only hope for
saving bzr from the irrelevance.

Re: base

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> So you are saying that there's no way a user can understand how to use
>> git efficiently without knowing about SHA1, hashes, blobs, index
>> files, and how they all live happily in disk files and point to one
>> another?
>
> It is perfectly possible to use git without knowing its model, in the
> sense that you can store your changes on the repo, see logs, etc. More
> or less like CVS or Subversion (or Bazaar!) where the user knows recipes
> for dealing with a restricted, mostly simplistic, set of
> requirements. On the long term (or not so long) it is not the most
> cost-effective approach.
>
> For any dVCS, revision IDs are a core concept. A user that doesn't
> understand revision IDs eventually will suffer the consequences of his
> ignorance. That applies to git's SHA1 hashes and to whatever bzr uses as
> IDs. Blobs and trees are on the foundations of git and defines how it
> stores information. Having some knowledge about them makes easy to
> understand why git does not track empty directories,

Actually, it doesn't make it easy to understand.  After all, git tracks
symbolic links which have as little information beside the entry itself
as directory entries do.

It would be easy for git to make an additional entry for the directory
entry itself.

-- 
David Kastrup

Re: base

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > It is perfectly possible to use git without knowing its model, in
 > the sense that you can store your changes on the repo, see logs,
 > etc. More or less like CVS or Subversion (or Bazaar!) where the
 > user knows recipes for dealing with a restricted, mostly
 > simplistic, set of requirements.

Not "the" user.  A certain set of users.  Namely, the set of users who
simply follow the recommended workflows and don't complain or suggest
changes to them.

 > On the long term (or not so long) it is not the most cost-effective
 > approach.

For the users described above, it probably is.  That's why Bazaar is
reasonably popular among people who are project managers in
companies.  They choose one of the well-supported workflows (many of
which are rather centralized, which often suits managers), the users
learn it easily because Bazaar makes it easy, and life is good.
Nothing wrong with that.

For projects like Emacs, however, it is messy (and possibly
disastrous) if the people who are "making the rules" don't have a good
model.  Not only does each one have to have a model, but they had
better share almost all of it.  That's not just the folks like Stefan
and Richard who have big votes, but also folks like you, me, and Eli.

It's not the least common denominator users who are the reason that a
DVCS should provide a good model.  It's for the use of the policy
makers (and, as you argue convincingly, the power users).

 > Do you want to see a file on another branch without switching to
 > it? Want to temporarily reset your working copy to some point on
 > the past?

But many users will *never* want to do either of those.  They want to
clone the trunk or the stable branch (often not both!), and after that
they need log, status, diff, commit, update/pull, and push.  (And
maybe not even commit, let alone push.)

Re: base

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

>  > On the long term (or not so long) it is not the most cost-effective
>  > approach.
>
> For the users described above, it probably is.  That's why Bazaar is
> reasonably popular among people who are project managers in
> companies.  They choose one of the well-supported workflows (many of
> which are rather centralized, which often suits managers), the users
> learn it easily because Bazaar makes it easy, and life is good.
> Nothing wrong with that.

Apart from using a sub-optimal tool, right?

I agree that dumbed-down tools are right for some collectives and/or
projects. I strongly believe that Emacs' hackers are no such collective.

(bzr pretends to be a dumbed-down tool. In practice, it is more
difficult to use than the tool that implements the equivalent workflow
(git for fully distributed, subversion for centralized))

[snip]

>  > Do you want to see a file on another branch without switching to
>  > it? Want to temporarily reset your working copy to some point on
>  > the past?
>
> But many users will *never* want to do either of those.
[snip]

Seeing the user as someone with simplistic expectations and needs is a
capital sin in the Emacs religion.

Re: base

[Stephen J. Turnbull]

Óscar Fuentes writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > [snip]
 > 
 > >  > On the long term (or not so long) it is not the most
 > >  > cost-effective approach.
 > > For the users described above, it probably is.  That's why Bazaar
 > > is reasonably popular among people who are project managers in
 > > companies.  They choose one of the well-supported workflows (many
 > > of which are rather centralized, which often suits managers), the
 > > users learn it easily because Bazaar makes it easy, and life is
 > > good.  Nothing wrong with that.

 > Apart from using a sub-optimal tool, right?

We're not talking about tools here, we're talking about workflows and
use cases.

 > > But many users will *never* want to do either of those.
 > [snip]
 > 
 > Seeing the user as someone with simplistic expectations and needs
 > is a capital sin in the Emacs religion.

Please.  I advocate sharp tools and learning how to use them well,
too.  All I'm saying is that for many users, they will not need that,
and should be allowed to learn about the tool at their own pace.  Some
git users will never need more than "clone", "pull", and "log" (eg,
that's my use case for my X.org repos to date).

Other users will need more advanced uses, and I think it is a
responsibility of those who discuss project workflows to be familiar
with them.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > You are pushing a simple request ad absurdum.  I wasn't asking for
 > an exhaustive list of _all_possible_ workflows, only for a few
 > representative ones.  And please don't tell me that's impossible,
 > or even hard, because today I can easily do that for Bazaar.

No, you can provide some representative workflows that are enough for
you.  That's far from providing representative workflows that would be
enough to convince anyone who has actually used git that bzr is a
half-adequate replacement.

For example, suppose I ask, "How do I efficiently switch from one
branch to another in the same directory, like I do in git?"

Or "how do I rebase branch A from the common ancestor with branch B to
the grandparent of the head of branch C, which branched from trunk
before B did?"  And for a gold star, tell me whether it matters when B
branched from trunk.

I did both of those operations with git today, BTW, and the answer to
the gold star question for git is "no".

 > For complex and unconventional workflows, it _might_ be necessary
 > to use the history DAG to explain them, but for the common
 > workflows even that should not be necessary.

OK, if it's not necessary, do it.  Specifically, explain why pushing
directly from a working branch to the upstream repository "just like
a CVS commit" (which has got to be as simple and conventional as it
gets, right?) is a bad idea in Bazaar.  No references to the DAG are
allowed, because they're unnecessary, right?

And yes, I think it is fair to ask you to explain why a simple,
obvious, but deprecated workflow is deprecated.  That's as important
as describing the recommended workflows.  Not to mention that you
asked us, and you weren't alone.

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Miles Bader <miles@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 26 Aug 2010 20:01:02 +0900
> 
> Eli Zaretskii writes:
> 
>  > You are pushing a simple request ad absurdum.  I wasn't asking for
>  > an exhaustive list of _all_possible_ workflows, only for a few
>  > representative ones.  And please don't tell me that's impossible,
>  > or even hard, because today I can easily do that for Bazaar.
> 
> No, you can provide some representative workflows that are enough for
> you.

Actually, I meant some representative workflows that should cover the
common use-cases.

> That's far from providing representative workflows that would be
> enough to convince anyone who has actually used git that bzr is a
> half-adequate replacement.

Indeed, I see no reason to ask for workflows that convince not to use
bzr in a project that uses bzr.

> For example, suppose I ask, "How do I efficiently switch from one
> branch to another in the same directory, like I do in git?"

  bzr switch THE_OTHER_BRANCH

(I have no idea whether this is "like you do in git".)

> Or "how do I rebase branch A from the common ancestor with branch B to
> the grandparent of the head of branch C, which branched from trunk
> before B did?"

  cd A && bzr rebase --onto=revno:-3 ../C

> And for a gold star, tell me whether it matters when B branched from
> trunk.

I don't see why it should.  Although I'm probably missing something in
your description, because I don't understand what is B doing in this
story.  Both A and B branched from the trunk at the same point, right?

>  > For complex and unconventional workflows, it _might_ be necessary
>  > to use the history DAG to explain them, but for the common
>  > workflows even that should not be necessary.
> 
> OK, if it's not necessary, do it.  Specifically, explain why pushing
> directly from a working branch to the upstream repository "just like
> a CVS commit" (which has got to be as simple and conventional as it
> gets, right?) is a bad idea in Bazaar.  No references to the DAG are
> allowed, because they're unnecessary, right?

Right.  But there's nothing for me to explain here, because it is
already explained on the wiki: "it can cause history to be displayed
in a strange way in the upstream master, any mirrors or branches of
it, and your own branch later."  And the mail referenced from there
explains more: the revisions from the branch will appear as part of
mainline, and mainline will appear as if it were a branch.

Note that the acronym DAG is not used anywhere.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Miles Bader <miles@gnu.org>,
 > >     emacs-devel@gnu.org
 > > Date: Thu, 26 Aug 2010 20:01:02 +0900
 > > 
 > > Eli Zaretskii writes:
 > > 
 > >  > You are pushing a simple request ad absurdum.  I wasn't asking
 > >  > for an exhaustive list of _all_possible_ workflows, only for a
 > >  > few representative ones.  And please don't tell me that's
 > >  > impossible, or even hard, because today I can easily do that
 > >  > for Bazaar.
 > > No, you can provide some representative workflows that are enough
 > > for you.

 > Actually, I meant some representative workflows that should cover
 > the common use-cases.

By "common use cases" you evidently mean "but not anything that a git
user might want," or even "that a typical user can express in ordinary
terms and a git user could achieve by manipulating the DAG" (see below
for an example).

 > > That's far from providing representative workflows that would be
 > > enough to convince anyone who has actually used git that bzr is a
 > > half-adequate replacement.

 > Indeed, I see no reason to ask for workflows that convince not to
 > use bzr in a project that uses bzr.

Lack of some workflows I use frequently in git is certainly the most
important reason why I avoid bzr.  It will certainly inhibit me from
contributing code to Emacs in the near to medium term.  Maybe you
think that is a good thing?

 > > For example, suppose I ask, "How do I efficiently switch from one
 > > branch to another in the same directory, like I do in git?"
 > 
 >   bzr switch THE_OTHER_BRANCH

Thank you for playing.  Unfortunately, not only isn't that efficient,
it doesn't work at all without a fair amount of additional explanation:

  steve@uwakimon /tmp/test/bar $ bzr switch ../foo
  bzr: ERROR: Cannot switch a branch, only a checkout.

Obviously I just used ordinary branches to get that error.

But it's not clear to me whether the obvious change to that workflow,
ie, checkout from "../foo" in "bar", actually has the semantics of
git, though, and I bet you have no idea either.  For example, suppose
I want to merge two branches in that checkout, but preserve the
possibility of switching to either of the parents in the future.  This
is trivial in git: git checkout foo; git merge bar; git branch foo^
old-foo.  The obvious solution in bzr (bzr checkout -r before:) *does
not work*; it is not a branch and you cannot commit.  (At least,
that's what the dox say.)  So I expect I'd have to do a bit more
preparation to get a usable approximation to git colocated branches.

 > > Or "how do I rebase branch A from the common ancestor with branch
 > > B to the grandparent of the head of branch C, which branched from
 > > trunk before B did?"
 > 
 >   cd A && bzr rebase --onto=revno:-3 ../C

Thank you for playing.  Unfortunately, this doesn't work in several
cases.  I could get trunk commits or branch B commits I don't want.

So, what was that all about?

Translated to non-DAG terms, the scenario is "just add Miles's feature
and no extra crap".  To expand a bit (but still use only commonly
understood development concepts), "I just want Drew's branch with
Miles's feature.  But I don't want anything in Tom's branch that isn't
required to implement Miles's feature, I don't want any random work
done on the trunk since C branched, and I don't want the stuff that
Drew added to C in his last two commits."

I think "just add Miles's feature and no extra crap" is a reasonable
thing to want.  It probably would not occur to you to ask your VCS to
do it unless you understand the DAG, though.

I don't think it's reasonable to ask anybody to explain how to achieve
that result based on a few memorized workflows, and without reference
to the DAG.  However, the DAG-based description, and its git
implementation should give me a close approximation to what I really
want.  The git implementation is straightforward:

    git rebase --onto C~2 B A

(or "git checkout A; git rebase --onto C~2 B").

 > Note that the acronym DAG is not used anywhere.

OK, you got me on that one.  1 out of 3 ain't bad. :-)

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Fri, 27 Aug 2010 22:03:13 +0900
> 
>  > > No, you can provide some representative workflows that are enough
>  > > for you.
> 
>  > Actually, I meant some representative workflows that should cover
>  > the common use-cases.
> 
> By "common use cases" you evidently mean "but not anything that a git
> user might want," or even "that a typical user can express in ordinary
> terms and a git user could achieve by manipulating the DAG" (see below
> for an example).

No, I meant use-cases that are of interest to ordinary users, as
opposed to technicians.

>  >   bzr switch THE_OTHER_BRANCH
> 
> Thank you for playing.  Unfortunately, not only isn't that efficient,
> it doesn't work at all without a fair amount of additional explanation:
> 
>   steve@uwakimon /tmp/test/bar $ bzr switch ../foo
>   bzr: ERROR: Cannot switch a branch, only a checkout.

It is documented to work only with checkouts.

> But it's not clear to me whether the obvious change to that workflow,
> ie, checkout from "../foo" in "bar", actually has the semantics of
> git, though, and I bet you have no idea either.  For example, suppose
> I want to merge two branches in that checkout, but preserve the
> possibility of switching to either of the parents in the future.  This
> is trivial in git: git checkout foo; git merge bar; git branch foo^
> old-foo.  The obvious solution in bzr (bzr checkout -r before:) *does
> not work*; it is not a branch and you cannot commit.

Some combination of "bzr merge -r" with appropriately chosen pair of
revision should be able to do the trick, I think.

> (At least,
> that's what the dox say.)  So I expect I'd have to do a bit more
> preparation to get a usable approximation to git colocated branches.

Why bother, if you can easily branch and work in a separate tree?

>  >   cd A && bzr rebase --onto=revno:-3 ../C
> 
> Thank you for playing.  Unfortunately, this doesn't work in several
> cases.  I could get trunk commits or branch B commits I don't want.

I don't understand what didn't work for you, but it could be due to
bugs in `rebase'.

> Translated to non-DAG terms, the scenario is "just add Miles's feature
> and no extra crap".  To expand a bit (but still use only commonly
> understood development concepts), "I just want Drew's branch with
> Miles's feature.  But I don't want anything in Tom's branch that isn't
> required to implement Miles's feature, I don't want any random work
> done on the trunk since C branched, and I don't want the stuff that
> Drew added to C in his last two commits."
> 
> I think "just add Miles's feature and no extra crap" is a reasonable
> thing to want.  It probably would not occur to you to ask your VCS to
> do it unless you understand the DAG, though.

I see no problems doing what you want with a series of "bzr merge"
commands.  "bzr rebase" is simpler, but if it doesn't work, "merge"
will.

And I don't see any reason to "understand the DAG", either.  What's to
understand, anyway? I know what a DAG is, and I think I have some idea
what "bzr merge" does to a history.  I don't pretend being a
technician, but what I know is enough for what I do.  It was enough to
suggest solution to your riddles, even though I never needed to do any
of that.  So what if some of the solutions have limitations or hit
upon bugs? that's not what this was about.

> 1 out of 3 ain't bad. :-)

You are a darling.

Re: base

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> By "common use cases" you evidently mean "but not anything that a git
>> user might want," or even "that a typical user can express in ordinary
>> terms and a git user could achieve by manipulating the DAG" (see below
>> for an example).
>
> No, I meant use-cases that are of interest to ordinary users, as
> opposed to technicians.

What's the difference, exactly...?

["No True Scotsman would ever use a DAG!"]

-Miles

-- 
Congratulation, n. The civility of envy.

Re: base

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Fri, 27 Aug 2010 23:25:45 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> By "common use cases" you evidently mean "but not anything that a git
> >> user might want," or even "that a typical user can express in ordinary
> >> terms and a git user could achieve by manipulating the DAG" (see below
> >> for an example).
> >
> > No, I meant use-cases that are of interest to ordinary users, as
> > opposed to technicians.
> 
> What's the difference, exactly...?

See the rest of the thread, it's all there.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > No, I meant use-cases that are of interest to ordinary users, as
 > opposed to technicians.

Sure, but what about the case of "I want this feature, but no other
crap"?  Why wouldn't that be of interest to an ordinary user?  In git,
that's simple to express:

    git rebase --onto my-branch feature-parent feature-branch

You do need to know which branch is feature-parent, but gitk will tell
you that with "gitk --all".  You only need to be able to see the green
tags in gitk, and trace your branch of interest back to its node and
up again to a tag (and any such tag will do -- although it requires
some understanding of DAGs to know *why*, this means it's hard for a
naive user to make a mistake here).  So doing this is not beyond an
ambitious but non-technical user at all.  *Explaining how* to do it,
though, requires some knowledge.

The point of this whole subthread is that the git model makes this
easy (for the technician) to think about.  It is not easy to think
about this in bzr, and harder to implement.  You wave your hands and
say "I'm sure it can be done with merge".  Well, I'm pretty sure too,
but I'm also sure I'd have to ask Robert Collins to tell me how.

 > Why bother [with colocated branches], if you can easily branch and
 > work in a separate tree?

Because I *don't like* working in a separate tree for *some* purposes,
although I readily create separate workspaces (in git) for others.
Why should power users have to put up with these limitations?

 > And I don't see any reason to "understand the DAG", either.  What's
 > to understand, anyway?

It's not a big deal to "understand the DAG," of course.  You can just
see it with the appropriate tool (and all VCSes supply such a tool).
What's useful is to understand how user-level concepts like "features"
map to the DAG, and how your VCS can manipulate DAG parts that (may or
may not) correspond to user-level features.

 > I know what a DAG is, and I think I have some idea what "bzr merge"
 > does to a history.

Oh?  Suppose that branch foo has 4 revisions and branch bar has only
the first one.  Now do "bzr merge -r2..4 ../foo; bzr commit -m merge"
in branch bar.  What does "bzr log -n0" show?  I was surprised (and
disappointed, although I understand why it happened once I saw the
result).

#! /bin/bash
pushd /tmp; mkdir test; cd test
mkdir foo; cd foo; bzr init
addfile () { echo $1 > $1; bzr add $1; bzr commit -m "add $1"; }
addfile foo
bzr branch . ../bar
addfile bar
addfile baz
addfile quux
cd ../bar
bzr merge -r2..4 ../foo; bzr commit -m merge
bzr log -n0

Did you predict the output correctly?

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: miles@gnu.org,
>     emacs-devel@gnu.org
> Date: Sun, 29 Aug 2010 01:25:45 +0900
> 
> Eli Zaretskii writes:
> 
>  > No, I meant use-cases that are of interest to ordinary users, as
>  > opposed to technicians.
> 
> Sure, but what about the case of "I want this feature, but no other
> crap"?  Why wouldn't that be of interest to an ordinary user?  In git,
> that's simple to express:
> 
>     git rebase --onto my-branch feature-parent feature-branch

In bzr, it's also simple:

      bzr rebase ../parent

(modulo bugs in `rebase').  Or, if we don't want to futz with
`rebase':

      bzr merge -rN1..N2 ../feature-branch

assuming that revisions N1 to N2 introduced "the feature" on the other
branch.

> *Explaining how* to do it, though, requires some knowledge.

I have no problems explaining why the latter works, see below.  As for
the former, the documentation of `rebase' seem to be clear enough,
FWIW.

>  > Why bother [with colocated branches], if you can easily branch and
>  > work in a separate tree?
> 
> Because I *don't like* working in a separate tree for *some* purposes,
> although I readily create separate workspaces (in git) for others.
> Why should power users have to put up with these limitations?

I don't see it as a limitation.  Disk space is not at premium anymore.
OTOH, the mental resources needed to remember which branch I'm on now
_are_ at premium with this old fart.  I prefer to see the branch name
right there at the shell prompt, to serve as a reminder.

> Oh?  Suppose that branch foo has 4 revisions and branch bar has only
> the first one.  Now do "bzr merge -r2..4 ../foo; bzr commit -m merge"
> in branch bar.

"bzr merge -rN1..N2 FOO" applies to the current branch the changes
introduced in revisions (N1..N2] of branch FOO.  That's the simple
mental model I have about "bzr merge", and it seems to work for me.
For the situation you describe, it should add files `baz' and `quux',
which were added in revisions 3 and 4 in branch foo.

> Did you predict the output correctly?

Yes, assuming you mean this output:

  /tmp/test/bar$ bzr merge -r2..4 ../foo; bzr commit -m merge
  +N  baz
  +N  quux
  All changes applied successfully.
  Committing to: /tmp/test/bar/
  added baz
  added quux
  Committed revision 2.

Re: base

[Leo]

On 2010-08-28 18:32 +0100, Eli Zaretskii wrote:
> In bzr, it's also simple:
>
>       bzr rebase ../parent

The above could not be anywhere similar to git with --onto.

Leo

Re: base

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 28 Aug 2010 19:58:43 +0100
> 
> On 2010-08-28 18:32 +0100, Eli Zaretskii wrote:
> > In bzr, it's also simple:
> >
> >       bzr rebase ../parent
> 
> The above could not be anywhere similar to git with --onto.

You cannot expect me to know what git commands do, exactly.  Without
any detailed explanations, I can only guess.

Re: base

[Leo]

On 2010-08-28 20:58 +0100, Eli Zaretskii wrote:
> You cannot expect me to know what git commands do, exactly.  Without
> any detailed explanations, I can only guess.

Sorry. I thought you can find it in `git help rebase' that includes some
nice ASCII graphs.

Leo

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > user?  In git, that's simple to express:
 > > 
 > >     git rebase --onto my-branch feature-parent feature-branch
 > 
 > In bzr, it's also simple:
 > 
 >       bzr rebase ../parent

No, it's not that simple.  You need to specify three things which can
vary more or less independently: the first version to rebase, the last
version to rebase, and where to rebase them.  The bzr syntax only
allows two of the three: the current branch, and the point at which to
rebase.  It *can't* work in the general case.

 > (modulo bugs in `rebase').  Or, if we don't want to futz with
 > `rebase':
 > 
 >       bzr merge -rN1..N2 ../feature-branch
 > 
 > assuming that revisions N1 to N2 introduced "the feature" on the
 > other branch.

That does the wrong thing.  Although it merges the right content, it
loses all the history.

 > > *Explaining how* to do it, though, requires some knowledge.

 > I have no problems explaining why the latter works, see below.  As
 > for the former, the documentation of `rebase' seem to be clear
 > enough, FWIW.

Then you have *real* problems, because you think you know what you're
doing, but you don't.

Of course, it's possible that your model is sufficient for your
purposes.  Maybe you don't use rebase at all, or maybe history loss
doesn't bother you in this case.  Good for you!  But that makes your
input into discussions of *project* workflow quite suspect, because
your advice is at best irrelevant, and at worst wrong, for what some
of your colleagues want to do.

 > > Because I *don't like* working in a separate tree for *some*
 > > purposes, although I readily create separate workspaces (in git)
 > > for others.  Why should power users have to put up with these
 > > limitations?

 > I don't see it as a limitation.  Disk space is not at premium
 > anymore.  OTOH, the mental resources needed to remember which
 > branch I'm on now _are_ at premium with this old fart.  I prefer to
 > see the branch name right there at the shell prompt, to serve as a
 > reminder.

Good for you.  But why should your preferences rules *my* workflow?

It's not a question of disk space.  It's a question of preferred
workflow.  I like git's colocated model for some purposes, like a
quick switch to a branch for accumulating typo fixes, or recording
alternative specifications of a feature and their implementations.  I
also like it because it allows me to group some branches that are
related together, and add or delete branches as they become
(ir)relevant to that task, then clone the whole thing to a difference
host, or offer it to a colleague.

 > > Oh?  Suppose that branch foo has 4 revisions and branch bar has
 > > only the first one.  Now do "bzr merge -r2..4 ../foo; bzr commit
 > > -m merge" in branch bar.

 > "bzr merge -rN1..N2 FOO" applies to the current branch the changes
 > introduced in revisions (N1..N2] of branch FOO.

Yes, it does that ... for the content.  However, it forgets the
history N1..N2 which was just applied, which is undesirable for two
reasons: first, I want to see it with an ordinary log command (not
switching branches), and second, at least in theory the VCS should be
able to use that information to avoid merge conflicts in the future
should that branch be merged again.

 > That's the simple mental model I have about "bzr merge", and it
 > seems to work for me.  For the situation you describe, it should
 > add files `baz' and `quux', which were added in revisions 3 and 4
 > in branch foo.
 > 
 > > Did you predict the output correctly?
 > 
 > Yes, assuming you mean this output:
 > 
 >   /tmp/test/bar$ bzr merge -r2..4 ../foo; bzr commit -m merge
 >   +N  baz
 >   +N  quux
 >   All changes applied successfully.
 >   Committing to: /tmp/test/bar/
 >   added baz
 >   added quux
 >   Committed revision 2.

No, I mean the output of bzr log -n0.  In particular, were you
expecting that the history of changes you just merged would just
vanish into thin air?

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Sun, 29 Aug 2010 04:16:16 +0900
> 
> No, I mean the output of bzr log -n0.  In particular, were you
> expecting that the history of changes you just merged would just
> vanish into thin air?

foo is the mainline, while bar is a branch, right?

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: emacs-devel@gnu.org,
 > >     miles@gnu.org
 > > Date: Sun, 29 Aug 2010 04:16:16 +0900
 > > 
 > > No, I mean the output of bzr log -n0.  In particular, were you
 > > expecting that the history of changes you just merged would just
 > > vanish into thin air?
 > 
 > foo is the mainline, while bar is a branch, right?

In this case, yes.

Re: base

[Uday S Reddy]

On 8/26/2010 12:01 PM, Stephen J. Turnbull wrote:

> OK, if it's not necessary, do it.  Specifically, explain why pushing
> directly from a working branch to the upstream repository "just like
> a CVS commit" (which has got to be as simple and conventional as it
> gets, right?) is a bad idea in Bazaar.  No references to the DAG are
> allowed, because they're unnecessary, right?

Ok, let me take a crack at this.

You have a local mirror, which has a pull/push relationship to the upstream, 
and a working branch, which has a pull/push relationship to the local mirror. 
Now you push from the working branch to upstream.  Let us say revisions 
101...103 get pushed.  Next I pull into the local mirror.  These revisions get 
pulled there.  And, then, sometime later, I pull from the local mirror to the 
working branch.  Will I get new copies of 101...103 into the working branch, or 
will Bazaar know that they were already there?

I haven't got a clue!

My strategy with Bazaar is generally to do only the operations that I know to 
work.  These are either the workflows already covered in the documents, or 
others that are reasonably similar to them.  There isn't enough information out 
there to help me figure out what will happen with tricky flows like these. 
And, I don't want to end up in a deep soup with a corrupted repository.  So, if 
I accidentally ended up in this situation, I would play it safe by deleting the 
working branch and creating a new one.

If I actually do a circular push-pull without realizing that I was doing it and 
it actually worked, I will probably realize later that Bazaar handles cycles 
ok, and be comfortable doing it again in future.  So, I am really like a monkey 
playing a piano.  Or, maybe, the piano is playing me!

Cheers,
Uday

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I'm not sure I understand what is a ``teachable mental model'',

A "teachable mental model" is a simple way of thinking about the
software's behavior.  It might be an equation or an algorithm or data
structure.  To be simple, it needs to be abstract, and probably is
more general than the software can actually handle.  Well-designed
software will emit errors or warnings when its limits are exceeded,
even though they are compatible with the simple model.  Within those
limits, the software's behavior will be predictable using the model,
including undocumented behavior (ie, in debugging).

 > and where do you see such a model explained in, e.g., git's or hg's
 > docs.

For git, it's in the Community Book,
http://book.git-scm.com/1_the_git_object_model.html, and following
chapters.

Actually, for git the most concise explanations were in the original
"git" man page, back in the early 1.x days (1.1, 1.2-ish).  Much of
that material is in the "gittutorial-2" man page as of git 1.7.x.x,
but it's been rehashed into tutorial form so the model has been kinda
buried.  However, if you look closely, maybe you can see the structure
of the object database (which contains history DAG, directory
structure of the project, and file content, plus some auxiliary object
types), and the relations of the object database, the index (the next
commit under construction), and the workspace.

For Mercurial, the structure of a branch and its associated databases
is described in The Book,
http://hgbook.red-bean.com/read/behind-the-scenes.html.

I don't think any such thing exists for bzr.  One problem is that the
basic storage model for bazaar branches has changed many times.  See
"bzr help current-formats", with four currently listed.  I believe
that I've seen as many as seven there.  I believe repo format has also
changed at least once.

BTW, I have zero sympathy for the point of view that printed books and
HTML don't count as documentation unless they're distributed with the
program.

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Thu, 26 Aug 2010 01:09:01 +0900
> 
> For git, it's in the Community Book,
> http://book.git-scm.com/1_the_git_object_model.html, and following
> chapters.
> [...]
> For Mercurial, the structure of a branch and its associated databases
> is described in The Book,
> http://hgbook.red-bean.com/read/behind-the-scenes.html.

That's not a "mental model", at least not by your definition (nor by
mine, should I guess what that is).  That's the data structures part
of the internals manual.

I don't see how users would need to know that stuff in order to be
able to use the tool safely and efficiently.  It's like saying that
Emacs users need to know how Lisp data types are implemented or what
is the glyph matrix, in order to make good _use_ of Emacs (as opposed
to _extend__ it).  Sure, it's nice to know all that, but it isn't (and
shouldn't) be necessary for a user.  If you want to _extend_ the tool,
then yes, you'd need this and some more.

> I don't think any such thing exists for bzr.

http://doc.bazaar.canonical.com/bzr.2.2/developers/overview.html and
other docs in that area comes close, maybe.  But that stuff is
rightfully in the developers' department, IMO.

> BTW, I have zero sympathy for the point of view that printed books and
> HTML don't count as documentation unless they're distributed with the
> program.

Well, we disagree, then.

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > That's not a "mental model", at least not by your definition

Of course it is, by *my* definition.  Of course I can't speak for
yours, though.  *sigh*  I guess I'm going to have to go into
interminable detail on this....

 > I don't see how users would need to know that stuff in order to be
 > able to use the tool safely and efficiently.

Really?  Don't you mean "I'd like to believe that users don't need to
know, because it's inconvenient and tedious"?

 > It's like saying that Emacs users need to know how Lisp data types
 > are implemented or what is the glyph matrix, in order to make good
 > _use_ of Emacs (as opposed to _extend__ it).

No, it isn't.  Your analogy is broken, because you are ignoring the
difference between private and public data.  When you use Emacs as an
editor, the public data is text.  When that text is structured, you
demand that other contributors understand the structure of the text,
whether it's C code, LISP code, TexInfo documentation, docstrings, or
even ChangeLogs and the NEWS file.  LISP data and the glyph matrix are
private data, and it's reasonable to ask Emacs to deal with them and
not bother you with those details when you're using Emacs.  You can
even ask Emacs to help with the syntax of text.  But eventually you
have to tell the users "You need to know TexInfo or whatever to work
on the manual, and you need to know when to use @code and when to use
@samp."  Emacs will help you produce correct syntax for @code, but it
can't tell you when to use it.

The history DAG and the commit metadata are public data.  They are
shared, they can be seen not only by the user who produces them but by
everybody in the project.  There are choices to be made, and they
don't have technical answers; they're matters of taste and policy.
You cannot expect the VCS to make correct decisions according to
project policy about when and where to branch, or which branch to
merge into which other, or when to rebase and when to merge at this
stage of the technology.

Project policy about what constitutes a "nice readable" history is a
matter of taste and a matter of software capability.  If users are
going to participate in those discussions, they need to understand the
capabilities of the software.  Bazaar is very feature-poor as far as
history restructuring goes; if you want a particular structure, you
need to follow a workflow that produces it.  Those workflows turn out
to be more complex for Emacs than the old workflows, and people
immediately complained.  That resulted in people posting alternative
workflows which work in *some* situations but not others, and yet
other people screwing up history by taking shortcuts with the
alternative workflows without having any idea what they were doing to
the DAG.

 > Sure, it's nice to know all that, but it isn't (and shouldn't) be
 > necessary for a user.  If you want to _extend_ the tool, then yes,
 > you'd need this and some more.

You may be right about "shouldn't", but you are wrong about "isn't",
at least given the capabilities of the chosen tool and at the level of
anybody who wants to participate in discussions about what the Emacs
workflow should be.

 > > I don't think any such thing exists for bzr.

 > http://doc.bazaar.canonical.com/bzr.2.2/developers/overview.html
 > and other docs in that area comes close, maybe.  But that stuff is
 > rightfully in the developers' department, IMO.

And in mine.  That is not even on the same planet with a mental model.
It's full of details that developers need to know to write the code to
work with Bazaar internals, but completely unnecessary to an
explanation of how the things the user can see work together with each
other and with the users.  OTOH, it is no help in understanding
externally visible behavior, whether intentional or buggy.

By contrast, the object database model as presented by the Git
Community Book is abstract.  In fact if you look into a real git ODB,
you'll just see files full of apparently random bits -- they're all
delta-compressed and gzipped.  Such details are not part of the mental
model, and they're not in the book (not emphasized in that chapter, at
least).

And that model can be visualized directly in git by gitk.  If you can
see it there, it's in your repository.  You can look at directory
objects or at files (the GUI version of the use of cat-file in
gittutorial-2), or at diffs.  This is not necessarily true in bzr,
which supports "ghost revisions" -- don't ask, I don't know the
details.  But that has to complicate the mental model, and it
definitely complicates and weakens the implementation: "ghost
revisions" are implicated in several of the cases of wedged branches
I've seen reported on bazaar@canonical.

You can logically traverse the graph you see in gitk using reset or
checkout, and it will have a visible effect on the display in gitk
(after doing refresh or maybe reload).

Modern versions of gitk will also display a representation of the
index to you (which you can also get from the status command).  The
bzr model behind status is much fuzzier (although this probably
doesn't matter as much as the object model).

So having a model means that it is easy to understand what an git
operation will do in terms of the graph you see in gitk.  "commit"
makes a node and links it on to the head of the active branch,
"branch" and "tag" produce labels, etc.  Fetch adds hidden nodes and
arcs to the graph, pull or merge makes them visible by attaching them
to the visible part of the graph and committing on top, then advancing
the branch head to the new commit (thus making the new nodes
"reachable from HEAD" in graph-theoretic terms, and gitk will adjust
the display by making these newly reachable nodes visible upon
refresh/reload).  In bzr, however, it's not so obvious how to think
about this.  The commit is not automatic, so "merge" seems to be about
content rather than the DAG.

And there's one really big difference.  In the mental model I use, git
objects are *eternal* and *universal*.  They've always existed, they
always will, and they're the same for everyone.  This is because of
the (model) 1-1 map between SHA1 hash values and all the possible
objects that could in theory exist.  (In reality, a hash isn't good
enough, for "eternity" and "all" you really want something like Gödel
numbers but with better compression properties -- a typical difference
between "mental model" and "implementation".)  In the actual git
implementation, once you've seen an object's content, it's "eternal
enough".  That is, a non-garbage object is never deleted, and even
garbage is kept around for 60 days by default.  (Hey, that's even
better than Scheme's promise of eternity!  And if that worries you,
you can set garbage collection to "never".)  Once you realize that,
recovery from rebase madness or inadvertant deletion of a branch[1]
becomes a certainty -- you just need to find the command that does the
tracing part of garbage collection, which will list up the dangling
heads and other unreachables for you.  This may not mean much to you,
but I think of git as very reliable because I know what it promises
about my data, and I'm quite confident that Linus's original design
was straightforward and good ("just how hard can it be to design a
linked list?" he asks the Emacs developers), and that improvements
since then didn't require a genius to work on the ODB, just ordinarily
smart hackers.

This *simply isn't true* of bzr.  Eternity is a little shaky.  bzr
uncommit will (eventually) destroy the commit, and nothing in the bzr
docs or that I've read on bazaar@canonical gives me a model of *when*,
except that I sorta think that it won't be copied when you branch from
that branch.  Practically, the bzrtools plugin does have a "heads"
command which will allow you to find such objects, so probably this is
no worse than git.  But not having a model worries me.  Worse, bzr
objects are definitely *not* universal from the external viewpoint
(eg, two identical programs can be different objects in bazaar).  bzr
tracks "containers" (delete all the content and metadata like name
from a file, and you have a "container").  This is what allows it to
do the much-vaunted "provably correct tracking of copies and renames".
Containers have identifiers (those arch-ids you see in Emacs files are
actually container ids), and those ids depend on who created them,
where, and when.  Two containers can be exactly the same as files, but
they'll be different anyway.  I don't have a model of this.  That is,
I don't understand why this is the provably correct way to treat
renames and copies.

And who knows how the history DAG is represented in Bazaar?  I don't,
and I suspect it changes from branch format to branch format.  Why do
the "rich root" formats need to be incompatible with the non-rich-root
formats, and what are they good for anyway?  You got me on both
counts.  This kind of thing just goes on and on and on and on and on
and on and on and on and on and on and on and on and on and on and ....

Note that I'm not saying that Bazaar is inconsistent or incoherent.
I'm saying that I personally have trouble giving an account of why
it's consistent and coherent.  I would not want to try to debug *any*
failure in bzr without the help of the developers, because I have no
idea where I'd start.  OTOH, I can give an account of why git does
what it does, and I've had success in teaching that model to others.
Although the first thing I'd do in case of a bug is report it, the
second thing I'd do is to start browsing code.  I think I'd have a
good chance of localizing the issue, because I have a model of how git
is supposed to work.  YMMV.

Footnotes: 
[1]  Branches are *not* objects, they are *refs* = references to
objects, and so can be created or deleted at will without breaking any
promises about object permanence.

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Thu, 26 Aug 2010 19:25:35 +0900
> 
> *sigh* I guess I'm going to have to go into interminable detail on
> this....

Thanks.  However, what you wrote just shows once again that we are
talking on two very different levels.  Your "user" is actually a
hacker who wants to know and understand a lot about low-level details
of the tool's operation.  My idea of a user and the level of this
knowledge users need is very different.  You say that it is impossible
in practice to use tools without such deep knowledge.  I say that it's
possible and prove that by doing it, with bzr and with other tools.

There are a few tools I use where my level of familiarity with the
internals is like yours regarding git, but bzr is not one of them, and
probably never will be.  Still, I have no trouble using it quite
efficiently (no thanks to bzr docs), without having a slightest idea
how it represents the history DAG or what are all those files in the
.bzr subdirectories of my repository.  Contrary to what you say, these
are, IMO, private data, not public data; for example, if bzr changes
its repository format, I as a user don't care as long as there's a
simple way of upgrading to the new format.  The fact that this data is
visible does not mean it's public in the sense that users _should_
look at them, it just means that they _can_.

I don't expect you to agree, so let's leave it at that.  I already
wrote a lot, maybe too much, about my views on this today.

Re: base

[Leo]

On 2010-08-26 12:26 +0100, Eli Zaretskii wrote:
> There are a few tools I use where my level of familiarity with the
> internals is like yours regarding git, but bzr is not one of them, and
> probably never will be. Still, I have no trouble using it quite
> efficiently (no thanks to bzr docs), without having a slightest idea
> how it represents the history DAG or what are all those files in the
> .bzr subdirectories of my repository.

I don't think Stephen was arguing that in order to use git effectively
one must learn its internals. It was rather that git has a very simple
foundation for those who want to explore it.

Many people use git without understanding its model and yet they are
far more efficient than using other tools such as bzr happily doing
merging, branching and rebasing.

Leo

Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Thanks.  However, what you wrote just shows once again that we are
 > talking on two very different levels.  Your "user" is actually a
 > hacker who wants to know and understand a lot about low-level
 > details of the tool's operation.

No.  I'm saying that the project needs a few users who understand at
that level, and that therefore it is important to have such a model.
See my response to Óscar for details.  Óscar's point about the
simplicity of the git model is also relevant.

I apologize for not making it clear that I do understand that average
users can do fine without deep understanding (but with competent
guidance).  My main point is that somebody like you who has intervened
in the process of recommending workflows really should have a good
model.

 > quite efficiently (no thanks to bzr docs), without having a
 > slightest idea how it represents the history DAG or what are all
 > those files in the .bzr subdirectories of my repository.

Er, Eli, I didn't mention any of those files (or their analogs in
git), and I don't recall the docs I pointed to describing them,
although it did mention their existence.

 > Contrary to what you say, these are, IMO, private data, not public
 > data; for example, if bzr changes its repository format, I as a
 > user don't care as long as there's a simple way of upgrading to the
 > new format.

But the point is that often there isn't a simple way.  In fact, on one
of my platforms I'm currently stuck without a usable bzr because
Ubuntu Jaunty provides bzr 1.13, and that doesn't do format 2a, which
is required for Launchpad.  Upgrading Ubuntu is not an easy option for
me, either.

Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: miles@gnu.org,
>     emacs-devel@gnu.org
> Date: Fri, 27 Aug 2010 14:43:05 +0900
> 
> Eli Zaretskii writes:
> 
>  > Thanks.  However, what you wrote just shows once again that we are
>  > talking on two very different levels.  Your "user" is actually a
>  > hacker who wants to know and understand a lot about low-level
>  > details of the tool's operation.
> 
> No.  I'm saying that the project needs a few users who understand at
> that level, and that therefore it is important to have such a model.

This is the first time this particular issue comes up.  Until now, the
views with which I was arguing seemed to tell that _any_ user needs
such an understanding to use a dVCS safely and efficiently.

> I apologize for not making it clear that I do understand that average
> users can do fine without deep understanding (but with competent
> guidance).

That's okay, at least we are now in partial agreement.  Not sure
others agree, though.

> My main point is that somebody like you who has intervened in the
> process of recommending workflows really should have a good model.

Maybe.  I simply don't yet have enough experience to make my own
opinion.  Neither does Emacs as a project, I think.  So I will take
your word for it, for now.

>  > quite efficiently (no thanks to bzr docs), without having a
>  > slightest idea how it represents the history DAG or what are all
>  > those files in the .bzr subdirectories of my repository.
> 
> Er, Eli, I didn't mention any of those files (or their analogs in
> git), and I don't recall the docs I pointed to describing them,
> although it did mention their existence.

The docs you pointed to do describe them.  This page, for example:

  http://book.git-scm.com/1_git_directory_and_working_directory.html

>  > Contrary to what you say, these are, IMO, private data, not public
>  > data; for example, if bzr changes its repository format, I as a
>  > user don't care as long as there's a simple way of upgrading to the
>  > new format.
> 
> But the point is that often there isn't a simple way.  In fact, on one
> of my platforms I'm currently stuck without a usable bzr because
> Ubuntu Jaunty provides bzr 1.13, and that doesn't do format 2a, which
> is required for Launchpad.  Upgrading Ubuntu is not an easy option for
> me, either.

Well, when things get broken, you need a technician to fix them.  Most
users aren't technicians.  Projects shouldn't choose tools that become
broken or could break the project to the degree that most users
couldn't fix without calling a technician.

Re: base

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Well, when things get broken, you need a technician to fix them.  Most
> users aren't technicians.  Projects shouldn't choose tools that become
> broken or could break the project to the degree that most users
> couldn't fix without calling a technician.

The real problem are tools that can break the project to the degree that
it becomes scary to impossible to fix even for technicians.

One thing I like about git is that you can always literally do

git reset --hard '@{one hour ago}'

As long as you have not pushed anything.  But why would you when things
go horribly wrong?

-- 
David Kastrup

Re: base

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> No.  I'm saying that the project needs a few users who understand at
>> that level, and that therefore it is important to have such a model.
>
> This is the first time this particular issue comes up.  Until now, the
> views with which I was arguing seemed to tell that _any_ user needs
> such an understanding to use a dVCS safely and efficiently.

I said two or more times on this thread that a deep understanding isn't
necessary for an effective use (define "effective"= at least as
productive as with subversion.)

[snip]

Re: base

[Leo]

On 2010-08-25 01:19 +0100, Miles Bader wrote:
> I think it's related to bzr being inconsistent, complicated, and
> confusing, with no simple mental model for users to latch onto, and
> multiple operating modes poorly stitched together (it's not really
> clear what bzr wants to be; sometimes it seems like its trying to be
> everything at once -- and, predictably, failing at all as a result).

The UI issue is pretty much a thing of the past. Linus himself said it
in 2007 and as it stands today, the UI is as good, if not better, as any
other tools.

I personally spent 25 minutes including watching a 20-minute video to
learn and use git including: the index, rewrite history, rebase, create
and merge branch, tagging in addition to traditional operations. This is
possible thanks to the excellent video:

  http://alexvollmer.com/posts/2009/01/18/meet-magit/ (20m)

Leo

Re: base

[Juanma Barranquero]

On Wed, Aug 25, 2010 at 09:38, Leo <sdl.web@gmail.com> wrote:

> This is possible thanks to the excellent video:

A video is not documentation. Many people reads english far better
than they understand it spoken.

    Juanma

Re: base

[Teemu Likonen]

* 2010-08-25 09:41 (+0200), Juanma Barranquero wrote:

> On Wed, Aug 25, 2010 at 09:38, Leo <sdl.web@gmail.com> wrote:
>> This is possible thanks to the excellent video:
>
> A video is not documentation. Many people reads english far better
> than they understand it spoken.

I'm not sure what is the problem here but if you are looking for a
written English tutorial about Git it's certainly available. Here, for
example, online and printed copy:

    http://progit.org/book/

Git's own web page has an online documentation too:

    http://book.git-scm.com/

I learned using Git without reading either of them but they seem nice
and simple tutorials for everybody.

Re: base

[Uday S Reddy]

On 8/25/2010 1:19 AM, Miles Bader wrote:

> I think it's related to bzr being inconsistent, complicated, and
> confusing, with no simple mental model for users to latch onto, and
> multiple operating modes poorly stitched together (it's not really clear
> what bzr wants to be; sometimes it seems like its trying to be
> everything at once -- and, predictably, failing at all as a result).

The criticism is understandable, but I don't think it is true.

I think simplicity was a key design goal of Bazaar.  The attitude is that you 
don't have to understand how everything works.  Just use these basic commands 
and we will take care of making it all work.  That explains why the 
documentation is so meager.  It also explains why they are so opposed to adding 
things like rebase, which require the users to have a deeper understanding of 
the process to use them correctly.

My feeling is that Bazaar is mostly successful in delivering that simplicity. 
As a software guy, I can admire that.  But also, as a software guy, I really 
want to know what is going on.  That is where the problem is.  I can't be sure, 
but the problem could probably be solved by somebody writing down a more 
in-depth manual of Bazaar.

But I haven't seen any evidence that Bazaar is bad software.  If I think that 
something should be possible and try it, either it gets rejected or it just 
works.  I learn something along the way.  There is a place for software like 
that in the bigger scheme of things.

Cheers,
Uday

Re: base

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> I thought git was a shoo-in for this crowd (except maybe Eli because
> of the Windows issues), but the UI badmouthing kept the discussion
> going long enough for other candidates to get serious consideration.

I dunno, but I think it's pretty likely git would have been adopted if
Richard hadn't put his foot down.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: base

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> I should have added "in some circles, especially newbies."  But not
> just them; a couple of Python programmers I respect a lot made
> comments like "git command lines look like perl code" (which may not
> bother you but it's a low blow on Python lists).

I take it they'd like something with significant whitespace...

-Miles

-- 
Philosophy, n. A route of many roads leading from nowhere to nothing.