Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/05/2015 03:43 PM, Richard M. Stallman wrote:
> branch: master
> commit 4e23cd0ccde4ad1e14fe2870ccf140487af649b2
> Merge: dca743f 16eec6f
> Author: Richard Stallman <rms@gnu.org>
> Commit: Richard Stallman <rms@gnu.org>
>
>             * mail/rmail.el (rmail-show-message-1): When displaying a mime message,
>             indicate start and finish in the echo area.
>
>             * mail/rmail.el (rmail-epa-decrypt): Disregard <pre> before armor.
>             Ignore more kinds of whitespace in mime headers.
>             Modify the decrypted mime part's mime type so it will be displayed
>             by default when visiting this message again.
>
>             * net/browse-url.el (browse-url-firefox-program): Prefer IceCat, doc.
>             (browse-url-firefox-arguments)
>             (browse-url-firefox-startup-arguments): Doc fix.

Well, this looks bad. It's a merge commit, with a crapload of changes 
(which is, by itself, to be expected), but the message makes it look 
like a normal commit, and enumerates the changes that are not, in fact, 
included in it.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 15:56:30 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 04/05/2015 03:43 PM, Richard M. Stallman wrote:
> > branch: master
> > commit 4e23cd0ccde4ad1e14fe2870ccf140487af649b2
> > Merge: dca743f 16eec6f
> > Author: Richard Stallman <rms@gnu.org>
> > Commit: Richard Stallman <rms@gnu.org>
> >
> >             * mail/rmail.el (rmail-show-message-1): When displaying a mime message,
> >             indicate start and finish in the echo area.
> >
> >             * mail/rmail.el (rmail-epa-decrypt): Disregard <pre> before armor.
> >             Ignore more kinds of whitespace in mime headers.
> >             Modify the decrypted mime part's mime type so it will be displayed
> >             by default when visiting this message again.
> >
> >             * net/browse-url.el (browse-url-firefox-program): Prefer IceCat, doc.
> >             (browse-url-firefox-arguments)
> >             (browse-url-firefox-startup-arguments): Doc fix.
> 
> Well, this looks bad. It's a merge commit, with a crapload of changes 
> (which is, by itself, to be expected), but the message makes it look 
> like a normal commit, and enumerates the changes that are not, in fact, 
> included in it.

Any constructive suggestions?

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/05/2015 04:08 PM, Eli Zaretskii wrote:

> Any constructive suggestions?

1) Forget the "push automatically after commit" nonsense, and 
double-check each commit one creates before pushing.

2) People who don't know how to do that, and are unwilling to learn, or 
who aren't confident in their results anyway should post patches to the 
mailing list.

Had Richard started with that, a lot of time would've been saved, on 
many ends.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 16:16:13 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/05/2015 04:08 PM, Eli Zaretskii wrote:
> 
> > Any constructive suggestions?
> 
> 1) Forget the "push automatically after commit" nonsense

The discussion is waaaay beyond that, so this is no longer relevant.

> and double-check each commit one creates before pushing.

Agreed (and now mentioned on the Wiki).  But again, not very relevant
to the issue at hand, which had to do with user confusion more than
with anything else.

And if we think double-checking each commit before pushing is a must,
we should make VC support that seamlessly.  After all, all Richard
used was VC.

> 2) People who don't know how to do that, and are unwilling to learn, or 
> who aren't confident in their results anyway should post patches to the 
> mailing list.

I disagree.  We should let people who want to use a CVS-like workflow
do that.  It's possible if done correctly.  The previous instructions
for that were sub-optimal, but I think they are now much more clear,
accurate, and concise to allow using that workflow safely.

I see no reasons for being this harsh just because some contributors
don't yet master Git enough to use it like we think they should.

> Had Richard started with that, a lot of time would've been saved, on 
> many ends.

Time spent helping someone is time well spent, at least as long as
it's my time.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/05/2015 06:43 PM, Eli Zaretskii wrote:

 >> 1) Forget the "push automatically after commit" nonsense
>
> The discussion is waaaay beyond that, so this is no longer relevant.

That's not my impression from the last sentence in 
http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00156.html

> not very relevant
> to the issue at hand, which had to do with user confusion more than
> with anything else.

Hence the item 2 below.

> And if we think double-checking each commit before pushing is a must,
> we should make VC support that seamlessly.  After all, all Richard
> used was VC.

We can come up with a more automatic solution, but even now it's 
entirely doable using VC: `C-x v L' to open the log buffer, and when in 
it, `C-m' to read the commit message, `d' to see the corresponding diff.

Editing the already-created commits is more complicated, but I think 
there was some advice on that subject too, in the humongous thread.

>> 2) People who don't know how to do that, and are unwilling to learn, or
>> who aren't confident in their results anyway should post patches to the
>> mailing list.
>
> I disagree.  We should let people who want to use a CVS-like workflow
> do that.  It's possible if done correctly.

I'm not saying it's not possible, but a wrong commit message is extra 
work for someone else who will have to correct it. It'll become more so 
when the change log files are auto-generated.

> The previous instructions
> for that were sub-optimal, but I think they are now much more clear,
> accurate, and concise to allow using that workflow safely.

It's better, but I think recommending `git diff origin/master' as the 
first option is suboptimal, because it ignores the commit messages, 
which we do want to look right.

> I see no reasons for being this harsh just because some contributors
> don't yet master Git enough to use it like we think they should.

The workflow details aside, I think a committer should be motivated 
enough to examine the result of their work before pushing. And if they 
don't know how, learn that on their own.

But not everyone has to be an Emacs committer. That's not harsh: people 
can have better priorities in life.

>> Had Richard started with that, a lot of time would've been saved, on
>> many ends.
>
> Time spent helping someone is time well spent, at least as long as
> it's my time.

Cue the "teach a man how to fish" proverb. It seems to me that the 
result is only one fish on Richard's table, and one that was pretty 
haphazardly prepared.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 22:47:05 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/05/2015 06:43 PM, Eli Zaretskii wrote:
> 
>  >> 1) Forget the "push automatically after commit" nonsense
> >
> > The discussion is waaaay beyond that, so this is no longer relevant.
> 
> That's not my impression from the last sentence in 
> http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00156.html

Wrong impression.

> > not very relevant
> > to the issue at hand, which had to do with user confusion more than
> > with anything else.
> 
> Hence the item 2 below.

That item is a dead end in practice, and is too harsh even if it were
practical.

> > And if we think double-checking each commit before pushing is a must,
> > we should make VC support that seamlessly.  After all, all Richard
> > used was VC.
> 
> We can come up with a more automatic solution, but even now it's 
> entirely doable using VC: `C-x v L' to open the log buffer, and when in 
> it, `C-m' to read the commit message, `d' to see the corresponding diff.

You are missing the point: I meant "C-x v v", not some other command
available with VC.  It's "C-x v v" that got Richard in trouble in the
first place, by trying to commit a single file in the middle of a
failed merge.

> Editing the already-created commits is more complicated, but I think 
> there was some advice on that subject too, in the humongous thread.

It's also on the Wiki.

> >> 2) People who don't know how to do that, and are unwilling to learn, or
> >> who aren't confident in their results anyway should post patches to the
> >> mailing list.
> >
> > I disagree.  We should let people who want to use a CVS-like workflow
> > do that.  It's possible if done correctly.
> 
> I'm not saying it's not possible, but a wrong commit message is extra 
> work for someone else who will have to correct it. It'll become more so 
> when the change log files are auto-generated.

Which is why it is important to help those users find the right
procedures they can safely follow.

> > The previous instructions
> > for that were sub-optimal, but I think they are now much more clear,
> > accurate, and concise to allow using that workflow safely.
> 
> It's better, but I think recommending `git diff origin/master' as the 
> first option is suboptimal, because it ignores the commit messages, 
> which we do want to look right.

I don't mind switching the order.  I myself use "git show".  It's just
that most others suggested "git diff", and its syntax is a bit simpler
when more than one commit is involved.

> > I see no reasons for being this harsh just because some contributors
> > don't yet master Git enough to use it like we think they should.
> 
> The workflow details aside, I think a committer should be motivated 
> enough to examine the result of their work before pushing. And if they 
> don't know how, learn that on their own.

I don't think there's lack of motivation in this case.

> But not everyone has to be an Emacs committer. That's not harsh: people 
> can have better priorities in life.

Applied to veteran Emacs developers, it _is_ harsh, at least IMO.

> >> Had Richard started with that, a lot of time would've been saved, on
> >> many ends.
> >
> > Time spent helping someone is time well spent, at least as long as
> > it's my time.
> 
> Cue the "teach a man how to fish" proverb. It seems to me that the 
> result is only one fish on Richard's table, and one that was pretty 
> haphazardly prepared.

We all need help from time to time.  I see no reason to tell people
they goofed too many times, especially if they already know that.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/05/2015 11:07 PM, Eli Zaretskii wrote:

> Wrong impression.

Okay then.

> That item is a dead end in practice, and is too harsh even if it were
> practical.

I think it was one of the discussed options. And why a dead end? I'm 
sure we can handle applying 4-5 patches a year from RMS manually.

> You are missing the point: I meant "C-x v v", not some other command
> available with VC.  It's "C-x v v" that got Richard in trouble in the
> first place, by trying to commit a single file in the middle of a
> failed merge.

And I meant that an automated solution would be great to have, but it's 
the responsibility of every committer to pay attention and not mess up.

I think that should be pretty obvious.

>> Editing the already-created commits is more complicated, but I think
>> there was some advice on that subject too, in the humongous thread.
>
> It's also on the Wiki.

"If you made a mistake"? That only helps when we need to change the most 
recent commit. Which is good, but probably not enough.

> Which is why it is important to help those users find the right
> procedures they can safely follow.

Having better instructions will, of course, be a beneficial side of this 
whole enterprise.

> I don't mind switching the order.  I myself use "git show".  It's just
> that most others suggested "git diff", and its syntax is a bit simpler
> when more than one commit is involved.

I think the committer had probably already tested the installed changes 
for functionality. So the thing that's most often in need of checking is 
writing: comments, docs and commit messages.

> I don't think there's lack of motivation in this case.

In my book, "I want everything to work like CVS" means a lack of 
motivation to learn.

>> But not everyone has to be an Emacs committer. That's not harsh: people
>> can have better priorities in life.
>
> Applied to veteran Emacs developers, it _is_ harsh, at least IMO.

Maybe to any other veteran, but since Richard holds the "master key" 
anyway, that wouldn't be like locking him out of the project.

Considering the mega-thread is clocking at 505 messages now, would it 
really not have been a better solution?

>> Cue the "teach a man how to fish" proverb. It seems to me that the
>> result is only one fish on Richard's table, and one that was pretty
>> haphazardly prepared.
>
> We all need help from time to time.  I see no reason to tell people
> they goofed too many times, especially if they already know that.

"Haphazardly prepared" by other people, of course, because there's 
really no possible way to reliably get instructions from this large a 
crowd, all shouting at the same time.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 01:32:49 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/05/2015 11:07 PM, Eli Zaretskii wrote:
> 
> > Wrong impression.
> 
> Okay then.
> 
> > That item is a dead end in practice, and is too harsh even if it were
> > practical.
> 
> I think it was one of the discussed options. And why a dead end?

Because Richard explicitly said he didn't want that.

> > You are missing the point: I meant "C-x v v", not some other command
> > available with VC.  It's "C-x v v" that got Richard in trouble in the
> > first place, by trying to commit a single file in the middle of a
> > failed merge.
> 
> And I meant that an automated solution would be great to have, but it's 
> the responsibility of every committer to pay attention and not mess up.

Newbies often do mess up.  Emacs should try to keep them out of
trouble as much as practically possible.  E.g., we have the "disabled
command" feature that we use for risky commands, for a similar
purpose.

> >> Editing the already-created commits is more complicated, but I think
> >> there was some advice on that subject too, in the humongous thread.
> >
> > It's also on the Wiki.
> 
> "If you made a mistake"? That only helps when we need to change the most 
> recent commit. Which is good, but probably not enough.

Then please tell what you had in mind, perhaps it would be good to
have that added.

> > I don't think there's lack of motivation in this case.
> 
> In my book, "I want everything to work like CVS" means a lack of 
> motivation to learn.

In my book it's an understandable position of a busy person who wants
a simple job of making an upstream change to "just work".  Such people
_will_ learn with good help, but much slower.

GitQuickStartForEmacsDevs was written with these people in mind.

> >> But not everyone has to be an Emacs committer. That's not harsh: people
> >> can have better priorities in life.
> >
> > Applied to veteran Emacs developers, it _is_ harsh, at least IMO.
> 
> Maybe to any other veteran, but since Richard holds the "master key" 
> anyway, that wouldn't be like locking him out of the project.

I think you fail to understand how humiliating that would be.  That's
okay, let's talk in, say, 30 years, and see where you stand then ;-)

> Considering the mega-thread is clocking at 505 messages now, would it 
> really not have been a better solution?

No, not really.  Not IMO, anyway.

> >> Cue the "teach a man how to fish" proverb. It seems to me that the
> >> result is only one fish on Richard's table, and one that was pretty
> >> haphazardly prepared.
> >
> > We all need help from time to time.  I see no reason to tell people
> > they goofed too many times, especially if they already know that.
> 
> "Haphazardly prepared" by other people, of course, because there's 
> really no possible way to reliably get instructions from this large a 
> crowd, all shouting at the same time.

When someone is in grave trouble, what do you expect?  He can be
taught fishing after he's out of trouble, but not before.  You don't
start teaching people how to avoid a fire before putting the fire out.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/06/2015 10:54 AM, Eli Zaretskii wrote:

> Then please tell what you had in mind, perhaps it would be good to
> have that added.

I use 'git rebase -i' for that. Not sure if we actually want to mention 
rebasing in the instructions.

But if not, should they recommend reviewing each commit right away after 
it's made?

> In my book it's an understandable position of a busy person who wants
> a simple job of making an upstream change to "just work".  Such people
> _will_ learn with good help, but much slower.

Well, here's hoping. IME, Git is better learned from fundamentals, but 
hopefully these careful instructions will make it easier for people to 
ignore the former, without major consequences.

> I think you fail to understand how humiliating that would be.  That's
> okay, let's talk in, say, 30 years, and see where you stand then ;-)

I'd call that delegating, and I'm sure many people would be okay with 
it. But of course, if there's a similar motivated individual 30 years 
from now to write a new guide, that would be great too.

> When someone is in grave trouble, what do you expect?  He can be
> taught fishing after he's out of trouble, but not before.  You don't
> start teaching people how to avoid a fire before putting the fire out.

Being hungry is the best motivation to learn fishing. And as we know 
now, his situation was fairly normal: a history containing two normal 
local commits and lagging behind the remote master otherwise.

So what was needed is a pull, a merge resolving the conflicts, and then 
a push. The situation was complicated by the need to resolve ChangeLog 
conflicts manually (or else there may have been no conflicts at all), 
which is something that was a problem for me as well after Emacs's 
transition to Git. While I know how to merge, it wasn't obvious how 
exactly those kind of conflicts should be resolved, which ordering to 
use, dates, etc. And it's annoying to have to do it each time manually.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 15:03:23 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/06/2015 10:54 AM, Eli Zaretskii wrote:
> 
> > Then please tell what you had in mind, perhaps it would be good to
> > have that added.
> 
> I use 'git rebase -i' for that. Not sure if we actually want to mention 
> rebasing in the instructions.

That's exactly the issue: should we mention such techniques on that
page?

> But if not, should they recommend reviewing each commit right away after 
> it's made?

Probably a good idea, thanks.

> So what was needed is a pull, a merge resolving the conflicts, and then 
> a push. The situation was complicated by the need to resolve ChangeLog 
> conflicts manually (or else there may have been no conflicts at all), 
> which is something that was a problem for me as well after Emacs's 
> transition to Git. While I know how to merge, it wasn't obvious how 
> exactly those kind of conflicts should be resolved, which ordering to 
> use, dates, etc. And it's annoying to have to do it each time manually.

I hope the instructions in their current form explain all that well
enough.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/06/2015 03:24 PM, Eli Zaretskii wrote:

 > That's exactly the issue: should we mention such techniques on that
> page?

Hard to say. But 'git commit --amend' is already a dangerous operation. 
Someone might forget that the current commit has already been pushed, 
and amend it anyway. What will they do then?

Try to push the result, see a message about non-fast-forward pushes 
being not allowed, then go along the "If pushing fails" section (pull, 
resolve, commit, push), and we'll have two similar commits in the history.

I don't really know how to proof the instructions against that.

>> So what was needed is a pull, a merge resolving the conflicts, and then
>> a push. The situation was complicated by the need to resolve ChangeLog
>> conflicts manually (or else there may have been no conflicts at all),
>> which is something that was a problem for me as well after Emacs's
>> transition to Git. While I know how to merge, it wasn't obvious how
>> exactly those kind of conflicts should be resolved, which ordering to
>> use, dates, etc. And it's annoying to have to do it each time manually.
>
> I hope the instructions in their current form explain all that well
> enough.

They don't explain how to merge ChangeLogs, and the specialized merge 
driver is only mentioned in GitForEmacsDevs. Well, we should have no 
need for it soon.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 07 Apr 2015 02:32:43 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> On 04/06/2015 03:24 PM, Eli Zaretskii wrote:
> 
>  > That's exactly the issue: should we mention such techniques on that
> > page?
> 
> Hard to say. But 'git commit --amend' is already a dangerous operation. 
> Someone might forget that the current commit has already been pushed, 
> and amend it anyway. What will they do then?
> 
> Try to push the result, see a message about non-fast-forward pushes 
> being not allowed, then go along the "If pushing fails" section (pull, 
> resolve, commit, push), and we'll have two similar commits in the history.
> 
> I don't really know how to proof the instructions against that.

Neither do I, so I guess they will ask here.

> >> So what was needed is a pull, a merge resolving the conflicts, and then
> >> a push. The situation was complicated by the need to resolve ChangeLog
> >> conflicts manually (or else there may have been no conflicts at all),
> >> which is something that was a problem for me as well after Emacs's
> >> transition to Git. While I know how to merge, it wasn't obvious how
> >> exactly those kind of conflicts should be resolved, which ordering to
> >> use, dates, etc. And it's annoying to have to do it each time manually.
> >
> > I hope the instructions in their current form explain all that well
> > enough.
> 
> They don't explain how to merge ChangeLogs, and the specialized merge 
> driver is only mentioned in GitForEmacsDevs. Well, we should have no 
> need for it soon.

Indeed, and that's why I didn't add that to the instructions.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > In my book, "I want everything to work like CVS" means a lack of 
  > > motivation to learn.

Why should I have a "motivation to learn" so much about using git?
I am not learning it our of curiosity!

You make an analogy of fishing.  Suppose you are a teacher, and
a government imposes the rule that every teacher must catch a fish
each day in order to be allowed to teach that day.  Do you want
to learn to fish, or do you want the rule cancelled?

Development tools are supposed to make our work easier -- not harder.
For me, Git means many hurdles to jump in order to do the things that
were easy before.

Also, I do this infrequently enough that I will have time to forget
whatever I learn now.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 07 Apr 2015 12:13:46 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dgutov@yandex.ru, emacs-devel@gnu.org
> 
> Also, I do this infrequently enough that I will have time to forget
> whatever I learn now.

To countermand this problem, I have a git-notes.txt file that is
constantly loaded into my Emacs session, where I keep notes about
commands required to perform certain tasks.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Richard.

On Tue, Apr 07, 2015 at 12:13:46PM -0400, Richard Stallman wrote:
>   > > In my book, "I want everything to work like CVS" means a lack of 
>   > > motivation to learn.

> Why should I have a "motivation to learn" so much about using git?
> I am not learning it our of curiosity!

> You make an analogy of fishing.  Suppose you are a teacher, and
> a government imposes the rule that every teacher must catch a fish
> each day in order to be allowed to teach that day.  Do you want
> to learn to fish, or do you want the rule cancelled?

> Development tools are supposed to make our work easier -- not harder.
> For me, Git means many hurdles to jump in order to do the things that
> were easy before.

For what it's worth, I agree with you here on all the points you make.

> Also, I do this infrequently enough that I will have time to forget
> whatever I learn now.

I have had the good fortune/misfortune of having to learn this tool to a
minimum level of competence to be able to contribute to Emacs at all.
This cost me many, many hours I would rather have spent doing other
things.  I'm committing often enough not to forget between commits - for
the moment, at any rate.

Git is a monster to learn, taking an order of magnitude longer than to
learn Mercurial or Bazaar, and a greater jump still from learning CVS.

I would prefer just to be a user of a VCS.  With most VCSs, this is
possible.  With git, it is not; one has to know a good deal of its
internal workings to use it at all.

However, a lot of people like git, possibly for reasons similar to the
ones why we dislike it.  As a project we're stuck with it for the
foreseeable future.  :-(

> -- 
> Dr Richard Stallman

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 7 Apr 2015 16:51:31 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > Development tools are supposed to make our work easier -- not harder.
> > For me, Git means many hurdles to jump in order to do the things that
> > were easy before.
> 
> For what it's worth, I agree with you here on all the points you make.
> 
> > Also, I do this infrequently enough that I will have time to forget
> > whatever I learn now.
> 
> I have had the good fortune/misfortune of having to learn this tool to a
> minimum level of competence to be able to contribute to Emacs at all.
> This cost me many, many hours I would rather have spent doing other
> things.  I'm committing often enough not to forget between commits - for
> the moment, at any rate.
> 
> Git is a monster to learn, taking an order of magnitude longer than to
> learn Mercurial or Bazaar, and a greater jump still from learning CVS.
> 
> I would prefer just to be a user of a VCS.  With most VCSs, this is
> possible.  With git, it is not; one has to know a good deal of its
> internal workings to use it at all.

Alan, if you have a few moments to spare, could you read
GitQuickStartForEmacsDevs and see if the current procedures there
appeal to you (or maybe even tell you something useful you didn't
already know)?  Your comments will be appreciated.

TIA

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Eli.

On Tue, Apr 07, 2015 at 08:12:52PM +0300, Eli Zaretskii wrote:
> Alan, if you have a few moments to spare, could you read
> GitQuickStartForEmacsDevs and see if the current procedures there
> appeal to you (or maybe even tell you something useful you didn't
> already know)?  Your comments will be appreciated.

> TIA

First impression (though I have glanced at it quite a few times in
passing): it's a good simple intro to git.

Small point: one of the examples commits a ChangeLog, which as from
today, we don't do any more.

Bigger point: the workflow depicted implicitly assumes that _all_
changes made to files are to be committed in one commit action.  I think
it would be better if this was stated explicitly, with a sentence like
"The following commands assume _all_ the changes you have made to any
files will be committed together." immediately under the heading "Daily
Work".  I would naturally prefer the commands only to commit specified
files (I work this way), but I can appreciate not wanting the guide to
get complicated.

I actually use git stash rather than commits with messages like "Commit
to allow pull from upstream."; I find it the lesser of two evils - I
don't think one should have to commit unnaturally because of constraints
in the tools.  I think the sub-workflow git stash; git pull; git stash
pop might be worth mentioning.

It might be useful to mention "git checkout foo.el" as doing what we
used to know as "bzr revert foo.el", perhaps under the "If you made a
mistake" section.  I remember I had to ask for this command on
emacs-devel, once.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 7 Apr 2015 20:11:14 +0000
> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Small point: one of the examples commits a ChangeLog, which as from
> today, we don't do any more.

Fixed.

> Bigger point: the workflow depicted implicitly assumes that _all_
> changes made to files are to be committed in one commit action.  I think
> it would be better if this was stated explicitly, with a sentence like
> "The following commands assume _all_ the changes you have made to any
> files will be committed together." immediately under the heading "Daily
> Work".

Added a note to that effect.

> I actually use git stash rather than commits with messages like "Commit
> to allow pull from upstream."; I find it the lesser of two evils - I
> don't think one should have to commit unnaturally because of constraints
> in the tools.  I think the sub-workflow git stash; git pull; git stash
> pop might be worth mentioning.

Added.

> It might be useful to mention "git checkout foo.el" as doing what we
> used to know as "bzr revert foo.el", perhaps under the "If you made a
> mistake" section.  I remember I had to ask for this command on
> emacs-devel, once.

Done.

Thanks.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/07/2015 07:51 PM, Alan Mackenzie wrote:

> Git is a monster to learn, taking an order of magnitude longer than to
> learn Mercurial or Bazaar, and a greater jump still from learning CVS.

When trying to use Bazaar, I've consistently been put off by the lack of 
transparency of its data model. Or at least that was the feeling.

> However, a lot of people like git, possibly for reasons similar to the
> ones why we dislike it.

That's possible. And like mentioned by Andreas, maybe also for the 
similar reasons some people (e.g. myself) like Emacs.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Dmitry.

On Wed, Apr 08, 2015 at 04:38:44AM +0300, Dmitry Gutov wrote:
> On 04/07/2015 07:51 PM, Alan Mackenzie wrote:

> > Git is a monster to learn, taking an order of magnitude longer than to
> > learn Mercurial or Bazaar, and a greater jump still from learning CVS.

> When trying to use Bazaar, I've consistently been put off by the lack of 
> transparency of its data model. Or at least that was the feeling.

I'm not quite sure what you mean by "data model", but my feeling was
similar, combined with the feeling it didn't matter that much - most
things just worked.

> > However, a lot of people like git, possibly for reasons similar to the
> > ones why we dislike it.

> That's possible. And like mentioned by Andreas, maybe also for the 
> similar reasons some people (e.g. myself) like Emacs.

I don't think think that's a valid comparison.  In Emacs, you chose what
level of complexity you work at, and you can learn it gradually.  At a
basic level, you can work Emacs with self-insert keys, arrow keys, and
six or seven essential commands (C-g, C-x C-f, C-x C-s, C-x C-c, C-/, and
one or two others).  All these commands are "simple", in the sense they
don't require you to specify obscure options, or anything like that.

In git, the complexity seems gratuitous - the user is exposed to the
maximum level of detail possible rather than the minimum required to use
it productively.  This can be seen by comparing it with Mercurial, which
has the same level of capability explained in a single man page of
~300kB, compared with git's man pages of over 2MB.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[chad]

> On 08 Apr 2015, at 03:48, Alan Mackenzie <acm@muc.de> wrote:
> 
> In Emacs, you chose what
> level of complexity you work at, and you can learn it gradually.

I have a friend whos helping teach programming to kids (~15 years
old) without any previous programming experience. They teach the
kids python, emacs, and git (and they work in teams). From what I
hear, the students pick up git more quickly and more easily than
they do emacs.

I say this not to discredit anyones experience, but instead to point
out that there are many people who have a very different experience.

~Chad

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > From what I
  > hear, the students pick up git more quickly and more easily than
  > they do emacs.

I am disappointed that they don't find Emacs easy to learn,
but that's not the same question we were discussing.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/08/2015 01:48 PM, Alan Mackenzie wrote:

> I don't think think that's a valid comparison.  In Emacs, you chose what
> level of complexity you work at, and you can learn it gradually.  At a
> basic level, you can work Emacs with self-insert keys, arrow keys, and
> six or seven essential commands (C-g, C-x C-f, C-x C-s, C-x C-c, C-/, and
> one or two others).  All these commands are "simple", in the sense they
> don't require you to specify obscure options, or anything like that.

There's nothing interesting in Emacs on that level. I certainly wouldn't 
have been as productive in it as I am now if I stopped at it.

If you like, make an analogy to only working in a local Git repository, 
and only in one branch. It's easy, even somewhat useful, but not what 
most people do.

> In git, the complexity seems gratuitous - the user is exposed to the
> maximum level of detail possible rather than the minimum required to use
> it productively.

"Maximum" is an exaggeration. You don't have to know *that* much. And 
even being somewhat experienced in using Git, I only have a very vague 
understanding of its merge strategies. And that's an important area: 
Git's original goals included easy merging.

> This can be seen by comparing it with Mercurial, which
> has the same level of capability explained in a single man page of
> ~300kB, compared with git's man pages of over 2MB.

IIUC, Mercurial doesn't have lightweight branching. It now offers 
several branching options, and none of them is exactly analogous to 
Git's straightforward model. I mean, talk about simplicity:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 04:16:29 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> On 04/08/2015 01:48 PM, Alan Mackenzie wrote:
> 
> > I don't think think that's a valid comparison.  In Emacs, you chose what
> > level of complexity you work at, and you can learn it gradually.  At a
> > basic level, you can work Emacs with self-insert keys, arrow keys, and
> > six or seven essential commands (C-g, C-x C-f, C-x C-s, C-x C-c, C-/, and
> > one or two others).  All these commands are "simple", in the sense they
> > don't require you to specify obscure options, or anything like that.
> 
> There's nothing interesting in Emacs on that level.

There's no requirement for a tool to be "interesting", only to be
useful, and let one do their job.

> I certainly wouldn't have been as productive in it as I am now if I
> stopped at it.

There's no requirement to be more productive with Git beyond being
able to push changes.

> If you like, make an analogy to only working in a local Git repository, 
> and only in one branch. It's easy, even somewhat useful, but not what 
> most people do.

No, Git isn't useful that way.  Emacs, by contrast, is a useful text
editor even if you use the most basic commands and cursor motion keys.

> > In git, the complexity seems gratuitous - the user is exposed to the
> > maximum level of detail possible rather than the minimum required to use
> > it productively.
> 
> "Maximum" is an exaggeration.

Yes, it is.  But you have to admit that Git requires a newbie to learn
quite a lot -- new terminology, several new commands, and new
procedures -- as a _prerequisite_ for being able to work in a single
remote-tracking branch.  And this is the core problem here.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/09/2015 10:27 AM, Eli Zaretskii wrote:

> There's no requirement for a tool to be "interesting", only to be
> useful, and let one do their job.

It wouldn't be adequate for my job, no.

> No, Git isn't useful that way.  Emacs, by contrast, is a useful text
> editor even if you use the most basic commands and cursor motion keys.

It *is* useful: it saves the changes, allows to undo the local 
uncommitted changes, and even to revert to earlier versions, if the user 
learns how.

One could even share the directory over the network, and people could 
take turns working on the project.

> But you have to admit that Git requires a newbie to learn
> quite a lot -- new terminology, several new commands, and new
> procedures -- as a _prerequisite_ for being able to work in a single
> remote-tracking branch.  And this is the core problem here.

Maybe so, but not an order of magnitude more than if we used something 
comparable like Mercurial. It's just the price of using an advanced tool.

Contributing to Emacs asks a person to learn different things, some of 
them fairly niche, but Git skills will easily transfer to other projects.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 15:20:07 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: acm@muc.de, rms@gnu.org, emacs-devel@gnu.org
> 
> > But you have to admit that Git requires a newbie to learn
> > quite a lot -- new terminology, several new commands, and new
> > procedures -- as a _prerequisite_ for being able to work in a single
> > remote-tracking branch.  And this is the core problem here.
> 
> Maybe so, but not an order of magnitude more than if we used something 
> comparable like Mercurial.

I don't know about orders of magnitude, and we didn't try Mercurial.
We did use Bazaar, and Richard never complained like that, AFAIR.

> It's just the price of using an advanced tool.

An advanced tool that insists on exposing too much of its advanced
features for the simplest operation.

> Contributing to Emacs asks a person to learn different things, some of 
> them fairly niche

You forget that there are those among us for whom all of those things
were lessons learned long ago.  Which leaves just Git as the step to
climb.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/09/2015 03:51 PM, Eli Zaretskii wrote:

> I don't know about orders of magnitude, and we didn't try Mercurial.
> We did use Bazaar, and Richard never complained like that, AFAIR.

Someone motivated enough should be able to write something analogous to 
bound branches, in an alternative commit command.

> You forget that there are those among us for whom all of those things
> were lessons learned long ago.  Which leaves just Git as the step to
> climb.

I don't, just offering an alternative viewpoint. Arguably, a more common 
one. And if it's not more common now, wait a few years.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > However, a lot of people like git, possibly for reasons similar to the
  > > ones why we dislike it.

  > That's possible. And like mentioned by Andreas, maybe also for the 
  > similar reasons some people (e.g. myself) like Emacs.

If you love complexity for complexity's sake, Git and Emacs will offer
you plenty.  The difference is, in Emacs you can learn certain
complexity when you find it worth while, and ignore the rest.  In Git
you must learn the complexity to do even the simplest things.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/08/2015 09:19 PM, Richard Stallman wrote:

> If you love complexity for complexity's sake, Git and Emacs will offer
> you plenty.  The difference is, in Emacs you can learn certain
> complexity when you find it worth while, and ignore the rest.  In Git
> you must learn the complexity to do even the simplest things.

Nonsense, nobody loves complexity. I like power and transparency. Git is 
pretty transparent, and one can peer into Emacs's inner workings very 
easily, at least compared to most other advanced editors.

You can ignore Emacs's complexity if you're okay with giving up 
features, but then it becomes inferior in many respects to other, 
"modern" editors, which arguably offer more features on lower levels of 
complexity.

It doesn't have to be this way, but that's where things are at now.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 04:31:08 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
> On 04/08/2015 09:19 PM, Richard Stallman wrote:
> 
> > If you love complexity for complexity's sake, Git and Emacs will offer
> > you plenty.  The difference is, in Emacs you can learn certain
> > complexity when you find it worth while, and ignore the rest.  In Git
> > you must learn the complexity to do even the simplest things.
> 
> Nonsense, nobody loves complexity. I like power and transparency.

You are responding to the irrelevant part of the issue: the 1st
sentence, which in fact says that Git and Emacs are quite similar for
those who love complexity (they are also similar for those who like
power).

The relevant part of the issue is everything beyond the 1st sentence:
it says that with Git you _must_ learn some of the complexity just to
do the simplest things a project member is required to do.

> You can ignore Emacs's complexity if you're okay with giving up 
> features, but then it becomes inferior in many respects to other, 
> "modern" editors, which arguably offer more features on lower levels of 
> complexity.

It is still a useful text editor.  With Git, unless you know how to
resolve pull/push conflicts, you cannot do the simplest thing.  And
that's the difference; I don't understand how you can deny it.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > [Even without Lisp applications, Emacs] is still a useful text
 > editor.  With Git, unless you know how to resolve pull/push
 > conflicts, you cannot do the simplest thing.  And that's the
 > difference; I don't understand how you can deny it.

The only way I can make sense of that comment is that your definition
of "simple" is the activity of highest complexity known to man:
working in large distributed teams, which is the situation that
induces pull/push conflicts.  Emacs provides zero[1] functionality
for handling that that doesn't involve a full "commit" (ie, file
save), and Emacs knows nothing about history *outside* of buffers (the
equivalent of a Git workspace).  Git does almost nothing that isn't
tuned to that level of *external* complexity.

The simplest thing is to use Git like RCS: git commit, git diff,
lather, rinse, repeat.  Even Richard and Alan do that without getting
their shorts in a knot.  But their workflows are very workspace-and-
mainline-centric; they don't see a need for dealing with branches, let
alone the DAG.  They don't want to go beyond the RCS workflow.  DVCS
fans do; branches and DAG manipulations are useful tools for many
development activities and workflows, which Richard and Alan evidently
perform rarely if ever.  Unfortunately for them most of the developing
world has decided that DVCS and DAGs are good things, and they're
finding themselves more and more isolated, even within the Emacs
community.

Granted, Git has a lot of spurious complication (the Git analogs of
`cl-caadar'! this happens when a tool is work-in-progess, as all
useful free software tools are in practice), but the problems Richard
and Alan are encountering are soon solved by those who study a little
bit, and establish some discipline in performing what they've learned.
Richard and Alan, too, could very easily develop and make habitual a
DVCS routine that allows them to continue the same programming
workflow with a little extra typing that happens to differ from
CVS.[2]  Instead they started a flamewar, and Richard has made
explicit that he expects somebody else to do most of the work of
adapting git to his specification.

There's nothing wrong with wanting your tools to be adapted to you, of
course, but if you want to cooperate with others, sometimes you need
to compromise with the shared tools.  Hundreds, maybe thousands, of
developers have been compromising with Richard's fiats about tools
(diff -c, ChangeLogs, Bazaar to name three) for decades.  Of course
such conventions are useful, but which is optimal is a matter of
personal preference and habit, which (shockingly enough) differ from
developer to developer.  Not everybody can have what they want.

Footnotes: 
[1]  I've heard of collaborative editing tools built on Emacs, but
AFAIK it's not a common activity or supported in Emacs itself.  And
AFAIK "agile" has moved away from that, favoring techniques like pair
programming instead.

[2]  Yes, I know that Richard at least finds typing painful.  Of all
people on God's green Earth, Richard should be able to find ways of
abbreviating ritualized typing.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>     acm@muc.de,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Fri, 10 Apr 2015 01:24:04 +0900
> 
> Eli Zaretskii writes:
> 
>  > [Even without Lisp applications, Emacs] is still a useful text
>  > editor.  With Git, unless you know how to resolve pull/push
>  > conflicts, you cannot do the simplest thing.  And that's the
>  > difference; I don't understand how you can deny it.
> 
> The only way I can make sense of that comment is that your definition
> of "simple" is the activity of highest complexity known to man:
> working in large distributed teams, which is the situation that
> induces pull/push conflicts.

IOW, working in any public project these days.  We violently agree.

> The simplest thing is to use Git like RCS: git commit, git diff,
> lather, rinse, repeat.

That'd be a step backward: Emacs switched from RCS to CVS about 25
years ago.

> Even Richard and Alan do that without getting
> their shorts in a knot.  But their workflows are very workspace-and-
> mainline-centric; they don't see a need for dealing with branches, let
> alone the DAG.  They don't want to go beyond the RCS workflow.  DVCS
> fans do; branches and DAG manipulations are useful tools for many
> development activities and workflows, which Richard and Alan evidently
> perform rarely if ever.  Unfortunately for them most of the developing
> world has decided that DVCS and DAGs are good things, and they're
> finding themselves more and more isolated, even within the Emacs
> community.

All true and agreed.  I just tried to show how the resulting
requirements might get in the way of some people.  I think we should
understand their POV, rather than blame them for it and despise it.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > All true and agreed.  I just tried to show how the resulting
 > requirements might get in the way of some people.  I think we
 > should understand their POV, rather than blame them for it and
 > despise it.

It would help if they would do the same, instead of applying terms to
git that they hotly dispute when applied to Emacs.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: acm@muc.de,
>     emacs-devel@gnu.org,
>     rms@gnu.org,
>     dgutov@yandex.ru
> Date: Fri, 10 Apr 2015 13:53:12 +0900
> 
> Eli Zaretskii writes:
> 
>  > All true and agreed.  I just tried to show how the resulting
>  > requirements might get in the way of some people.  I think we
>  > should understand their POV, rather than blame them for it and
>  > despise it.
> 
> It would help if they would do the same, instead of applying terms to
> git that they hotly dispute when applied to Emacs.

Unless your name is "git", you shouldn't take offense.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Unless your name is "git", you shouldn't take offense.

Unfortunately for your reputation for evenhandedness, you neglected to
tell Richard the same when he took offense at having Emacs compared to
git.  I've tried hard (as you should know better than anybody else),
but I've had enough.

See ya.  Maybe.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > but the problems Richard
  > and Alan are encountering are soon solved by those who study a little
  > bit, and establish some discipline in performing what they've learned.

Your tendency to belittle people is showing.

  > There's nothing wrong with wanting your tools to be adapted to you, of
  > course, but if you want to cooperate with others, sometimes you need
  > to compromise with the shared tools.

You have found an excuse to be callous about the trouble this
particular tool causes.  Do I see you gloating about it?  I think so.

  >   Hundreds, maybe thousands, of
  > developers have been compromising with Richard's fiats about tools
  > (diff -c, ChangeLogs, Bazaar to name three) for decades.

I was Emacs maintainer for decades on and off, and I am still head of
the GNU Project.  I did, and I still do, make some decisions.

Which diff format to use for submittinmg Emacs patches is up to the
Emacs maintainer.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Richard Stallman writes:

 >   > but the problems Richard and Alan are encountering are soon
 >   > solved by those who study a little bit, and establish some
 >   > discipline in performing what they've learned.
 > 
 > Your tendency to belittle people is showing.

"Belittle"?  I stated a fact which applies to millions of git users.
I hardly think anybody will think less of you because I stated it!

You and Alan have made a choice to try to continue using a workflow
designed for a different tool, which is more or less incompatible with
git as distributed by its maintainers.  There's nothing wrong with
that if that's what you want to do, but you will experience problems
until either you establish a more adapted discipline, or you modify
your instance of the tool so that it is adapted to you.

I've exerted substantial effort both on- and off-list to suggest more
adapted workflows and to figure out how to implement the workflow I
now understand you to want.  The former is easy, but you rejected that
suggestion, and I found the latter rather difficult and the ideas
about implementation I was able to propose unsatisfying.  I
nevertheless hope my suggestions toward implementing your preferred
workflow will be of some use to you.

 >   > There's nothing wrong with wanting your tools to be adapted to
 >   > you, of course, but if you want to cooperate with others,
 >   > sometimes you need to compromise with the shared tools.
 > 
 > You have found an excuse to be callous about the trouble this
 > particular tool causes.

Tools that behave as designed don't cause trouble of themselves.
Misuse of those tools is what causes trouble.  I understand that you
and others think it is poor design, but I and many others disagree.

 > Do I see you gloating about it?  I think so.

Hardly.  I'm sad.  I'm not interested in seeing you or Alan suffer,
but despite all the Sturm und Drang, I still believe you would be
better off, and Emacs would be better off, if you had spent as much
effort on learning the tool as you have on complaining about the tool
and attributing ill-will to others who only wanted to help you learn
good ways to use the tool.  I'm sorry that we failed to understand
your requirements, but as often happens the people who best understand
the tool are enthusiastic and evangelistic about it.

I'm especially sad because Emacs Lisp taught me most of what I
practically know about working with linked data structures, and I see
many analogies between Lisp's lists and git's DAG that have been very
useful to me in understanding git.  I think it's very unfortunate that
the Emacs project has not been using git and exploiting those
similarities since it was originally decided to move to a DVCS.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Stephen.

Sorry for the delayed reply.  My net connection went down on Thursday
afternoon, and it wasn't fixed until this morning.

On Fri, Apr 10, 2015 at 01:24:04AM +0900, Stephen J. Turnbull wrote:

> The simplest thing is to use Git like RCS: git commit, git diff,
> lather, rinse, repeat.  Even Richard and Alan do that without getting
> their shorts in a knot.  But their workflows are very workspace-and-
> mainline-centric; they don't see a need for dealing with branches, let
> alone the DAG.  They don't want to go beyond the RCS workflow.  DVCS
> fans do; branches and DAG manipulations are useful tools for many
> development activities and workflows, which Richard and Alan evidently
> perform rarely if ever.  Unfortunately for them most of the developing
> world has decided that DVCS and DAGs are good things, and they're
> finding themselves more and more isolated, even within the Emacs
> community.

Speaking purely for myself, this is untrue.  I like DVCSs and the
flexibility they (should) provide.  It is git, with its turgid command
set and options, and over-bloated (> 2MB), unsearchable manual, that I
dislike.  It is its inflexibility with regard to workflow, which you
allude to above.

Just for the record, it was indeed a git pull which erased all changes in
my workspace.  It happened on 2014-12-08, as I was attempting to make my
first commit in git.  I had just performed git add for all changed files,
then did git pull to synchronise with savannah before doing the local
commit.  I still had open buffers in Emacs for all these files, 13 files
in all, which I saved, appending a suffix to each of their names.  It was
some tedious manual work and six days later before I actually pushed that
commit to savannah.

Since that time, whenever I have files in the staging area ready to
commit, and do a git pull, those files end up no longer being in the
staging area.

What a flexible tool git isn't!

> Granted, Git has a lot of spurious complication (the Git analogs of
> `cl-caadar'! this happens when a tool is work-in-progess, as all
> useful free software tools are in practice), ....

That's garbage by association, Stephen.  You're suggesting here that all
useful free software tools share git's over-complication, and that this
is therefore all right.  It's not.  Emacs, for example, was carefully and
masterfully architected from the start, with a clear vision.  git appears
to have been hacked together in a hurry with nobody with any taste in
charge.  As Antoine St. Exupéry is reported to have said, a design is
complete not when there's nothing left to add, but when there's nothing
left to remove.

> ...., but the problems Richard and Alan are encountering are soon
> solved by those who study a little bit, and establish some discipline
> in performing what they've learned.

Excuse me, but that is disparagingly patronising.  I have studied git a
LOT; I was forced to, merely to be able to use it at a most basic level.
Richard simply doesn't have the time (and we're talking about tens of
hours) to invest in getting up to speed with git.  There is no "soon"
about git learning, and the insinuation that I am undisciplined in my
use of VCSs is uncalled for.

> Richard and Alan, too, could very easily develop and make habitual a
> DVCS routine that allows them to continue the same programming workflow
> with a little extra typing that happens to differ from CVS.[2]  Instead
> they started a flamewar, and Richard has made explicit that he expects
> somebody else to do most of the work of adapting git to his
> specification.

Again you're muddying the waters, insinuating that we're both stuck in
the antediluvian CVS past.  Richard and I have both used bzr, relatively
free of problems, and I have used and still use Mercurial, which I like.
DVCSs, generically, are not the problem.

> There's nothing wrong with wanting your tools to be adapted to you, of
> course, but if you want to cooperate with others, sometimes you need
> to compromise with the shared tools.

More insinuations.  Although I have criticised git's many shortcomings,
I have never requested or suggested that other people adapt it to my
liking.  And nobody could fairly accuse me of not compromising with git.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Since that time, whenever I have files in the staging area ready to
 > commit, and do a git pull, those files end up no longer being in the
 > staging area.

I don't understand.  I did

cd /tmp
git clone ~/src/Twitter
cd Twitter
git reset --hard HEAD^
echo foo > foo
git add foo

I expect that if I now pull I will get an up-to-date git repo with foo
ready for commit.  Try it:

Twitter 18:19$ git pull
Updating 64cb97f..f079094
Fast-forward
 stream.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Twitter 18:19$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

  new file:   foo

Twitter 18:19$

How do I reproduce your experience?

 > > ...., but the problems Richard and Alan are encountering are
 > > soon solved by those who study a little bit, and establish some
 > > discipline in performing what they've learned.
 > 
 > Excuse me, but that is disparagingly patronising.

Nonsense.  I don't know what you and Richard are doing differently,
but it is a fact that millions of people have learned to use git,
reasonably quickly, at the level needed to contribute to some project.

I don't know why you and Richard encounter the issues you do.  That
doesn't mean I think you're somehow less of a developer for that.  I
would like to know why; if I did, I might be able to see a way to do
things your way.  But all I hear from you and Richard is that git
requires tens of hours to learn to the level required for contributing
to Emacs, which is manifestly false from my own experience and that of
many many others, and that it is a "screw", which is purely
pejorative.  Neither contains content useful to developing an
"unscrewed" workflow.

 > Again you're muddying the waters, insinuating that we're both stuck
 > in the antediluvian CVS past.

You want workflows that (for Richard) involves avoiding branches and
(for both) leaving some changes uncommitted for long periods while
updating your workspace with new code from upstream.  Those are
typical of workflows developed for and adapted to CVS.

"Antediluvian" is your word, not mine.  Feel free to retract it, I
won't mind.

 > > There's nothing wrong with wanting your tools to be adapted to
 > > you, of course, but if you want to cooperate with others,
 > > sometimes you need to compromise with the shared tools.
 > 
 > More insinuations.

Only if you make the effort to read them that way.  That was not my
intent, and it's in not the words you quoted.

 > Although I have criticised git's many shortcomings, I have never
 > requested or suggested that other people adapt it to my liking.

In fact, Richard has done so, in particular suggesting to seek out
somebody who "resents" git sufficiently to do it for him.  But I did
not say that in the text you quoted.

 > And nobody could fairly accuse me of not compromising with git.

"Fair" is a matter of opinion, of course.  But what anyone can observe
is that you complain about the need to compromise with git, and
disparage the tool itself.  I think that's hardly helpful in
developing a workflow.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Stephen.

#On Tue, Apr 14, 2015 at 08:08:12AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > Since that time, whenever I have files in the staging area ready to
>  > commit, and do a git pull, those files end up no longer being in the
>  > staging area.

> I don't understand.  I did

> cd /tmp
> git clone ~/src/Twitter
> cd Twitter
> git reset --hard HEAD^
> echo foo > foo
> git add foo

> I expect that if I now pull I will get an up-to-date git repo with foo
> ready for commit.  Try it:

> Twitter 18:19$ git pull
> Updating 64cb97f..f079094
> Fast-forward
>  stream.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> Twitter 18:19$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)

>   new file:   foo

> Twitter 18:19$

> How do I reproduce your experience?

I don't know.  But when it has happened to me, it has always been with
existing files in a repository directly cloned from a remote repository.
(I have no experience of other scenarios.)  I can't even say whether the
loss of staging of files is a bug or an intended feature.

>  > > ...., but the problems Richard and Alan are encountering are
>  > > soon solved by those who study a little bit, and establish some
>  > > discipline in performing what they've learned.

>  > Excuse me, but that is disparagingly patronising.

> Nonsense.  I don't know what you and Richard are doing differently,
> but it is a fact that millions of people have learned to use git,
> reasonably quickly, at the level needed to contribute to some project.

I can't speak for Richard, but for me, it might be how I learn new tools:
I first flick through tutorials to get the general gist of a tool, then
hit the reference documentation and build an internal mental map of it,
then start using the tool, using the reference doc to sort out the
problems which occur.  This usually works well, but hasn't done for git.

How do other people, such as yourself, learn these things?

> I don't know why you and Richard encounter the issues you do.  That
> doesn't mean I think you're somehow less of a developer for that.  I
> would like to know why; if I did, I might be able to see a way to do
> things your way.

OK.  To take an example, I was stuck a couple of months back having made
changes in my working directory and needing to revert them (from the
repository).  In many (?most) VCSs this operation is called "revert".
Not in git.  In git, you have to use "git checkout" in a particular
fashion.  Supposing one doesn't know that the command is called
"checkout", how does one find out?  How would you find this out?  In the
end, I gave up and bothered people on emacs-devel instead.  But if you
can answer this question, it would help me a great deal next time I have
a similar puzzlement.

> But all I hear from you and Richard is that git requires tens of hours
> to learn to the level required for contributing to Emacs, which is
> manifestly false from my own experience and that of many many others,

How, then, did you learn git?

> and that it is a "screw", which is purely pejorative.

I agree with you here.  The term is offensive, probably deliberately so.

> Neither contains content useful to developing an "unscrewed" workflow.

>  > Again you're muddying the waters, insinuating that we're both stuck
>  > in the antediluvian CVS past.

> You want workflows that (for Richard) involves avoiding branches and
> (for both) leaving some changes uncommitted for long periods while
> updating your workspace with new code from upstream.  Those are
> typical of workflows developed for and adapted to CVS.

Yes.  I think it more likely that CVS was developed for those workflows.
But why does git cope so badly with these workflows?  It's supposed to be
a modern flexible tool.

How do you personally deal with commits that you make not because your
development is at a suitable stage for a commit, but that you make
because git encourages/enforces it (for example, when you want to pull)?

I don't see any need for me personally to use branches.  If I was
constantly active in the development of several different things in Emacs
I might.  But then I would probably want to use several parallel
repositories rather than branches within a single one.  git's scheme of
constant branching and branch swapping doesn't scale to built objects
(such as files.o and files.elc).  I actually keep two Emacs git
repositories, one for master, the other for the Emacs-24 branch.

I foresee that both "frivolous" commits and "frivolous" branching would
create extra administrative work for me.  Somehow, they would have to be
dealt with, and effort would need to be made to prevent them accidentally
leaking to the savannah repository.

> "Antediluvian" is your word, not mine.  Feel free to retract it, I
> won't mind.

OK, I retract it.  There hasn't been a flood since the CVS times which
has affected me, so it's inaccurate.

[ ... ]

>  > And nobody could fairly accuse me of not compromising with git.

> "Fair" is a matter of opinion, of course.  But what anyone can observe
> is that you complain about the need to compromise with git, and
> disparage the tool itself.  I think that's hardly helpful in
> developing a workflow.

Well, maybe not.  But remaining silent about problems isn't helpful
either.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 17:16:35 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, rms@gnu.org,
>   Dmitry Gutov <dgutov@yandex.ru>
> From: Alan Mackenzie <acm@muc.de>
> 
> To take an example, I was stuck a couple of months back having made
> changes in my working directory and needing to revert them (from the
> repository).  In many (?most) VCSs this operation is called "revert".
> Not in git.  In git, you have to use "git checkout" in a particular
> fashion.  Supposing one doesn't know that the command is called
> "checkout", how does one find out?  How would you find this out?

The only way I found to be efficient is Google.  In this case, try
something like "git how to revert changes in a file".  You normally
get good hits right away.

Nothing else works, unless I already know enough about it to know
which man page(s) to summon.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[João Távora]

On Tue, Apr 14, 2015 at 6:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> The only way I found to be efficient is Google.  In this case, try
> something like "git how to revert changes in a file".  You normally
> get good hits right away.

I second google (or duckduckgo, for that matter)

But actually, to revert changes in a particular file, `git
status` , a command you should run often to see where you are,
gives you a pretty good hint:

    [emacs] echo bla >> README
    [emacs] git status
    # On branch master
    # Changes not staged for commit:
    #   (use "git add <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working
directory)
    #
    # modified:   README
    #
    no changes added to commit (use "git add" and/or "git commit -a")

More hints would be there if I had staged something, telling
me how to move between staged and unstaged states of a file.
The only hint I (personally) dislike is the "git pull" one that
appears on a failed "git push".

Perhaps these hints aren't showing by default with some git
installations and that's causing confusion?

-- 
João Távora

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 14 Apr 2015 22:23:01 +0100
> Cc: Alan Mackenzie <acm@muc.de>, Stephen Turnbull <stephen@xemacs.org>, Brief Busters <dgutov@yandex.ru>, 
> 	Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>
> 
> On Tue, Apr 14, 2015 at 6:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The only way I found to be efficient is Google.  In this case, try
> > something like "git how to revert changes in a file".  You normally
> > get good hits right away.
> 
> I second google (or duckduckgo, for that matter)
> 
> But actually, to revert changes in a particular file, `git
> status` , a command you should run often to see where you are,
> gives you a pretty good hint:

It's a good hint only if you already know what to do: it's too
technical.

Besides, "git status" is so annoyingly verbose that I never use it.  I
made an alias that runs "status --short" and use only it.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> Besides, "git status" is so annoyingly verbose that I never use it.  I
> made an alias that runs "status --short" and use only it.

Me too. I suggest throwing in a --branch too, however. You get one more 
line, but it's informative.

– Harald

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Wed, 15 Apr 2015 10:09:58 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: João Távora <joaotavora@gmail.com>, acm@muc.de, 
>  stephen@xemacs.org, emacs-devel@gnu.org, rms@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii wrote:
> > Besides, "git status" is so annoyingly verbose that I never use it.  I
> > made an alias that runs "status --short" and use only it.
> 
> Me too. I suggest throwing in a --branch too, however. You get one more 
> line, but it's informative.

Thanks, accepted.  Although my shell prompt shows the branch as well,
but it can never do harm to see the branch explicitly stated.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Wed, 15 Apr 2015 10:09:58 +0200
>> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
>> CC: João Távora<joaotavora@gmail.com>, acm@muc.de,
>>   stephen@xemacs.org, emacs-devel@gnu.org, rms@gnu.org, dgutov@yandex.ru
>>
>> Eli Zaretskii wrote:
>>> Besides, "git status" is so annoyingly verbose that I never use it.  I
>>> made an alias that runs "status --short" and use only it.
>> Me too. I suggest throwing in a --branch too, however. You get one more
>> line, but it's informative.
>
> Thanks, accepted.  Although my shell prompt shows the branch as well,
> but it can never do harm to see the branch explicitly stated.

Does your shell prompt show ahead/behind counts as well?

– Harald

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Wed, 15 Apr 2015 18:21:38 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: joaotavora@gmail.com, acm@muc.de, stephen@xemacs.org, 
>  emacs-devel@gnu.org, rms@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii wrote:
> >> Date: Wed, 15 Apr 2015 10:09:58 +0200
> >> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
> >> CC: João Távora<joaotavora@gmail.com>, acm@muc.de,
> >>   stephen@xemacs.org, emacs-devel@gnu.org, rms@gnu.org, dgutov@yandex.ru
> >>
> >> Eli Zaretskii wrote:
> >>> Besides, "git status" is so annoyingly verbose that I never use it.  I
> >>> made an alias that runs "status --short" and use only it.
> >> Me too. I suggest throwing in a --branch too, however. You get one more
> >> line, but it's informative.
> >
> > Thanks, accepted.  Although my shell prompt shows the branch as well,
> > but it can never do harm to see the branch explicitly stated.
> 
> Does your shell prompt show ahead/behind counts as well?

Not yet ;-)

Seriously, though: I'm not sure yet how useful will this information
be to me.  I'm never behind, and only briefly ahead.  But thanks for
mentioning that (the man page doesn't).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:

> I don't know.  But when it has happened to me, it has always been with
> existing files in a repository directly cloned from a remote
> repository.  (I have no experience of other scenarios.)  I can't even
> say whether the loss of staging of files is a bug or an intended
> feature.

I tried an experiment today, and I succeeded in reproducing it (in an
attempt at disproving it), but I didn't succeed in an attempt at
reproducing it with a slightly simpler procedure.

If I can reproduce it reliably I will file a bug with git.

I ended up with the restored stashed file being empty. 

See the conflict at the end of the commands below:

...
sb@mccoy:~/git/git-pull-test$ git pull
Auto-merging foo
Merge made by the 'recursive' strategy.
 foo | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sb@mccoy:~/git/git-pull-test$ git stash pop
Auto-merging foo
CONFLICT (content): Merge conflict in foo
sb@mccoy:~/git/git-pull-test$ cat foo
<<<<<<< Updated upstream
hi there
line two
line three modified
is there more?
Here is more!
Less is more!
=======
>>>>>>> Stashed changes
sb@mccoy:~/git/git-pull-test$ git --version
git version 1.9.4.msysgit.1

(what I did was to create a local git repository, clone it to another
local repository and try to pull at the same time as having stashed
changes in a modified file in the cloned repository)

However, this has never happened to me in a real situation, and I was
unable to reproduce it when I tried again (but with a slightly simpler
procedure).

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > However, a lot of people like git, possibly for reasons similar to the
  > ones why we dislike it.  As a project we're stuck with it for the
  > foreseeable future.  :-(

Maybe we could develop a version of git pull that merges like CVS,
rather than failing when remote changes are in the same file as a
local change.

We don't have to convince the Git developers, or even Git fans.
We just have to find people that resent Git and want to do the work.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Wed, 08 Apr 2015 14:21:42 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Maybe we could develop a version of git pull that merges like CVS,
> rather than failing when remote changes are in the same file as a
> local change.

git-pull is a shell script, you will find it in libexec/git-core/
directory.  Someone who knows enough about low-level Git commands can
write a modified script to do whatever they like.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

On Wed, Apr 8, 2015 at 2:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Someone who knows enough about low-level Git commands can
> write a modified script to do whatever they like.
>

E.g. Michael Haggerty's git-imerge script
<http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html>
(though
his is written in python).

/john

[-- Attachment #2: Type: text/html, Size: 703 bytes --]

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

John Yates writes:

 > E.g. Michael Haggerty's git-imerge script

Nice!  Looks to me like what "bzr loom" should have been.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/07/2015 07:13 PM, Richard Stallman wrote:

> Why should I have a "motivation to learn" so much about using git?
> I am not learning it our of curiosity!

I specifically meant to learn how to examine the results (which isn't 
much), but you can even do that using vc-print-root-log. Looking back, 
that alone wouldn't have helped.

Guess this time the key issue was you didn't know what to write in a 
merge commit message, but reading up on what a merge is in Git, on your 
own, might have cleared that up too.

> You make an analogy of fishing.  Suppose you are a teacher, and
> a government imposes the rule that every teacher must catch a fish
> each day in order to be allowed to teach that day.  Do you want
> to learn to fish, or do you want the rule cancelled?

If there's a shortage of food in town, and the regular fishermen can 
only catch enough to feed their families, I suppose everyone might have 
to go fishing, in addition to their regular employment.

But if you recall, leaving the fishing to the fishermen and just go 
teaching was also on the table (send patches through the mailing list). 
Though maybe I'm twisting the metaphor a bit here.

> Development tools are supposed to make our work easier -- not harder.
> For me, Git means many hurdles to jump in order to do the things that
> were easy before.

I'm sure most of it is unfamiliarity, and not the genuinely difficult 
interface, as some people like to claim.

But while working on Emacs, I also have had to spend effort on things 
that I usually find of little use: ChangeLog files, NEWS, updating the 
manual (one or two occasions), certain cases of maintaining backward 
compatibility. Yet other people apparently benefited from it, as so did 
the project as a whole.

 > Also, I do this infrequently enough that I will have time to forget
 > whatever I learn now.

That's a concern. But while specific commands might be forgettable, the 
core model of how Git represents history is fairly easy to get your head 
around and remember. If you read up on it, next time you're dealing with 
Git, even the man pages should make more sense, and using web search 
should be easier for more general questions.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Guess this time the key issue was you didn't know what to write in a 
  > merge commit message, but reading up on what a merge is in Git, on your 
  > own, might have cleared that up too.

I have other work to do than "read up" on various topics about Git.
The fact that people say I have a responsibility to do so
only demonstrates my point that Git is flawed.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/08/2015 09:19 PM, Richard Stallman wrote:

> I have other work to do than "read up" on various topics about Git.

Not "various", just architecture basics. It should be a 10-20 minutes read.

> The fact that people say I have a responsibility to do so
> only demonstrates my point that Git is flawed.

While Emacs used Bazaar, on numerous occasions I've had to read up how 
to do this or that. Feel free to search the email archives for the 
messages with me complaining.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 04:19:30 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> While Emacs used Bazaar, on numerous occasions I've had to read up how 
> to do this or that. Feel free to search the email archives for the 
> messages with me complaining.

Without searching, I'm quite sure the complaints were mostly due to
semantics of similar commands being different from what you were used
to in Git.

Complaints aside, Bazaar's advantage was that, given a one-time setup,
all the commands from the CVS era "just worked" and produced very
similar output.  So it was easy to adapt to.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/09/2015 10:31 AM, Eli Zaretskii wrote:

> Without searching, I'm quite sure the complaints were mostly due to
> semantics of similar commands being different from what you were used
> to in Git.

My point is, I didn't actually complain about it being unfamiliar, 
because working with Bazaar was a prerequisite to contributing to Emacs.

And neither did some other contributors in the similar situation.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > When someone is in grave trouble, what do you expect?

Richard wasn't in grave trouble.  He panicked when confronted with
unfamiliar output from the application.  It seems that up until the
last pull, his workflow was well-aligned with typical git workflows
(although it wasn't doing what he thought it was doing because he was
unaware that installing changes required a push).  So he was pretty
much committed up at that point, and therefore his changes were safe
against anything short of rm -rf.  The eventual resolution also turned
out to require only a few simple commands, it seems.

It was his attempts to teach the fishermen to fish before getting his
dinner cooked for him that triggered this thread.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Wed, 08 Apr 2015 05:45:40 +0900
> 
> Eli Zaretskii writes:
> 
>  > When someone is in grave trouble, what do you expect?
> 
> Richard wasn't in grave trouble.  He panicked when confronted with
> unfamiliar output from the application.

That's what I call "in grave trouble".

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1) Forget the "push automatically after commit" nonsense, and 
  > double-check each commit one creates before pushing.

The quick start instructions do not say that one should "double-check
each commit".  They don't even say how to double-check a commit.

  > 2) People who don't know how to do that, and are unwilling to learn, or 
  > who aren't confident in their results anyway should post patches to the 
  > mailing list.

That decision is not up to you.
I must be able to edit the Emacs repository.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 13:42:45 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> 
>   > 1) Forget the "push automatically after commit" nonsense, and 
>   > double-check each commit one creates before pushing.
> 
> The quick start instructions do not say that one should "double-check
> each commit".  They don't even say how to double-check a commit.

They didn't say that before, but they do now:

  It is a good idea to examine what you are about to push, before
  actually doing so, because fixing mistakes before pushing is much
  easier (see the next section). To do that, use the command "git diff
  origin/master". If you want to show your unpushed commits with their
  commit log messages, use "git show origin/master.." instead. If you only
  have one local commit you want to push, just "git show" is enough.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > It is a good idea to examine what you are about to push, before
    > actually doing so, because fixing mistakes before pushing is much
    > easier (see the next section). To do that, use the command "git diff
    > origin/master". If you want to show your unpushed commits with their
    > commit log messages, use "git show origin/master.." instead.

It is not clear to me how these two differ.  Does "git show origin/master.."
output everything that "git diff origin/master" outputs, plus log messages?

What are the two periods for?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 01:50:25 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dgutov@yandex.ru, emacs-devel@gnu.org
> 
>     > It is a good idea to examine what you are about to push, before
>     > actually doing so, because fixing mistakes before pushing is much
>     > easier (see the next section). To do that, use the command "git diff
>     > origin/master". If you want to show your unpushed commits with their
>     > commit log messages, use "git show origin/master.." instead.
> 
> It is not clear to me how these two differ.  Does "git show origin/master.."
> output everything that "git diff origin/master" outputs, plus log messages?

Yes, that's the only real difference between them, when you have no
uncommitted changes.  (When you do have uncommitted changes, "git
diff" will include them, while "git show" will not.)

> What are the two periods for?

That's because "git show" expects a range of commits to show, and the
two dots are part of specifying a range.  The full spec of what you
want is "origin/master..HEAD", where HEAD stands for the last commit
in your local branch, but HEAD can be omitted for shorthand purposes.

By contrast, "git diff" takes a single commit argument, and displays
the diffs between the working tree and that commit.

Do you think it would be best to keep only "git show" there and delete
the reference to "git diff"?

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> By contrast, "git diff" takes a single commit argument, and displays
> the diffs between the working tree and that commit.

Or it takes two, in which case it displays the diffs between two commits.

– Harald

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Do you think it would be best to keep only "git show" there and delete
  > the reference to "git diff"?

Yes.  But I think we should recommend defining a specific alias for it,
and using the alias.

Perhaps git-verify?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> Date: Tue, 07 Apr 2015 12:13:47 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dgutov@yandex.ru, emacs-devel@gnu.org
> 
>   > Do you think it would be best to keep only "git show" there and delete
>   > the reference to "git diff"?
> 
> Yes.

Done.

> But I think we should recommend defining a specific alias for it,
> and using the alias.
> 
> Perhaps git-verify?

Well, this doesn't really verify anything.  How about "git to-push" or
"git will-push" instead?

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Sebastien Vauban]

Eli Zaretskii wrote:
> That's because "git show" expects a range of commits to show, and the
> two dots are part of specifying a range.  The full spec of what you
> want is "origin/master..HEAD", where HEAD stands for the last commit
> in your local branch, but HEAD can be omitted for shorthand purposes.

I had the impression that "git show" was an older command, now
replaceable by "git log" with some options.  Is my impression right?

> By contrast, "git diff" takes a single commit argument, and displays
> the diffs between the working tree and that commit.

Isn't there a difference between "git diff" and "git diff HEAD" where
the first would show the changes between the working tree and the index,
while the latter would show them between the working tree and the latest
commit (HEAD, as you said)?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Harald Hanche-Olsen]

Sebastien Vauban wrote:
> I had the impression that "git show" was an older command, now
> replaceable by "git log" with some options.  Is my impression right?

As the two commands take many of the same options, you are probably 
right. “git log -1 -p” looks like a good start.

> Isn't there a difference between "git diff" and "git diff HEAD" where
> the first would show the changes between the working tree and the index,
> while the latter would show them between the working tree and the latest
> commit (HEAD, as you said)?

Yes. There is also “git diff --cached” (--staged is an alias of --cached 
here) which shows the diff between the commit (HEAD by default) and the 
index / staging area.

(One annoying feature of git is the great variation in terminology. It 
seems they have moved to new (and better?) terminology over time, but 
the old terminology remains, so that you now have to learn two or three 
synonymous terms for many concepts.)

– Harald

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:

 > the old terminology remains, so that you now have to learn two or three 
 > synonymous terms for many concepts.)

You mean like `caadar' and `cl-caadar'? <duck />

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Eli Zaretskii]

> From: Sebastien Vauban <sva-news@mygooglest.com>
> Date: Wed, 08 Apr 2015 14:02:41 +0200
> 
> Eli Zaretskii wrote:
> > That's because "git show" expects a range of commits to show, and the
> > two dots are part of specifying a range.  The full spec of what you
> > want is "origin/master..HEAD", where HEAD stands for the last commit
> > in your local branch, but HEAD can be omitted for shorthand purposes.
> 
> I had the impression that "git show" was an older command, now
> replaceable by "git log" with some options.  Is my impression right?

Maybe, I don't know.  Does it matter, in the context of those
instructions?

> > By contrast, "git diff" takes a single commit argument, and displays
> > the diffs between the working tree and that commit.
> 
> Isn't there a difference between "git diff" and "git diff HEAD" where
> the first would show the changes between the working tree and the index,
> while the latter would show them between the working tree and the latest
> commit (HEAD, as you said)?

Yes, and that somewhat confusing aspect is why the reference to "git
diff" was deleted from the instructions in that section.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Rostislav Svoboda]

On 6 April 2015 at 07:50, Richard Stallman <rms@gnu.org> wrote:
>     > commit log messages, use "git show origin/master.." instead.
>
> What are the two periods for?

I was puzzled by that too, back in the days... :)

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, this looks bad. It's a merge commit, with a crapload of changes 
  > (which is, by itself, to be expected), but the message makes it look 
  > like a normal commit, and enumerates the changes that are not, in fact, 
  > included in it.

I was told

    If I am right, you will see the changes you made, and nothing else.
    If so, fix up your commit message to something more reasonable with git 
    commit --amend, and you're good to go.

I had to guess what a "more reasonable" message is, and this is what I
guessed.

If my guess was not what you like, it's Git's fault.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Harald Hanche-Olsen]

Richard Stallman wrote:
> I was told
>
>      If I am right, you will see the changes you made, and nothing else.
>      If so, fix up your commit message to something more reasonable with git
>      commit --amend, and you're good to go.
>
> I had to guess what a "more reasonable" message is, and this is what I
> guessed.
>
> If my guess was not what you like, it's Git's fault.

I am more to blame for that than git is. In my defense, I was working on 
limited information, and I hadn't learned the expected format of a merge 
log message. But I think it's all worked out well in the end, not least 
thanks to Eli's efforts.

– Harald

Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Dmitry Gutov]

On 04/05/2015 08:42 PM, Richard Stallman wrote:

> I was told
>
>      If I am right, you will see the changes you made, and nothing else.
>      If so, fix up your commit message to something more reasonable with git
>      commit --amend, and you're good to go.

It's a merge commit. Usually, you can just go with the default message. 
There's definitely no need to remove the mention of this commit being a 
merge.

Someone else might have figured that there's no need to duplicate 
information already present in the other commits, which are also being 
pushed.

Depending on how change log generation handles merge commit (I'm not 
currently sure; does it just skip them?), someone might have to manually 
edit the resulting ChangeLog to straighten that out.

It's not that this occasion by itself is a big problem, but I'm sure 
we'd prefer to see it repeated as rarely as possible.

> I had to guess what a "more reasonable" message is, and this is what I
> guessed.

When you are given a vague instruction from some person you don't know 
very well, "guess at random and then perform an irreversible action" is 
usually not the only option.

> If my guess was not what you like, it's Git's fault.

Of course it is.