VC mode and git

VC mode and git

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

I think that C-x v v, when it commits changes, should also push them.
This would make git more comparable to other version control systems.

Does anyone see a reason not to?

-- 
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: VC mode and git

[Dmitry Gutov]

On 03/24/2015 05:57 PM, Richard Stallman wrote:
> [[[ 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. ]]]
>
> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.

It really shouldn't.

> Does anyone see a reason not to?

First and obvious reason, then there would be no way to commit without 
pushing. And yes, that's a useful ability.

Second, even if we add a user option, this would be an attempt to paper 
over the differences between the traditional VCS and the (modern) DVCS.

You really should familiarize yourself with that difference. All popular 
modern VCS are distributed (and thus have commit and push as different 
actions).

Re: VC mode and git

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

  > First and obvious reason, then there would be no way to commit without 
  > pushing. And yes, that's a useful ability.

If that is a useful ability we can easily make a command to do it.

A minor drawback that can easily be overcome is not an argument
against.

  > Second, even if we add a user option, this would be an attempt to paper 
  > over 

That's what VC is for: to paper over the differences between different
VC systems with a single uniform interface.

	 the differences between the traditional VCS and the (modern) DVCS.

It is a mistake to say that "modern" DVCs all work this way.
BZR did not.  I never had this problem with BZR.

-- 
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: VC mode and git

[Dmitry Gutov]

On 03/26/2015 12:54 PM, Richard Stallman wrote:

> It is a mistake to say that "modern" DVCs all work this way.
> BZR did not.  I never had this problem with BZR.

Even Bzr works this way by default. While it does have an optional 
"bound branch" workflow recommended to some newcomers, that requires 
extra configuration.

We shouldn't optimize VC for users coming from CVS; we should optimize 
for the modern user (which are the majority, or will be anyway), and 
they are accustomed to separate "commit" and "push" commands.

I could _maybe_ support `C-x v v' offering to push when the current file 
has no changes and there are local commits, but that's not what you're 
looking for anyway.

Re: VC mode and git

[John Yates]

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

On Thu, Mar 26, 2015 at 6:54 AM, Richard Stallman <rms@gnu.org> wrote:

> It is a mistake to say that "modern" DVCs all work this way.
> BZR did not.  I never had this problem with BZR.
>

IIANM that was not an inherent property of BZR but a configuration
choice made by the emacs project at the time of converting to BZR.
BZR made a point of allowing one to choose a highly centralized
workflow.  During emacs' BZR era the project opt'ed to avail itself
of that choice.  GIT offers no such choice.  It proudly offers only
a distributed workflow.

/john

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

Re: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 07:57:09 -0400
> From: John Yates <john@yates-sheets.org>
> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> IIANM that was not an inherent property of BZR but a configuration
> choice made by the emacs project at the time of converting to BZR.

No, it's an inherent feature of bzr that we recommended to Emacs
developers to use.  You can bind (or un-bind) any bzr branch as you
wish.  Bound branches implement commit+push as an atomic operation.

Re: VC mode and git

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

  >   During emacs' BZR era the project opt'ed to avail itself
  > of that choice.  GIT offers no such choice.  It proudly offers only
  > a distributed workflow.

"Be a man -- learn to do it the complicated way, even if it is of no
benefit to you."

-- 
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: VC mode and git

[Rasmus]

Richard Stallman <rms@gnu.org> writes:

> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.
>
> Does anyone see a reason not to?

It's generally not the way git is used, as it's meant to be decentralized
(I believe).  I typically edit my commits several times via git rebase
before pushing.

The confident hacker can push his or her changes automatically with git
hooks.  You'd put a shell script in ".git/hooks/post-commit" that issues
"git push origin master" or something similar.

—Rasmus

-- 
Bang bang

Re: VC mode and git

[Jan D.]

> 24 mar 2015 kl. 16:57 skrev Richard Stallman <rms@gnu.org>:
> 
> [[[ 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. ]]]
> 
> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.
> 
> Does anyone see a reason not to?

Sometimes there is no place to push, i.e. when you have a local git repository or a local development branch.

	Jan D.

Re: VC mode and git

[Daniel Colascione]

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

On 03/24/2015 08:57 AM, Richard Stallman wrote:
> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.

Absolutely not. Git is decentralized system. The whole point is to
separate *my* history from *your* history. This is incredibly powerful
facility that Emacs should not try to bypass in order to make git work
more like the obsolete version control systems it supplanted.

It's not even clear how the feature would work. The upstream for a
particular git repository isn't always clear. If you want to work like
that, you're free to configure your system to do so. What you propose is
very much not idiomatic.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

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

  > Absolutely not. Git is decentralized system. The whole point is to
  > separate *my* history from *your* history.

The whole point of VC is to provide a common interface to various VC 

You may regard that decentralization as a feature.  I have no use for
it myself, but I did fall into the resulting pitfall.

That is no reason to abandon the compatibility that is VC's goal.

  > This is incredibly powerful
  > facility that Emacs should not try to bypass in order to make git work
  > more like the obsolete version control systems it supplanted.

They are not obsolete, and they are not supplanted.  You don't have to
use them, but I do.

  > It's not even clear how the feature would work. The upstream for a
  > particular git repository isn't always clear.

For 'git push' to work, it has to know where to push to.
Isn't that clear enough?  If 'git push' knows where,
C-x v v checkin can know where.


-- 
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: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> [[[ 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. ]]]
> 
> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.
> 
> Does anyone see a reason not to?

Yes. It would mean VC mode could not be used to work on private development
branches.

An important part of many DVCs workflows is that you can make experimental 
changes that users of whatever shared repository your pushes go to don't see.

It is common for people to try a risky modification that may consist of
multiple commits, test it privately, then push the series when the code 
has reached a stable and well-tested state. Sometimes this fails, and 
you need to revert to the last publicly visible state.

If every commit did a push, this option would go away. The friction cost
of experimenting would go up.  A lot of people would be forced to abandon
using C-X v v as a routine thing and have to go outside Emacs to do commits.
It's not a good idea.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 12:37:14 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> > I think that C-x v v, when it commits changes, should also push them.
> > This would make git more comparable to other version control systems.
> > 
> > Does anyone see a reason not to?
> 
> Yes. It would mean VC mode could not be used to work on private development
> branches.

Why cannot VC determine whether a branch is private or not?

I'm not saying I think "C-x v v" should push -- I don't -- but the
reason you bring up doesn't sound as a serious one.

Re: VC mode and git

[Daniel Colascione]

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

On 03/24/2015 10:20 AM, Eli Zaretskii wrote:
>> Date: Tue, 24 Mar 2015 12:37:14 -0400
>> From: "Eric S. Raymond" <esr@thyrsus.com>
>> Cc: emacs-devel@gnu.org
>>
>>> I think that C-x v v, when it commits changes, should also push them.
>>> This would make git more comparable to other version control systems.
>>>
>>> Does anyone see a reason not to?
>>
>> Yes. It would mean VC mode could not be used to work on private development
>> branches.
> 
> Why cannot VC determine whether a branch is private or not?

It's a matter of convention, not something vc can query. Whether I want
to push depends on a lot more than what vc, or any automated tool, can
figure out in the general case by sniffing around the build environment.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 10:24:16 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> >> Yes. It would mean VC mode could not be used to work on private development
> >> branches.
> > 
> > Why cannot VC determine whether a branch is private or not?
> 
> It's a matter of convention, not something vc can query. Whether I want
> to push depends on a lot more than what vc, or any automated tool, can
> figure out in the general case by sniffing around the build environment.

You are answering a different question.  I asked why it's hard to
determine that a branch is a private one, not to determine my intent
to push or not.

Re: VC mode and git

[Daniel Colascione]

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

On 03/24/2015 10:26 AM, Eli Zaretskii wrote:
>> Date: Tue, 24 Mar 2015 10:24:16 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: rms@gnu.org, emacs-devel@gnu.org
>>
>>>> Yes. It would mean VC mode could not be used to work on private development
>>>> branches.
>>>
>>> Why cannot VC determine whether a branch is private or not?
>>
>> It's a matter of convention, not something vc can query. Whether I want
>> to push depends on a lot more than what vc, or any automated tool, can
>> figure out in the general case by sniffing around the build environment.
> 
> You are answering a different question.  I asked why it's hard to
> determine that a branch is a private one, not to determine my intent
> to push or not.

"Private" is also a convention. Git doesn't distinguish "private" from
"public" branches: that distinction is a matter of convention.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

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

  > > Why cannot VC determine whether a branch is private or not?

  > It's a matter of convention, not something vc can query.

An experienced git user could create a file in the repository, whose
existence says that VC should not push automatically as part of a
commit.

-- 
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: VC mode and git

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> Why cannot VC determine whether a branch is private or not?
> 
> I'm not saying I think "C-x v v" should push -- I don't -- but the
> reason you bring up doesn't sound as a serious one.

Because the knowledge as to whether the branch is intended to be private or
public is an intention in the mind of the programmer, which git cannot read.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 13:35:36 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > Why cannot VC determine whether a branch is private or not?
> > 
> > I'm not saying I think "C-x v v" should push -- I don't -- but the
> > reason you bring up doesn't sound as a serious one.
> 
> Because the knowledge as to whether the branch is intended to be private or
> public is an intention in the mind of the programmer, which git cannot read.

Isn't there something in .git/refs/remotes/ that could disclose what's
on her mind?

Re: VC mode and git

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Because the knowledge as to whether the branch is intended to be private or
> > public is an intention in the mind of the programmer, which git cannot read.
> 
> Isn't there something in .git/refs/remotes/ that could disclose what's
> on her mind?

Even when a remote has been declared, git cannot know about any sequence of 
commits whether it's intended to be published to that remote.  It might be 
exploratory programming, done with the option to reset to a prior state
in mind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

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

  > Even when a remote has been declared, git cannot know about any sequence of 
  > commits whether it's intended to be published to that remote.  It might be 
  > exploratory programming, done with the option to reset to a prior state
  > in mind.

1. If that's what you want, why do a commit?  You can test the modified
files without committing them.

2. That is rather sophisticated use; a user who might want to do this
would know how to get what he wants.  He could set a flag saying
that C-x v v should not push in this repository, or whatever it takes.

In general, the messages opposing this change have presented arguments
that are weak: possible problems for expert git users that have
obvious solutions that would be be easy for an expert git user to use.


-- 
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: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>  > Even when a remote has been declared, git cannot know about any sequence of 
>  > commits whether it's intended to be published to that remote.  It might be 
>  > exploratory programming, done with the option to reset to a prior state
>  > in mind.
> 
> 1. If that's what you want, why do a commit?  You can test the modified
> files without committing them.

Because quite frequently, while exploring, there are states you want to save
- so you can roll back to them - that are not final.  For example, a refactor
(which should have its own change comment) during an attempted fix.
 
> 2. That is rather sophisticated use; a user who might want to do this
> would know how to get what he wants.  He could set a flag saying
> that C-x v v should not push in this repository, or whatever it takes.

He does know how to get what he wants. He gets it by not pushing until he
is ready to commit.

Separating these operations is the simplest possible way to afford
this flexibility.  Adding policy flags adds complexity and should
not be done unless they bring a larger gain in utility, which is I'm
theoretically possible but I'm not seeing.

What people are trying to tell you is that you are trying to force-fit
a DVCS into behaving like a centralized VCS because your thinking
about how to use it is still limited by old mental habits from RCS/CVS
days.  Early in my learning process about DVCSes I had the same
problem and had to get past it. Now it's your turn.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

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

  > What people are trying to tell you is that you are trying to force-fit
  > a DVCS into behaving like a centralized VCS because your thinking
  > about how to use it is still limited by old mental habits from RCS/CVS
  > days.

When a change in software makes people change their mental habits,
that is called "incompatibility".  It is a negative.

You can't make incompatibility a virtue by calling the previous mental
habits "old" or saying that they "limit" people.  That's just
name-calling.

	   Early in my learning process about DVCSes I had the same
  > problem and had to get past it. Now it's your turn.

In other words, "We all suffered through this inconvenience, so why
shouldn't you have to suffer as we did?"

Perhaps you gained something in exchange for the incompatibility.
Distributed version control systems permit many things that may be
useful for you -- but I don't have an occasion to do those things.

Of course, it is not a lot of work to type 'git push'.  The issue is
not about that small amount of work.  The problem is the pitfall:
forgetting to do this leads to silent lossage.

Sometimes incompatibility is inevitable, but that's not true in this
case.  It is easy to see how to make VC make this operation
compatible, in various ways.  We can get all the benefit without the
pitfall.

-- 
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: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> When a change in software makes people change their mental habits,
> that is called "incompatibility".  It is a negative.

Sometimes. Other times it's called "proper separation of function", as in
this case.
 
> 	   Early in my learning process about DVCSes I had the same
>   > problem and had to get past it. Now it's your turn.
> 
> In other words, "We all suffered through this inconvenience, so why
> shouldn't you have to suffer as we did?"

It is often the case that new tools require new mental habits if
you're going to fully exploit them.  If you tried to program in LISP
exactly emulating the style of assembler, you'd produce terrible LISP.

> Perhaps you gained something in exchange for the incompatibility.
> Distributed version control systems permit many things that may be
> useful for you -- but I don't have an occasion to do those things.

Most other people do.  By changing the default in the way you suggest, their
workflows will be disrupted.  You are, in effect, demanding that everyone
be required to treat this LISP like an assembler unless they flip a switch.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[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 other words, "We all suffered through this inconvenience, so why
  > > shouldn't you have to suffer as we did?"

  > It is often the case that new tools require new mental habits if
  > you're going to fully exploit them.

I have no wish to fully exploit the flexibility of git.  I understand
it is useful for those doing more complex things -- but, for me, it is
not merely useless, it is a screw.  (If it were merely useless to me,
I would not complain about it.)

Bzr has more or less the same flexibility as Git, and yet it has a
simple mode of operation which doesn't create this problem.  Surely
Git can have one too.

-- 
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: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > Bzr has more or less the same flexibility as Git,

Only from your self-declared non-expert perspective.  Bzr has *one*
advantage in flexibility over git, and that is bound branches.
Otherwise, git has a huge advantage over bzr in flexibility at every
level.  

 > and yet it has a simple mode of operation which doesn't create this
 > problem.

It's not a problem for anyone who doesn't have a decade and a half of
CVS usage under his belt.  Really.  And as Eric points out, most of us
who do have that experience have also jumped on the DVCS bandwagon
with a shout of joy.

I'm not saying that you should jump for joy, too, just that you are in
a fairly small and rapidly decreasing minority.

 > Surely Git can have one too.

As the thread on "echo 'git push || git reset HEAD^' > .post-commit-hook"
demonstrates, it's not as easy as you might hope.  It could be done in
vc.el, but bzr uses a lot of code to get bound branches right.  (It's
unclear how much code is actually needed because of bzr's baroque
architecture, but execution path goes through quite a few functions
from several modules.)  It might be very hard to get it right, and if
you get it wrong, users will be screwed in exactly the way you worry
about.

Regards,

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Fri, Mar 27, 2015 at 03:38:54PM +0900, Stephen J. Turnbull wrote:
> Richard Stallman writes:

>  > Bzr has more or less the same flexibility as Git,

> Only from your self-declared non-expert perspective.  Bzr has *one*
> advantage in flexibility over git, and that is bound branches.
> Otherwise, git has a huge advantage over bzr in flexibility at every
> level.  

Correction: git is hugely more flexible than bzr.  It's a value
judgement as to whether this flexibility is a "huge advantage".

Flexibility means complexity.  Complexity, without a good reason, is
bad.  git's complexity is IMAO very bad in this sense.  That this
complexity is not needed in a useful VCS is proved by the counterexample
of Mercurial.

I thoroughly resent the hour after hour after hour I've been forced to
spend reading git man pages, desperately searching for the obscure
option (or obscure command name) needed to get me out of some problem or
other, or find out how to do some simple thing.  I strongly suspect
Richard would agree with me on this point.

Just for comparison, the git man pages weigh in at 1,681,250 bytes, the
entire Emacs manual (24.3, info format) is 2,315,718 bytes.  A VCS should
not take the same order of magnitude of text and effort to describe and
learn as Emacs does.

A VCS which can dump somebody in the sort of problems Richard now has,
when he has merely been performing the simplest of operations, is an
excessively "flexible" system.

>  > and yet it has a simple mode of operation which doesn't create this
>  > problem.

> It's not a problem for anyone who doesn't have a decade and a half of
> CVS usage under his belt.  Really.  And as Eric points out, most of us
> who do have that experience have also jumped on the DVCS bandwagon
> with a shout of joy.

As an on-jumper, I can't recollect any shouts of joy on my part.  DVCSs
have advantages and disadvantages, and I think the former outweigh the
latter - except in the case of git.  Personally, I would now be more
productive in Emacs if we had just stayed with CVS (though I do
recognise that part of that advantage came from other people's drudge
work).

> I'm not saying that you should jump for joy, too, just that you are in
> a fairly small and rapidly decreasing minority.

One wonders at this point just how many people have been excluded from
active participation in free software projects due to being unable or
unwilling to learn git.  These people don't get to vote, and don't get
counted.

[ .... ]

> Regards,

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 12:30:13 +0000
> Cc: rms@gnu.org, esr@thyrsus.com, eliz@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I thoroughly resent the hour after hour after hour I've been forced to
> spend reading git man pages, desperately searching for the obscure
> option (or obscure command name) needed to get me out of some problem or
> other, or find out how to do some simple thing.

I concluded long ago that the Git man pages are not the right tool for
that.  I find a Google search much more efficient in finding answers
to such questions.  I only use the man pages as a reference for
something I already know about, but forgot the details, or don't
exactly remember the option's exact name.

Re: VC mode and git

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

  > Flexibility means complexity.  Complexity, without a good reason, is
  > bad.  git's complexity is IMAO very bad in this sense.  That this
  > complexity is not needed in a useful VCS is proved by the counterexample
  > of Mercurial.

Furthermore, flexibility and complexity do not necessarily impose a
fixed price in the form of pitfalls.  With good design, more
flexibility (and complexity) can be available to those who want it
without causing trouble for those that don't.


-- 
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: VC mode and git

[Stefan Monnier]

> Only from your self-declared non-expert perspective.  Bzr has *one*
> advantage in flexibility over git, and that is bound branches.

FWIW, it has also lightweight checkouts.  It also has situations where
it handles file-renames better (see the corresponding vc-print-log bug
report mentioned recently).


        Stefan

Re: VC mode and git

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > Only from your self-declared non-expert perspective.  Bzr has *one*
 > > advantage in flexibility over git, and that is bound branches.
 > 
 > FWIW, it has also lightweight checkouts.

Those are basically crippled bound branches IMHO; if you want to count
them separately, that makes sense since Richard is always concerned
about using Emacs on machines that are seriously underpowered by
today's standards in OECD countries.  Or, for most of bzr's history,
you could just use git and get the same reduction in space used,
without losing disconnected operation. :-)

 > It also has situations where it handles file-renames better (see
 > the corresponding vc-print-log bug report mentioned recently).

I wouldn't call that "flexibility"; it's a different approach, and
IIRC bzr never learned to detect those automatically so you had to use
bzr rename or bzr copy to get the right answer.  If bzr can autodetect
renames, then it would be more flexible.

Re: VC mode and git

[Stefan Monnier]

> Those are basically crippled bound branches IMHO;

That's one way to look at them.

But being an avid user of git-new-workdir, I think it goes further than
that.  All the lightweight checkouts don't just share the storage space
but they also share the "git remote" setup, the stash space, and things
like that, which makes a big difference to me (regarding the stash
space, Bzr's shelves were "per checkout" and I often ended up copying
them from one checkout to another, so I appreciate the fact that they're
per-repository in Git).

> if you want to count them separately, that makes sense since Richard
> is always concerned about using Emacs on machines that are seriously
> underpowered by today's standards in OECD countries.

I hate fans, so my computers tend to be seriously underpowered as well.

> Or, for most of bzr's history, you could just use git and get the same
> reduction in space used, without losing disconnected operation. :-)

The .git directory (mine's at 420MB right now) is not significantly
smaller then the .bzr was (I remember mine hovering around 500MB).

>> It also has situations where it handles file-renames better (see
>> the corresponding vc-print-log bug report mentioned recently).
> I wouldn't call that "flexibility"; it's a different approach, and
> IIRC bzr never learned to detect those automatically so you had to use
> bzr rename or bzr copy to get the right answer.

It had "bzr automove" or something like that, but it didn't work very well.

> If bzr can autodetect renames, then it would be more flexible.

Auto-detection is nice (tho I use "git mv" anyway, but it does help when
you forget it).  But the bug-report points out the difficulty of getting
from "this changelog entry" to "the corresponding diff" because you need
to pass the "file name used back then".  It's a difficult problem in
general, but in my experience Bzr handled it better.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: esr@thyrsus.com,  eliz@gnu.org,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 27 Mar 2015 14:10:49 -0400
> 
> It had "bzr automove" or something like that, but it didn't work very well.

Actually, automove worked very well; it's "mv --auto" that fell short.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
>     eliz@gnu.org,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Sat, 28 Mar 2015 01:53:19 +0900
> 
> IIRC bzr never learned to detect those automatically so you had to use
> bzr rename or bzr copy to get the right answer.  If bzr can autodetect
> renames, then it would be more flexible.

That's not true: I have the automv plugin installed for bzr that does
detect renames automatically.  In addition, the built-in "mv" command
has the --auto switch which does that, but AFAIR its performance was
not as good as that of the plugin.

Re: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Bzr has more or less the same flexibility as Git, and yet it has a
> simple mode of operation

It's not a "simple mode of operation".  You should know better, being
offline most of the time.

Andreas.

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

Re: VC mode and git

[Dmitry Gutov]

On 03/26/2015 12:56 PM, Richard Stallman wrote:

> Of course, it is not a lot of work to type 'git push'.  The issue is
> not about that small amount of work.  The problem is the pitfall:
> forgetting to do this leads to silent lossage.

Perhaps that can be solved in a different way. Magit displays the list 
of local unpushed commits in the status buffer.

We could have a similar section in `vc-dir'.

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 10:43:15 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> 
>   > Even when a remote has been declared, git cannot know about any sequence of 
>   > commits whether it's intended to be published to that remote.  It might be 
>   > exploratory programming, done with the option to reset to a prior state
>   > in mind.
> 
> 1. If that's what you want, why do a commit?  You can test the modified
> files without committing them.

Indeed, I generally commit after I tested.  But having written and
tested a small part of a large feature doesn't yet mean I'm ready to
publish it.  As a matter of fact, the small part that I've written and
tested might not be useful on its own right, or might even break other
features.  IOW, the tested code is incomplete.

So pushing might be inappropriate.  But I still want to keep the
history of mu changes recorded in the VCS, because if I later find
that I introduced a bug, I want to be able to see which change did
that.

And there are other good reasons to commit frequently without pushing.

Such workflows are widely used these days, and we cannot possibly
ignore them, even if you or someone else never uses them.  Users will
not forgive us if we do.

> 2. That is rather sophisticated use; a user who might want to do this
> would know how to get what he wants.  He could set a flag saying
> that C-x v v should not push in this repository, or whatever it takes.

Yes, pushing should be optional.  The question is how exactly to
implement the option, and whether "C-x v v" should do anything else
before pushing.  For example, I always do a "git show" before pushing,
to have one last look at what I will push and make sure I didn't miss
anything, or made some mistake.  Fixing mistakes in local commits is
easy; doing that after pushing is much harder (basically impossible,
except by another commit/push).

So perhaps "C-x v v" after a local commit should do a "git show", and
offer to push from there.

> In general, the messages opposing this change have presented arguments
> that are weak: possible problems for expert git users that have
> obvious solutions that would be be easy for an expert git user to use.

AFAIR, none of the messages described any expert uses of Git, they all
describe very simple and basic workflows, ones that are widely used by
everyone.  It would be wrong to make "C-x v v" disrupt those
workflows.

Re: VC mode and git

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

  > Yes, pushing should be optional.  The question is how exactly to
  > implement the option, and whether "C-x v v" should do anything else
  > before pushing.  For example, I always do a "git show" before pushing,
  > to have one last look at what I will push and make sure I didn't miss
  > anything, or made some mistake.

I think that _by default_ C-x v v should commit and push.  But there
are many ways to work out the details of that.  I have nothing against
having it display more information, ask for confirmation, or whatever.
And I have nothing against making this depend on settings in the
repository or .emacs.

The point is that C-x v v should not, by default, lead people to
think they are finished, without installing the changes on Savannah.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 06:57:17 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: esr@thyrsus.com, emacs-devel@gnu.org
> 
> The point is that C-x v v should not, by default, lead people to
> think they are finished, without installing the changes on Savannah.

Thing is, for most users of Git nowadays, having committed locally
_does_ mean they are finished.  They don't perceive the push as an
integral part of the routine flow.  So the current default suits the
majority very well.

Re: VC mode and git

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

  > AFAIR, none of the messages described any expert uses of Git, they all
  > describe very simple and basic workflows, ones that are widely used by
  > everyone.

With all due respect, you underestimate the amount of expertise
involved.  Perhaps there is a natural tendency to think, about the
things that you are an expert on, that it isn't much expertise.

People like me, who barely know how to use Git but have to use it a
little, must be very numerous.

	       It would be wrong to make "C-x v v" disrupt those
  > workflows.

I am not proposing to disrupt anything, just to change the default,
and only when using VC.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 06:57:18 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: esr@thyrsus.com, emacs-devel@gnu.org
> 
>   > AFAIR, none of the messages described any expert uses of Git, they all
>   > describe very simple and basic workflows, ones that are widely used by
>   > everyone.
> 
> With all due respect, you underestimate the amount of expertise
> involved.

I don't think so.

> Perhaps there is a natural tendency to think, about the things that
> you are an expert on, that it isn't much expertise.

I'm far from being an expert on Git, believe me.  I just memorized a
couple of useful workflows which work for me.

> People like me, who barely know how to use Git but have to use it a
> little, must be very numerous.

I don't have statistics, but I very much doubt that your assertion is
true.

> 	       It would be wrong to make "C-x v v" disrupt those
>   > workflows.
> 
> I am not proposing to disrupt anything, just to change the default,
> and only when using VC.

A default that goes contrary to expectations of the many will be seen
as a disruption, I think.

Re: VC mode and git

[Paul Eggert]

On 03/25/2015 07:43 AM, Richard Stallman wrote:
> In general, the messages opposing this change have presented arguments
> that are weak: possible problems for expert git users that have
> obvious solutions that would be be easy for an expert git user to use.

In my experience, few git users are expert enough to solve all the 
problems mentioned in this thread on their own, without a lot of 
head-scratching or consulting friends etc.  However, most non-expert Git 
users will want to maintain the distinction between committing and 
pushing, as this distinction is basic to Git and is typically 
preferred.  If VC by default conflated committing with pushing, I expect 
that would cause more problems than it'd cure, even among non-experts.

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Why cannot VC determine whether a branch is private or not?

A branch can be both at the same time.

Andreas.

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

Re: VC mode and git

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

  > > Why cannot VC determine whether a branch is private or not?

  > A branch can be both at the same time.

People who are doing such sophisticated things will understand the
issues and can use whatever interface to specify what they want.

The reason to make this change is to help people who are not
sophisticated git users.


-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> The reason to make this change is to help people who are not
> sophisticated git users.

For those people it is even more important that vc does not push by
default.  Pushing by accident is bad.

Andreas.

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

Re: VC mode and git

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> Richard Stallman <rms@gnu.org> writes:
> 
> > The reason to make this change is to help people who are not
> > sophisticated git users.
> 
> For those people it is even more important that vc does not push by
> default.  Pushing by accident is bad.

That's right.  An unintended push-on-commit is *much* more likely to
cause annoyance and damage than an unintended non-push-on-commit.  A
local commit is a reversible operation; a push is not.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

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

  > That's right.  An unintended push-on-commit is *much* more likely to
  > cause annoyance and damage than an unintended non-push-on-commit.

The failure to push means that the change is not installed.
This could go unnoticed for months.

-- 
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: VC mode and git

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

  > > The reason to make this change is to help people who are not
  > > sophisticated git users.

  > For those people it is even more important that vc does not push by
  > default.

With all due respect, I think you are mistaken.  C-x v v pushes by
default with CVS and with Bzr, and that has never been a problem.  Why
would it be a problem with Git when it is not a problem with the
others?

	      Pushing by accident is bad.

If C-x v v is defined to push,
that will not be an accident.

Yuri Khan said:

  > > The reason to make this change is to help people who are not
  > > sophisticated git users.

  > And teach them bad habits along the way? Please don’t.

That seems to be name-calling.  My workflow was not bad with CVS or
Bzr, so why should it be bad now?  You seem to think that it is ok to
disrupt the workflow of people like me who rarely use Git.

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> With all due respect, I think you are mistaken.  C-x v v pushes by
> default [...] with Bzr,

This is wrong.

Andreas.

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

Re: VC mode and git

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> With all due respect, I think you are mistaken.  C-x v v pushes by
>> default [...] with Bzr,
>
> This is wrong.

Just to elaborate: neither vc-bzr nor vc-git nor vc-hg (the DVCS
interfaces) push on commit but our advertised bzr setup made bzr itself
push on commit by default (because it was a bound branch).

In the same way, you could set up a git post-commit hook that pushes if
you wish by placing a scipt with contents

--8<---------------cut here---------------start------------->8---
#!/bin/sh
git push
--8<---------------cut here---------------end--------------->8---

in .git/hooks/post-commit/.

Bye,
Tassilo

Re: VC mode and git

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Richard Stallman <rms@gnu.org>,  esr@thyrsus.com,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 26 Mar 2015 12:38:15 +0100
> 
> In the same way, you could set up a git post-commit hook that pushes if
> you wish by placing a scipt with contents
> 
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
> git push
> --8<---------------cut here---------------end--------------->8---
> 
> in .git/hooks/post-commit/.

What happens if the commit succeed, but the push in the hook fails?
Will Git roll back the commit?

If not, then this isn't reallt a good emulation of bzr's bound
branches, because there a commit+push was an atomic operation: either
both succeeded, or none at all.

Re: VC mode and git

[Dmitry Gutov]

On 03/26/2015 06:59 PM, Eli Zaretskii wrote:

>> in .git/hooks/post-commit/.
>
> What happens if the commit succeed, but the push in the hook fails?
> Will Git roll back the commit?

Nope, unless you ask it.

> If not, then this isn't reallt a good emulation of bzr's bound
> branches, because there a commit+push was an atomic operation: either
> both succeeded, or none at all.

Maybe you should try something like:

git push || git reset HEAD^

(100% untested).

Re: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 19:07:42 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: esr@thyrsus.com, schwab@linux-m68k.org, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> On 03/26/2015 06:59 PM, Eli Zaretskii wrote:
> 
> >> in .git/hooks/post-commit/.
> >
> > What happens if the commit succeed, but the push in the hook fails?
> > Will Git roll back the commit?
> 
> Nope, unless you ask it.

Thought so.  So the simplistic script posted here is really not a good
idea, IMO.  It needs to be smarter in order to be useful to people who
don't want to hear about pushing separately.

> > If not, then this isn't reallt a good emulation of bzr's bound
> > branches, because there a commit+push was an atomic operation: either
> > both succeeded, or none at all.
> 
> Maybe you should try something like:
> 
> git push || git reset HEAD^

Yes, and then somehow we should also emulate bzr's "commit --local",
so that you could commit without pushing should you need that (e.g.,
after a failed merge or whatnot).

Volunteers welcome to provide such a facility ;-)

Re: VC mode and git

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

  > Maybe you should try something like:

  > git push || git reset HEAD^

What does  git reset HEAD^  do?
Is it reliable?

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 09:25:54 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, tsdh@gnu.org, esr@thyrsus.com,
> 	schwab@linux-m68k.org, emacs-devel@gnu.org
> 
>   > Maybe you should try something like:
> 
>   > git push || git reset HEAD^
> 
> What does  git reset HEAD^  do?

It uncommits the last commit, but leaves your changes in the working
tree, essentially returning you back to the situation before you
committed.

> Is it reliable?

It never failed me, although I needed to use it only rarely, when my
last commit had a mistake that I detected before pushing upstream.

But I'll defer to the experts for the definitive opinions about its
reliability.

Re: VC mode and git

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

Perhaps the best thing is to make C-x v v, when it does a commit,
display a message suggesting that you push.  There would be a separate
command for that.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sat, 28 Mar 2015 12:16:52 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dgutov@yandex.ru, tsdh@gnu.org, esr@thyrsus.com,
> 	schwab@linux-m68k.org, emacs-devel@gnu.org
> 
> Perhaps the best thing is to make C-x v v, when it does a commit,
> display a message suggesting that you push.  There would be a separate
> command for that.

If people agree, this would be a very simple change, I think.

Re: VC mode and git

[Stefan Monnier]

>> Perhaps the best thing is to make C-x v v, when it does a commit,
>> display a message suggesting that you push.  There would be a separate
>> command for that.

> If people agree, this would be a very simple change, I think.

I think everyone agrees we should add a vc-push command, and I think
adding a message reminding the user that Git's commit hasn't pushed the
change upstream yet would be fine.


        Stefan

Re: VC mode and git

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

  > Just to elaborate: neither vc-bzr nor vc-git nor vc-hg (the DVCS
  > interfaces) push on commit but our advertised bzr setup made bzr itself
  > push on commit by default (because it was a bound branch).

If Git has no feature comparable to a bound branch, that seems like a defect
compared with Bzr.  Perhaps we should supply that feature.

  > In the same way, you could set up a git post-commit hook that pushes if
  > you wish by placing a scipt with contents

  > --8<---------------cut here---------------start------------->8---
  > #!/bin/sh
  > git push
  > --8<---------------cut here---------------end--------------->8---

  > in .git/hooks/post-commit/.

That recommendation is rather cumbersome compared to our former
recommendations for Bzr, but that change would be a step up
in our Git recommendations for people starting with Git.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 23:09:04 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: esr@thyrsus.com, eliz@gnu.org, schwab@linux-m68k.org, emacs-devel@gnu.org
> 
>   > Just to elaborate: neither vc-bzr nor vc-git nor vc-hg (the DVCS
>   > interfaces) push on commit but our advertised bzr setup made bzr itself
>   > push on commit by default (because it was a bound branch).
> 
> If Git has no feature comparable to a bound branch, that seems like a defect
> compared with Bzr.

Personally, I agree, but the majority out there don't.  Until a
motivated individual steps forward and adds this to Git, I don't think
we can hope to have such a feature.

> Perhaps we should supply that feature.

You mean, in Emacs?  I don't think we can.  The commit in a bound
branch was committing and pushing atomically, and I don't see how can
you do that by calling two separate Git commands.

>   > In the same way, you could set up a git post-commit hook that pushes if
>   > you wish by placing a scipt with contents
> 
>   > --8<---------------cut here---------------start------------->8---
>   > #!/bin/sh
>   > git push
>   > --8<---------------cut here---------------end--------------->8---
> 
>   > in .git/hooks/post-commit/.
> 
> That recommendation is rather cumbersome compared to our former
> recommendations for Bzr, but that change would be a step up
> in our Git recommendations for people starting with Git.

I don't recommend it, certainly not with this script, for 2 reasons:

  . using the script, the commit+push are not an atomic operation, so
    the commit could succeed, but the following push could fail,
    leaving your repository out of sync

  . it will be hard (or even impossible) to do a local commit without
    pushing, because the hook will always be run; you need the local
    commit for when you merge and resolve conflicts and in other
    situations

So, unless someone comes with a smarter hook script that overcomes the
above deficiencies, I strongly recommend against using it.

Re: VC mode and git

[Stefan Monnier]

>   . using the script, the commit+push are not an atomic operation, so
>     the commit could succeed, but the following push could fail,
>     leaving your repository out of sync

That's true: we need to uncommit if the push fails.
BTW, we could/should make this case very rare by adding a pre-commit
hook which makes sure that we're up-to-date before we can commit.

>   . it will be hard (or even impossible) to do a local commit without
>     pushing, because the hook will always be run; you need the local
>     commit for when you merge and resolve conflicts and in other
>     situations

I don't see why Richard (or someone in his situation) would ever need to
do a local commit.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  esr@thyrsus.com,  emacs-devel@gnu.org,  schwab@linux-m68k.org,  tsdh@gnu.org
> Date: Fri, 27 Mar 2015 08:59:41 -0400
> 
> >   . using the script, the commit+push are not an atomic operation, so
> >     the commit could succeed, but the following push could fail,
> >     leaving your repository out of sync
> 
> That's true: we need to uncommit if the push fails.
> BTW, we could/should make this case very rare by adding a pre-commit
> hook which makes sure that we're up-to-date before we can commit.

That's not a job for a pre-commit hook, IMO.  I think "C-x v v" should
pull before the push, and if there are conflicts, the next "C-x v v"
should do what needs to be done in that case, probably an other commit.

> >   . it will be hard (or even impossible) to do a local commit without
> >     pushing, because the hook will always be run; you need the local
> >     commit for when you merge and resolve conflicts and in other
> >     situations
> 
> I don't see why Richard (or someone in his situation) would ever need to
> do a local commit.

I think you forget commits after a conflict resolution, e.g. after a
merge from another branch.  I'm sure there are more situations like
that.  I don't think we can assume that absolutely _every_ commit can
do a push upstream.

Re: VC mode and git

[Stefan Monnier]

>> >   . using the script, the commit+push are not an atomic operation, so
>> >     the commit could succeed, but the following push could fail,
>> >     leaving your repository out of sync
>> That's true: we need to uncommit if the push fails.
>> BTW, we could/should make this case very rare by adding a pre-commit
>> hook which makes sure that we're up-to-date before we can commit.
> That's not a job for a pre-commit hook, IMO.

Why not?  That would avoid the kind of state Richard go into, IIUC.
That's also what Bzr would do on a bound branch.

>> I don't see why Richard (or someone in his situation) would ever need to
>> do a local commit.
> I think you forget commits after a conflict resolution, e.g. after a
> merge from another branch.

No I don't (you had already mentioned it in the text I quoted).
There's no reason why these commits should be local.

> I'm sure there are more situations like that.  I don't think we can
> assume that absolutely _every_ commit can do a push upstream.

Bzr bound branches did just that and it's never been a problem
(i.e. --local was only ever needed for offline operation).


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rms@gnu.org,  esr@thyrsus.com,  emacs-devel@gnu.org,  schwab@linux-m68k.org,  tsdh@gnu.org
> Date: Fri, 27 Mar 2015 13:58:54 -0400
> 
> >> >   . using the script, the commit+push are not an atomic operation, so
> >> >     the commit could succeed, but the following push could fail,
> >> >     leaving your repository out of sync
> >> That's true: we need to uncommit if the push fails.
> >> BTW, we could/should make this case very rare by adding a pre-commit
> >> hook which makes sure that we're up-to-date before we can commit.
> > That's not a job for a pre-commit hook, IMO.
> 
> Why not?

The explanation was in the part that you elided.

> That would avoid the kind of state Richard go into, IIUC.

Not if there are merge conflicts when pulling.

> That's also what Bzr would do on a bound branch.

Git ain't no bzr.

> >> I don't see why Richard (or someone in his situation) would ever need to
> >> do a local commit.
> > I think you forget commits after a conflict resolution, e.g. after a
> > merge from another branch.
> 
> No I don't (you had already mentioned it in the text I quoted).
> There's no reason why these commits should be local.

IMO, it makes no sense to push them right away.  It would violate the
"commit complete changesets" rule.

> > I'm sure there are more situations like that.  I don't think we can
> > assume that absolutely _every_ commit can do a push upstream.
> 
> Bzr bound branches did just that and it's never been a problem
> (i.e. --local was only ever needed for offline operation).

Git ain't no bzr.

Re: VC mode and git

[Tak Kunihiro]

>>   . it will be hard (or even impossible) to do a local commit without
>>     pushing, because the hook will always be run; you need the local
>>     commit for when you merge and resolve conflicts and in other
>>     situations
> 
> I don't see why Richard (or someone in his situation) would ever need to
> do a local commit.

As you say when I use vc-mode in school, no local commit is needed
because we use git regardless git or subversion.  However,
occasionally I want to get benefit of local commit via command line,
like when I am on a long flight above Pacific ocean.

Re: VC mode and git

[Stefan Monnier]

> As you say when I use vc-mode in school, no local commit is needed
> because we use git regardless git or subversion.  However,
> occasionally I want to get benefit of local commit via command line,
> like when I am on a long flight above Pacific ocean.

Then you'd temporarily comment out the commit-hook.
Or you'd refine the hook somehow so you can inhibit it sometimes (not
sure what kind of info those hooks receive, but in the worst case you
could say that the presence of a .git/LOCAL_COMMITS file would mean to
skip the hooks, or the hooks could check your ifconfig output to guess
that you probably want an local commit).


        Stefan

Re: VC mode and git

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

  > I don't see why Richard (or someone in his situation) would ever need to
  > do a local commit.

I agree, it is fine if there is no way to do so
in this mode of use.

-- 
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: VC mode and git

[Yann Hodique]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

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

>> > The reason to make this change is to help people who are not
>> > sophisticated git users.

>> For those people it is even more important that vc does not push by
>> default.

> With all due respect, I think you are mistaken.  C-x v v pushes by
> default with CVS and with Bzr, and that has never been a problem.  Why
> would it be a problem with Git when it is not a problem with the
> others?

Arguably, C-x v v *never* pushes. What it does instead is always *record*
a commit object in the source of truth for commit objects.
Depending on the VCS that means different places:
- in CVS, that source of truth is a server (and that's not pushing,
  since the commit object doesn't exist elsewhere)
- in Bzr, it is the local repository, but depending on Bzr config it might
  - result in Bzr (not VC) automatically pushing to a remote location,
    if you're operating on a bound branch
  - stay local in the other cases (which is how people typically use Bzr)
- in Git, it is also the local repository (and while there is no
  bound-branches, they can be simulated via hooks, which is also VCS-side
  configuration)
Bottom-line, in CVS there is a source of truth per project, and in
DVCSes there is also (at least) one per developer.
Admittedly, those sources are generally *partially* re-synchronized from
time to time, but that does not make it the same situation.

If some projects (like Emacs) operate in a more centralized manner,
that's fine. But the VCS configuration (per project) is the right place
to accomodate that, not the global VC client.

The way we look at push is as a brand-new operation, not even something
that was done automatically by commit in the old days.
The reason being that there is absolutely no 1:1 relationship between
those operations:
- a push generally covers multiple commits (as in "look, my set of
  carefully crafted commits finally looks good enough to be published")
- "the" place to push to might not exist, or might not be unique (and
  this is generally not discoverable)

As others, I believe any attempt to automatically push will result in
more confusion from users than benefits (especially since the current
generation is pretty much DVCS-native). I also think we should not
encourage users to develop bad habits/expectations by artificially
keeping alive the assumption that there is always a central place where
all commits have to live.

my 2¢

Yann.

-- 
Nature commits no errors; right and wrong are human categories.

  -- PARDOT KYNES, Arrakis Lectures

Re: VC mode and git

[Yuri Khan]

On Wed, Mar 25, 2015 at 8:43 PM, Richard Stallman <rms@gnu.org> wrote:

> The reason to make this change is to help people who are not
> sophisticated git users.

And teach them bad habits along the way? Please don’t.

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 10:43:13 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, esr@thyrsus.com, emacs-devel@gnu.org
> 
>   > > Why cannot VC determine whether a branch is private or not?
> 
>   > A branch can be both at the same time.
> 
> People who are doing such sophisticated things will understand the
> issues and can use whatever interface to specify what they want.

They are the majority nowadays.  A feature that helps a tiny minority,
but gets in the way of the rest will not be well accepted.

We need to find a way to do this more intelligently, keeping in mind
more than just one workflow.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Why cannot VC determine whether a branch is private or not?

It can determine whether a branch is a tracking branch or not, but
that's not really the question you're asking (and the question you're
asking is the one others have given you the answer to).

> I'm not saying I think "C-x v v" should push -- I don't -- but the
> reason you bring up doesn't sound as a serious one.

For me 'C-x v v' attempting to push would be a serious annoyance.  

If it was made configurable it would be one of the first things I would
have to change in a fresh emacs and if it wasn't made configurable, I
would have to fork vc-git.el and probably start with the version befor
the change was introduced.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 25 Mar 2015 09:48:47 +0100
> 
> > I'm not saying I think "C-x v v" should push -- I don't -- but the
> > reason you bring up doesn't sound as a serious one.
> 
> For me 'C-x v v' attempting to push would be a serious annoyance.  

OK, so you don't need it (and mostly use magit anyway).  But that's
still not a reason to dismiss it as an optional feature for others.
There are legitimate use cases for something like that, under certain
conditions, at least in Emacs development workflow.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> OK, so you don't need it (and mostly use magit anyway).  But that's
> still not a reason to dismiss it as an optional feature for others.

Am I allowed to say that I think this is the wrong place to add
complexity and effort in vc-git.el?

And can I say that I think people will be better off, by accepting that
commit and push are two separate operations in git?

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 25 Mar 2015 22:01:09 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > OK, so you don't need it (and mostly use magit anyway).  But that's
> > still not a reason to dismiss it as an optional feature for others.
> 
> Am I allowed to say that I think this is the wrong place to add
> complexity and effort in vc-git.el?
> 
> And can I say that I think people will be better off, by accepting that
> commit and push are two separate operations in git?

Am I allowed to say that you are wrong?

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Am I allowed to say that you are wrong?

Of course you are.

(But as far as I'm concerned, vc-git.el has one really big issue and I
think that's where the effort should be put Bug#8756)

Re: VC mode and git

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

  > And can I say that I think people will be better off, by accepting that
  > commit and push are two separate operations in git?

It is for you to say whether having them separate makes you better off.
It is not for you to say whether other people should accept this
or change it instead.

-- 
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: VC mode and git

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

  > > I think that C-x v v, when it commits changes, should also push them.
  > > This would make git more comparable to other version control systems.
  > > 
  > > Does anyone see a reason not to?

  > Yes. It would mean VC mode could not be used to work on private development
  > branches.

No it wouldn't.  It would mean that some other little feature would be
needed for private development branches.

Why present an easily-address wrinkle as if it were an insuperable problem?

  > An important part of many DVCs workflows is that you can make experimental 
  > changes that users of whatever shared repository your pushes go to don't see.

I generally don't commit a change until I am ready to install it.  But
if you want to commit changes locally, it is easy to set up ways to do
that.  For instance, set a flag in that directory which would say
"don't push automatically".

-- 
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: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Why present an easily-address wrinkle as if it were an insuperable problem?

Because it reveals that you don't understand the problem space yet.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

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

  > > Why present an easily-address wrinkle as if it were an insuperable problem?

  > Because it reveals that you don't understand the problem space yet.

Unless you substantiate that, it is mere name-calling again.  So far,
there is no substantiation.  It seems that some people would rather
dismiss the issue than LOOK for a good solution.

-- 
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: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>   > Because it reveals that you don't understand the problem space yet.
> 
> Unless you substantiate that, it is mere name-calling again.

This thread has been loaded to the gills with substantiation.  You
refuse to hear it.  Having learned over the years to recognize when
you have talked yourself into an immovable position, I officially give
up. I have more productive uses for my time than trying to
out-stubborn you.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

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

  >   Having learned over the years to recognize when
  > you have talked yourself into an immovable position, I officially give
  > up.

Thank you very much.

-- 
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: VC mode and git

[Paul Eggert]

On 03/24/2015 08:57 AM, Richard Stallman wrote:
> C-x v v, when it commits changes, should also push them.

Others have mentioned problems with that proposal.  One other thing: I 
guess that the proposal arose from your hassles with a bad ChangeLog 
merge as discussed in the recent "git is screwed" thread. Similar 
hassles have occurred since we switched to git, and we do need something 
better here.  I am planning to implement a different way of addressing 
these hassles, a way that doesn't suffer from the problems that others 
mentioned with altering C-x v v.  The basic idea is that an ordinary 
commit logs their ChangeLog entries only in its commit message, so that 
ordinary commits do not need to alter or merge ChangeLog files.  There 
is a process for generating and fixing up ChangeLogs, which can be done 
only as needed (e.g., just before a release).  For details, please see 
the patch near the end of Bug#19113:

http://bugs.gnu.org/19113#119

This patch works for me, and I plan to convert the Emacs master branch 
to it soon.  I'll send emacs-devel a heads-up warning about it about a 
week before I make the change.  It would be nice if others tested it, as 
everybody has their own habits when dealing with Git and I expect others 
will run into glitches after this is rolled out.  (I hope the glitches 
are smaller than the hassles you've been dealing with....)

Re: VC mode and git

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

  > One other thing: I 
  > guess that the proposal arose from your hassles with a bad ChangeLog 
  > merge as discussed in the recent "git is screwed" thread.

No, it arose from the fact that I committed changes previously and
they did not get beyond my machine.

This is not about ChangeLog in particular.  This is about making VC
handle git as it handles bzr and cvs.

As a separate matter, something is wrong in my repository with
lisp/ChangeLog.  I have changes I want to check in, and I don't know
what to do.  Brief hints are not enough to enable me to fix this.
How should I get my changes installed?

Would you please help me?

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 10:43:00 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> As a separate matter, something is wrong in my repository with
> lisp/ChangeLog.  I have changes I want to check in, and I don't know
> what to do.  Brief hints are not enough to enable me to fix this.
> How should I get my changes installed?
> 
> Would you please help me?

Someone asked for you to provide the output of the following Git
command:

  git status -s

This is an important first step towards understanding what exactly is
wrong in your local repository.  I very much doubt that any advice
that doesn't take the results of the above command in account could be
possibly correct.

So please provide that output, and let's take it from there.

Re: VC mode and git

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

  > Someone asked for you to provide the output of the following Git
  > command:

  >   git status -s

I transfer email in batches and I am generally responding to
yesterday's mail.  A delay of a day or more is inherent in this.

This morning, Thursday in Manila, I received the original message
asking for the output of git status -s today, and I wrote a message
with the data.  I have not sent out mail since then.  You will
probably receive it around the time you get this message.

It is no use pressing me to answer a question soon if I have not even
seen it yet.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 06:57:21 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> It is no use pressing me to answer a question soon if I have not even
> seen it yet.

Sorry, I didn't mean to press, I just thought that maybe that request
drowned in the flood of the other messages.

Re: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
>
> As a separate matter, something is wrong in my repository with
> lisp/ChangeLog.  I have changes I want to check in, and I don't know
> what to do.  Brief hints are not enough to enable me to fix this.
> How should I get my changes installed?
>
> Would you please help me?

Why did you not take my advice on that other thread to post the output 
of “git status -s” to the list? I bet there are many people able to 
help, but giving step by step advice based on too little information is 
dangerous and could lead you into further trouble.

Here is a sample output from “git status -s”, after I made some 
frivolous changes:

; git s
## master...origin/master
MM ChangeLog
M  README
  M lisp/mail/rmail.el

Here, README is changed and staged for commit (it's in the index), 
lisp/mail/rmail.el is changed but not staged for commit, and Changelog 
is changed and staged for commit, then changed again and the new change 
is not staged for commit. (Staging for commit is typically done by “git 
add”.)

It is also useful to know if you have any local commits. Assuming you 
are on the master branch, you can run

   git log origin/master..master

If it produces no output, then you have no local commits that are not in 
the remote branch. If you do, more work is required to recover.

It is POSSIBLE that a safe way to recover from your problems is as follows:

   git stash
   git reset --hard HEAD
   git pull --ff-only
   git stash apply

but I don't want to be the guy who goes down in history as the one who 
caused you to lose your changes because you followed this advice.

Maybe, if someone with more git experience reads this and says it is 
good, you should go ahead. Of course, if any of the commands but the 
last fails, stop and ask for advice again. If the last one reports merge 
conflicts, fix them by hand and run “git add” on each file after you 
fixed it. DO NOT use C-x v v after fixing a merge conflict, since that 
runs both git add and git commit, and you are not ready for the latter 
until all merge conflicts are dealt with.

In any case, do run git status before finally doing git commit. If all 
succeeds, you can clean up with

   git stash drop

– Harald

Re: VC mode and git

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

  > Why did you not take my advice on that other thread to post the output 
  > of “git status -s” to the list?

You have to give me time!  When you were rebuking me for not
responding to your first message, I had not even SEEN it.

-- 
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: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
> You have to give me time!  When you were rebuking me for not
> responding to your first message, I had not even SEEN it.

Sorry. I now remember that you are off line quite a bit.

– Harald

Re: VC mode and git

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

  > > You have to give me time!  When you were rebuking me for not
  > > responding to your first message, I had not even SEEN it.

  > Sorry. I now remember that you are off line quite a bit.

It's no big deal, but it was useful to remind people of the automatic
delays in my email.

Thank you for trying to helping me unwedge my repository.
I have not yet had a chance to try to really do it -- too much travel etc.

-- 
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: VC mode and git

[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 also useful to know if you have any local commits. Assuming you 
  > are on the master branch, you can run

  >    git log origin/master..master

Here's the output I got from that.

WARNING: terminal is not fully functional
-  (press RETURN)
commit dca743f0941909a80e3f28c023977120b6203e20
Author: Richard M. Stallman <rms@gnu.org>
Date:   Sun Mar 22 03:51:55 2015 -0400

    Recognize more format variation.  Automatically reshow decrypted text.
    
    * 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.
    
    * lisp/mail/rmail.el (rmail-show-message-1): When displaying a mime message,    indicate start and finish in the echo area.

commit 1a80be15bb1974d454cf37bcd1bd1be64e2cb488
Author: Richard M. Stallman <rms@gnu.org>
Date:   Sun Mar 22 03:45:03 2015 -0400

    Echo area shows when displaying a mime message.
    
    * lisp/mail/rmail.el (rmail-show-message-1): When displaying a mime message,    indicate start and finish in the echo area.

commit 414e79feeb445dc141b65767dfc3ba8dbb55723c
Author: Richard M. Stallman <rms@gnu.org>
Date:   Sun Mar 22 03:39:21 2015 -0400

    Prefer IceCat to Firefox and Iceweasel.
    
    * lisp/net/browse-url.el (browse-url-firefox-program): Prefer IceCat, doc.
    (browse-url-firefox-arguments)
    (browse-url-firefox-startup-arguments): Doc fix.
rms@rms:~/emacs-git/emacs$ 
-- 
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: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
>    >  It is also useful to know if you have any local commits. Assuming you
>    >  are on the master branch, you can run
>
>    >     git log origin/master..master
>
> Here's the output I got from that.
 > […]

Okay, so you have done some local commits. That complicates things 
somewhat, but not hopelessly so. It is essential knowledge for proper 
recovery, though.

– Harald

Re: VC mode and git

[Harald Hanche-Olsen]

I have a few more minutes. Here is a rough outline of a course of 
action. It is good if someone else is willing to review these suggestions.

Run “git diff -- lisp/ChangeLog”.

If the output looks sane, run

git add lisp/ChangeLog
git commit

But don't try to push it yet! That will fail. Run:

git checkout -b badmerge
git checkout master
git reset --hard origin/master
git checkout -b rms dca743f0941909a80e3f28c023977120b6203e20

Now, if all that went well, your master branch is back in sync with the 
remote, you have the result of your bad merge in the badmerge branch, 
and you have your latest good commit on the rms branch.

If I have understood correctly, only your changes to lisp/ChangeLog are 
now missing from the rms branch. To fix that, do

git checkout badmerge
# copy your additions to lisp/ChangeLog and save them somewhere safe
git checkout rms
# edit lisp/ChangeLog, putting in your additions
git commit -a # or just use C-x v v

Now all your local changes are safely in the “rms” branch.

If all is well so far, you need to update your master branch:

git checkout master
git pull --ff-only

And now you can do one of two things:

One is (assuming you're still on master)

git merge rms
git push

And if all is well, you're done!
You may now wish to clean up by removing the badmerge and rms branches.

If you have merge conflicts, DON'T ever use C-x v v after resolving 
conflicts in a single file. Instead, just do git add on the files as you 
are fixing them, and commit when done with all of them.

An alternative route is to rebase  your rms base on the current tip of 
the master branch, but that is beyond my experience.

– Harald

Re: VC mode and git

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

Having stashed my changes, I tried 'git pull'.  It said that the merge failed
and reported conflicts in lisp/ChangeLog.

I fixed those by hand, and tried various ways to proceed from there.
I tried to commit lisp/ChangeLog with C-x v v in that file
and got an error that partial commits are not allowed in the middle of a
merge.

You had recommended

    git add lisp/ChangeLog
    git commit

so I tried that.  git add completed with no output.
git commit showed me a monster list of files with
changes to be committed, and asked me for the log message.
I killed it.

What next?

I know one way to get out of this.  I can extract my changes by hand,
from the files ChangeLog says I had changed.  Then I can delete this
repository and make another to use to install these changes.

I could make another repository each time I need to install something.
But cvs was much more convenient.

-- 
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: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
> You had recommended
>
>      git add lisp/ChangeLog
>      git commit
>
> so I tried that.  git add completed with no output.
> git commit showed me a monster list of files with
> changes to be committed, and asked me for the log message.
> I killed it.
>
> What next?

That monster list of files is expected. If I am right, it reflects the 
changes made to origin/master, that is the central repository, *relative 
to your local master branch*.

So go ahead and commit. Give it a random commit message if you wish.
I promise you, you can back out of this if needed. I'll tell you how 
below, in fact.

Next, run: git diff origin/master

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.

Assuming this is so, you will have fallen behind the central repo, so 
you need once more to do

git pull
# fix conflicts, if any
git push

and your're done.

Assuming you're still concerned because the output of that git diff 
command is not what you expected, here is what to do:

git branch wtf

That will create a new branch named “wtf” (you can call it something 
less offensive if you wish) to use for further diagnostics and recovery 
efforts. It will be identical to your now current master branch. Then

git reset --hard master^

That will reset the master branch right back where you had it before the 
last commit, but it will now be in a clean state. All the changes that 
were in your index and working tree are still in the “wtf” branch. At 
this point, ask for further help. I am going to suggest, if it comes to 
this, that you push the “wtf” branch to a temporary branch on the 
central repo so that more eyeballs can get on the case and make an 
accurate diagnosis.

– Harald

Re: VC mode and git

[Steinar Bang]

>>>>> Harald Hanche-Olsen <hanche@math.ntnu.no>:

> So go ahead and commit. Give it a random commit message if you wish.

It's a merge commit, so letting the default message stand is probably
the best.

Re: VC mode and git

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

Thank you.  I think I have installed my changes.

How fragile and complicated git is.

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> How fragile and complicated git is.

Fully in the spirit of Emacs.

Andreas.

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

Re: VC mode and git

[Alan Mackenzie]

Hello, Andreas.

On Sun, Apr 05, 2015 at 08:58:56PM +0200, Andreas Schwab wrote:
> Richard Stallman <rms@gnu.org> writes:

> > How fragile and complicated git is.

> Fully in the spirit of Emacs.

That was quite uncalled for, and fully unjustified.

Emacs is usable at a naive level[*], it is well documented, and it is
robust.  It does not chew up users' data, and even if it did, would not
cause a 700-post thread on a mailing list in the course of recovering
that data.

[*] For a simple text document, you can get by with self-inserting keys,
the arrow keys, <del>, <backspace>, <CR>, C-x C-f, C-x C-s, C-x C-c, C-g
and possibly C-/.

> Andreas.

> -- 
> Andreas Schwab, schwab@linux-m68k.org

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

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

  > > How fragile and complicated git is.

  > Fully in the spirit of Emacs.

Emacs is not fragile.  Emacs has lots of complexity, which users can
learn or ignore.  Git requires users to learn its complexity when it
breaks due to its fragility.

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > How fragile and complicated git is.
>
>   > Fully in the spirit of Emacs.
>
> Emacs is not fragile.

It is.  You can shoot yourself in the foot quite easily.

Andreas.

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

Re: VC mode and git

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

  > > Emacs is not fragile.

  > It is.  You can shoot yourself in the foot quite easily.

Please stop insulting Emacs.  It is not true.

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > Emacs is not fragile.
>
>   > It is.  You can shoot yourself in the foot quite easily.
>
> Please stop insulting Emacs.  It is not true.

It's not an insult.  Any sufficiently powerful system can shoot itself
in the foot.

Andreas.

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

Re: VC mode and git

[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's not an insult.  Any sufficiently powerful system can shoot itself
  > in the foot.

Emacs does that if you do strange things.  The ordinary simple things
are simple and reliable.

-- 
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: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
> How fragile and complicated git is.

Complicated, sure. But fragile? I am not so sure.
Apart from commands like git reset --hard, it seems very difficult to 
actually lose data with git. But it is possible to get into a state 
which is hard to get out of, as you (we all) have discovered.

Apropos of that, I have a question for the git experts out there.
If you read the glossary, you will find that the index can hold three 
versions of the same file. This happens only, I believe, with a merge 
that had conflicts. The stash, on the other hand, seems to be just a 
sort of temporary commit, where you can put things to get them out of 
the way and retrieve them afterwards.

 From this it is my guess that stashing in the middle of a merge with 
conflicts is not safe, as the stash is not capable of holding multiple 
versions of a single file. Or am I wrong about that? I have not been 
able to find out by reading the documentation, but perhaps I have been 
looking in the wrong place.

This concern is one reason I asked Richard at one point about the output 
of “git ls-tree -u”. When it turned out to be empty, I was much relieved.

– Harald

Re: VC mode and git

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:
> Apropos of that, I have a question for the git experts out there.
>[…]
>  From this it is my guess that stashing in the middle of a merge with
> conflicts is not safe, as the stash is not capable of holding multiple
> versions of a single file. Or am I wrong about that?

It appears I have stumbled upon the answer here:
http://git.661346.n2.nabble.com/quot-fatal-git-write-tree-error-building-trees-quot-from-git-stash-td7573736.html
That post contains this bit:

$ git stash
foo: needs merge
foo: needs merge
foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
fatal: git-write-tree: error building trees
Cannot save the current index state

So git stash will very visibly fail in this situation.
And that is good to know. (Lookm there is that “error building trees” 
message again!)

– Harald

Re: VC mode and git

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

This means that you can't undo 'git stash pop' with 'git stash'.
'git stash pop' is therefore a risky thing to do.

-- 
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: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> This means that you can't undo 'git stash pop' with 'git stash'.
> 'git stash pop' is therefore a risky thing to do.

Not really. If "git stash pop" fails, git will leave the stash in place.

So if you reset your workspace with "git reset --hard HEAD" the stash
will still be there (and will still fail when applied, because of
conflicts). 

Re: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
> I know one way to get out of this.  I can extract my changes by hand,
> from the files ChangeLog says I had changed.  Then I can delete this
> repository and make another to use to install these changes.

That is way too drastic.

For one, if you run

git diff f1cea3e dca743f

then you will have all the changes you made since you checked out master 
a long time ago (f1cea3e) until your third commit (dca743f) on March 22. 
If I got it correctly, that is all the changes you have made, with the 
exception of changes to lisp/ChangeLog. (But I am not sure you made no 
other changes after that third commit. Are you?)

That output of git diff should be suitable as an input to patch, if you 
are so inclined. But I don't think it will come to that. As a last ditch 
maneuver, though, consider this possibility:

git reset --hard origin/master
git pull
git diff f1cea3e dca743f | patch -p1
# edit lisp/Changelog
git commit -a
git push

(Though I think git has better builtin commands than the above pipeline 
into patch; I just don't know them.)

In any case, the reason I recommend that you commit in the situation you 
are now in, is that it gives you much more freedom to explore the 
situation. With uncommitted changes in the index and/or work tree, your 
hands are tied to some extent (which is one reason git stash exists).

 > I could make another repository each time I need to install something.
 > But cvs was much more convenient.

The usual answer to this is to use development branches instead of 
workin directly in the master branch. I think it was decided not to 
recommend these for simple workflows, but I don't think it is that much 
harder, and it is certainly easier than having separate repositories.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 14:43:21 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>  > I could make another repository each time I need to install something.
>  > But cvs was much more convenient.
> 
> The usual answer to this is to use development branches instead of 
> workin directly in the master branch. I think it was decided not to 
> recommend these for simple workflows, but I don't think it is that much 
> harder, and it is certainly easier than having separate repositories.

It also requires to use at least one more command ("git merge"), and
brings additional risks, like if you pull to or push from the wrong
branch.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Sun, 05 Apr 2015 14:43:21 +0200
>> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>> The usual answer to this is to use development branches instead of
>> workin directly in the master branch. I think it was decided not to
>> recommend these for simple workflows, but I don't think it is that much
>> harder, and it is certainly easier than having separate repositories.
>
> It also requires to use at least one more command ("git merge"),

Yup. However, you will not encounter any difficulties arising from this 
that you do't already encounter with “git pull”.

> and
> brings additional risks, like if you pull to or push from the wrong
> branch.

But without extra configuration or explict arguments on the command 
line, that is not going to happen:

; git checkout -b test
Switched to a new branch 'test'
; git pull
remote: Counting objects: 113, done.
remote: Compressing objects: 100% (63/63), done.
remote: Total 63 (delta 57), reused 0 (delta 0)
Unpacking objects: 100% (63/63), done.
 From git://git.savannah.gnu.org/emacs
    fdc5219..bf81946  master     -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

     git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

     git branch --set-upstream-to=origin/<branch> test

; git push
fatal: The current branch test has no upstream branch.
To push the current branch and set the remote as upstream, use

     git push --set-upstream origin test

;

– Harald

Re: VC mode and git

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:
> Eli Zaretskii wrote:
>> It also requires to use at least one more command ("git merge"),
>
> Yup. However, you will not encounter any difficulties arising from this
> that you do't already encounter with “git pull”.

To be specific, this is the workflow I had in mind:

git checkout master # in case you're not already there
git pull # to stay reasonably current
git checkout -b hack master

You are now on a branch called “hack”, which is a copy of the master 
branch. Hack away, commit as you see fit, and when all satisfied, push 
it all by doing this:

(If at this point you have uncommitted changes that you do not wish to 
checkin yet, run “git stash” to put them aside.)

git checkout master
git pull
git merge hack
git push

– possibly pausing to fix any merge conflicts along the way.

Once the merge and push have succeeded, you can delete the hack branch:

git branch -d hack

And if you had stashed some uncommited changes earlier, start over:

git checkout -b hack master
git stash pop
# fix merge conflicts, if any, then continue hacking

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 15:32:57 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Harald Hanche-Olsen wrote:
> > Eli Zaretskii wrote:
> >> It also requires to use at least one more command ("git merge"),
> >
> > Yup. However, you will not encounter any difficulties arising from this
> > that you do't already encounter with “git pull”.
> 
> To be specific, this is the workflow I had in mind:

Thanks.  The recommended workflow with branches is already described
on the Wiki, here:

  http://www.emacswiki.org/emacs/GitForEmacsDevs

Feel free to suggest improvements for that, but other than that, I
think one workflow with branches should be enough for an introduction;
after that, people should find their own ways.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>
> Thanks.  The recommended workflow with branches is already described
> on the Wiki, here:
>
>    http://www.emacswiki.org/emacs/GitForEmacsDevs

Right; I've been teaching grandmother to suck eggs. Sorry about that.

> Feel free to suggest improvements for that, but other than that, I
> think one workflow with branches should be enough for an introduction;
> after that, people should find their own ways.

I notice that you recommend merging master into the task branch, not the 
other way around, as I indicated. Which is fine.

But then we get to the “Merging Into the Upstream Master” section, and 
there I have some concerns.

There you merge the task branch into a freshly updated master. Given 
that you recently merged the other way, that merge could well be a 
fast-forward, which is also fine. But then a little later, you do a 
commit, but won't that usually fail, because you already have a clean 
working directory? That is, after all, the result of a successful merge, 
whether fast-forward or not.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 19:26:41 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> I notice that you recommend merging master into the task branch, not the 
> other way around, as I indicated. Which is fine.

(I didn't write that text.)

> But then we get to the “Merging Into the Upstream Master” section, and 
> there I have some concerns.
> 
> There you merge the task branch into a freshly updated master. Given 
> that you recently merged the other way, that merge could well be a 
> fast-forward, which is also fine. But then a little later, you do a 
> commit, but won't that usually fail, because you already have a clean 
> working directory? That is, after all, the result of a successful merge, 
> whether fast-forward or not.

This survived without changes since the bzr instructions were written.
With bzr, these merges both ways didn't matter.  Also, bzr doesn't
automatically commit a successful merge, while Git does, which might
explain what you see.

So I suspect that the instructions need to be revised to some degree,
to reflect the differences.  Feel free to suggest them, or simply edit
the page.

Thanks.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Harald Hanche-Olsen <hanche@math.ntnu.no>

 > > The usual answer to this is to use development branches instead
 > > of workin directly in the master branch. I think it was decided
 > > not to recommend these for simple workflows, but I don't think it
 > > is that much harder, and it is certainly easier than having
 > > separate repositories.
 > 
 > It also requires to use at least one more command ("git merge"),

You can pull from a branch in the same repo.  As far as I know,

    git pull . other

is the same as

    git merge other

(there may be some technical difference involving a tracking branch in
the case of pull).  Of course, you may consider that a separate
command since pull requires arguments that need not be specified for
master in a repo created by git clone.

 > and brings additional risks, like if you pull to or push from the
 > wrong branch.

It should be possible to use "git config" to set up per-branch
defaults that are correct.

I was going to suggest this workflow.  The problem in Richard's
workflow is that he probably expects that when he's working
simultaneously in different modules (some changes being coded, others
being beta-tested), he should be able to tweak them more or less
independently.  But then he'd need to make small "correction" commits
rather than amending the last commit, and cherrypick (or rebase
--interactive) to master for the push.  I imagine he'd consider that
inconvenient.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>,
>     eggert@cs.ucla.edu,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Mon, 06 Apr 2015 04:08:13 +0900
> 
>  > It also requires to use at least one more command ("git merge"),
> 
> You can pull from a branch in the same repo.  As far as I know,
> 
>     git pull . other
> 
> is the same as
> 
>     git merge other

There's also "git checkout", and maybe a few more.

I agree that separate long-lived changes are better kept in separate
branches, but we have seen several people who are familiar with Git
make silly mistakes that involved two branches, so I'm not sure we
should suggest separate branches to people who want to be as close to
CVS as possible.

>  > and brings additional risks, like if you pull to or push from the
>  > wrong branch.
> 
> It should be possible to use "git config" to set up per-branch
> defaults that are correct.
> 
> I was going to suggest this workflow.  The problem in Richard's
> workflow is that he probably expects that when he's working
> simultaneously in different modules (some changes being coded, others
> being beta-tested), he should be able to tweak them more or less
> independently.  But then he'd need to make small "correction" commits
> rather than amending the last commit, and cherrypick (or rebase
> --interactive) to master for the push.  I imagine he'd consider that
> inconvenient.

Probably.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> I agree that separate long-lived changes are better kept in separate
> branches, but we have seen several people who are familiar with Git
> make silly mistakes that involved two branches, so I'm not sure we
> should suggest separate branches to people who want to be as close to
> CVS as possible.

I was going to ask what sort of silly mistake that might be, but then I 
thought of one myself: Creating a new branch off the emacs-24 branch, 
then merging that into the master branch. Or vice versa. It's easily 
done, and likely to wreak havoc on savannah. Perhaps the risk can be 
minimized by naming the task branch either master-something or 
emacs-24-something, to give a clear indication of where it belongs.

– Harald

Re: VC mode and git

[Steinar Bang]

>>>>> Harald Hanche-Olsen <hanche@math.ntnu.no>:

> I was going to ask what sort of silly mistake that might be, but then
> I thought of one myself: Creating a new branch off the emacs-24
> branch, then merging that into the master branch.

Since emacs-24 is ancestral to master, that probably won't be too bad.
The other way will be worse.

Re: VC mode and git

[Yuri Khan]

On Sun, Apr 5, 2015 at 6:43 PM, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:

> git diff f1cea3e dca743f | patch -p1
>
> (Though I think git has better builtin commands than the above pipeline into
> patch; I just don't know them.)

This is spelled “git cherry-pick f1cea3e..dca743f”, although it will
also put you into conflict resolution mode if conflicts occur.

> git reset --hard origin/master
> git pull
> git diff f1cea3e dca743f | patch -p1
> # edit lisp/Changelog
> git commit -a

This is roughly equivalent to fetching and then rebasing the branch
containing f1cea3e..dca743f onto origin/master. (If f1cea3e and
dca743f are more than one commit apart, your recipe would combine them
into a single commit. To achieve the same effect in Git, one uses “git
rebase --interactive” with the “squash” or “fixup” action.)

Re: VC mode and git

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

  >  > I could make another repository each time I need to install something.
  >  > But cvs was much more convenient.

  > The usual answer to this is to use development branches instead of 
  > workin directly in the master branch. I think it was decided not to 
  > recommend these for simple workflows, but I don't think it is that much 
  > harder, and it is certainly easier than having separate repositories.

The reason I am leaning towards making a repository each time
I have a change to install is that it might --work-- to install
changes if I do it with a new 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: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> The reason I am leaning towards making a repository each time I have a
> change to install is that it might --work-- to install changes if I do
> it with a new repository.

My guess is that the risk for conflict would be about the same, except
for the inconvenience of making a new repository and installing the
changes manually.

Re: VC mode and git

[Paul Eggert]

Richard Stallman wrote:
> The reason I am leaning towards making a repository each time
> I have a change to install is that it might --work-- to install
> changes if I do it with a new repository.

This is a reasonable approach to take with Git, if one wants to install changes 
carefully without detailed understanding of Git.  I use this approach myself at 
times.  Currently on my main development machine I have 79 Emacs repositories; 
although most of them are inactive I've used at least 17 of them this year -- 
probably more, as every now and then I delete some of them.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 11:22:05 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> Richard Stallman wrote:
> > The reason I am leaning towards making a repository each time
> > I have a change to install is that it might --work-- to install
> > changes if I do it with a new repository.
> 
> This is a reasonable approach to take with Git, if one wants to install changes 
> carefully without detailed understanding of Git.  I use this approach myself at 
> times.  Currently on my main development machine I have 79 Emacs repositories; 
> although most of them are inactive I've used at least 17 of them this year -- 
> probably more, as every now and then I delete some of them.

As others have pointed out, using a separate repository each time does
not guarantee that these problems will not happen.  It definitely
cannot guarantee you against problems with pushing, due to someone
else's pushing between the time you clone a new repository and the
time you are ready for pushing your commits.

When a push fails, you need to pull again, and then you might need to
handle the conflicts during the pull, of the same kind Richard bumped
into.

So I think this kind of workflow doesn't save one from any problems
you might encounter with a single clone.  It definitely has a
disadvantage of cloning the repository each time, which involves
moving 400MB through the wire, and takes many minutes.

Re: VC mode and git

[Paul Eggert]

Eli Zaretskii wrote:
> As others have pointed out, using a separate repository each time does
> not guarantee that these problems will not happen.

Of course it doesn't.  But it does solve RMS's problem that he has a repository 
that's in a bad state, and wants to get back to a good state where he can commit 
and push changes, without losing any of the work in his current repository. 
It's a simple approach that doesn't require deep understanding of Git.

> It definitely has a
> disadvantage of cloning the repository each time, which involves
> moving 400MB through the wire, and takes many minutes.

No, not at all.  It takes 1.5 seconds on my 5-year-old desktop (just hard 
drives, no flash), and the only bytes that need to go across the wire are the 
ones containing commits that others made to Savannah since the last time you 
resynchronized; these are bytes that would need to go across the wire under any 
method.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 11:46:04 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > As others have pointed out, using a separate repository each time does
> > not guarantee that these problems will not happen.
> 
> Of course it doesn't.  But it does solve RMS's problem that he has a repository 
> that's in a bad state, and wants to get back to a good state where he can commit 
> and push changes, without losing any of the work in his current repository. 

That's a one-time problem.  The situation that caused it could very
well happen again, and the workflow should include procedures to
handle that.  I thought Richard was contemplating the idea of cloning
a fresh repository every time he wanted to push some changes, so my
reaction was to that possibility, not to a one-time fix.

> It's a simple approach that doesn't require deep understanding of Git.

"Simple" is in the eyes of the beholder.  I think without a good
understanding it is impossible to come up with such a procedure, but
that's me.

Re: VC mode and git

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

  >   I thought Richard was contemplating the idea of cloning
  > a fresh repository every time he wanted to push some changes, so my
  > reaction was to that possibility, not to a one-time fix.

Yes, that was what I was thinking my recourse would have to be.
However, perhaps 'git reset --hard HEAD' is equivalent to that.
It worked this time.  Whether it will work in general, I don't know.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 01:50:42 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
>   >   I thought Richard was contemplating the idea of cloning
>   > a fresh repository every time he wanted to push some changes, so my
>   > reaction was to that possibility, not to a one-time fix.
> 
> Yes, that was what I was thinking my recourse would have to be.
> However, perhaps 'git reset --hard HEAD' is equivalent to that.
> It worked this time.  Whether it will work in general, I don't know.

It should work in general, but I hope you will never again get
yourself into the kind of mess you had this time.

I hope the improved instructions on the Wiki will keep you and others
from that trouble.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> As others have pointed out, using a separate repository each time does
> not guarantee that these problems will not happen.  […]
>
> So I think this kind of workflow doesn't save one from any problems
> you might encounter with a single clone.  It definitely has a
> disadvantage of cloning the repository each time, which involves
> moving 400MB through the wire, and takes many minutes.

That could be helped by using shallow clones, though. You only ever need 
a full clone if you wish to examine old history, and you could keep just 
one full clone for that purpose, while having many shallow clones for 
hacking.

If the clone is *too* shallow, I imagine you could get in trouble with 
merge operations, though. I am not sure about this, but the merge based 
workflow used seems to produce a history with several parallel branches 
much of the time, and that could force a merge operation to look further 
back than you might expect to find a common ancestor to use as a basis 
for merging. This is pure speculation on my part, though. If one ever 
runs into this problem, it is easily remedied by running git fetch 
--depth=n with some suitable n, but it is a potential complication with 
this approach.

– Harald

Re: VC mode and git

[Steinar Bang]

>>>>> Harald Hanche-Olsen <hanche@math.ntnu.no>:

> That could be helped by using shallow clones, though. You only ever
> need a full clone if you wish to examine old history, and you could
> keep just one full clone for that purpose, while having many shallow
> clones for hacking.

Local full clones start out as hardlinks to the original repository.
They will diverge over time, but initially they are quite cheap.

Re: VC mode and git

[Harald Hanche-Olsen]

Steinar Bang wrote:
>>>>>> Harald Hanche-Olsen<hanche@math.ntnu.no>:
>
>> That could be helped by using shallow clones, though. You only ever
>> need a full clone if you wish to examine old history, and you could
>> keep just one full clone for that purpose, while having many shallow
>> clones for hacking.
>
> Local full clones start out as hardlinks to the original repository.
> They will diverge over time, but initially they are quite cheap.

But they require some more setting up, as you need to adjust the remote 
tracking behaviour of the new clones. For those who know how, that is 
indeed a better solution.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 05:11:07 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Having stashed my changes, I tried 'git pull'.  It said that the merge failed
> and reported conflicts in lisp/ChangeLog.
> 
> I fixed those by hand, and tried various ways to proceed from there.
> I tried to commit lisp/ChangeLog with C-x v v in that file
> and got an error that partial commits are not allowed in the middle of a
> merge.

"C-x v v" does the wrong thing in this situation: it attempts to
commit that single file, lisp/ChangeLog in your case.  Git will not
allow you to do that when you are in the middle of a merge.  That
merge is the second part of what "git pull" does (the first part is
fetching the last changes from upstream).  Normally, if the merge
succeeds, Git automatically commits the result, but in this case it
failed, and the merge was suspended.

Since you are in the middle of a merge, you need to commit
_everything_ that awaits to be committed, after resolving the
conflicts.  This includes the stuff Git successfully merged, and the
single file where it failed and left it to you to resolve the
conflicts.  To commit everything, you need to issue "git commit"
without any file-name arguments from the shell prompt, or 'v' from the
vc-dir buffer.

> You had recommended
> 
>     git add lisp/ChangeLog
>     git commit
> 
> so I tried that.  git add completed with no output.
> git commit showed me a monster list of files with
> changes to be committed, and asked me for the log message.
> I killed it.

You should have let it proceed: that long list of files are the
changes from upstream that Git succeeded in merging, and which await
to be committed.  I would use "Fix pull conflicts" as the log message.

You can still do that, since you are now exactly in the same situation
you were before the "git commit" command.  Just type it again.

> I know one way to get out of this.  I can extract my changes by hand,
> from the files ChangeLog says I had changed.  Then I can delete this
> repository and make another to use to install these changes.

Yes, that's one way.  It is not the best one, though.

> I could make another repository each time I need to install something.
> But cvs was much more convenient.

I wrote up simple procedures, very similar to what you did with CVS,
on the Wiki.  While writing, I tried to follow a CVS procedure as
close as possible; I wonder whether that succeeded.

Please read http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs
and see if what's there now keeps you out of trouble.

Re: VC mode and git

[Paul Eggert]

On 03/25/2015 07:43 AM, Richard Stallman wrote:
> something is wrong in my repository with
> lisp/ChangeLog.  I have changes I want to check in, and I don't know
> what to do.  Brief hints are not enough to enable me to fix this.
> How should I get my changes installed?
>
> Would you please help me?

Here's a method that should work.  It's slow and painstaking but each 
step should be easy to follow, which is the main thing.

* Decide the changes that you want and record them, e.g., by putting 
them into a file 'wanted.diff':

   git diff >wanted.diff

* Apparently your copy of the master branch is busted, so rename it to 
something else so that it's out of the way:

   git branch -m master master-busted

* Create a new branch 'master' that tracks the origin:

   git branch --track master origin/master

* Check it out, discarding all your local changes (be careful here! the 
local changes should all be in 'wanted.diff'):

   git checkout -f master

* Make sure the master is up-to-date:

   git pull

* Apply the changes that you want to your working files, e.g.:

   patch -p1 <wanted.diff
   [Fix any problems by hand.]

* Use 'git diff' to make sure the patch is what you want.  If not, fix 
problems by hand and run 'git diff again.

* Commit the result:

   git commit -a -m'Fix lisp/ChangeLog'

* Double-check that the commit (including its log message) is really 
what you want, by inspecting the output of:

   git format-patch --stdout -1

* Push the patch, so that others can see it:

   git push

Re: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I think that C-x v v, when it commits changes, should also push them.

Definitely not.  I don't want to publish my local commits.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Sebastien Vauban]

Andreas Schwab wrote:
> Richard Stallman <rms-mXXj517/zsQ@public.gmane.org> writes:
>
>> I think that C-x v v, when it commits changes, should also push them.
>
> Definitely not.  I don't want to publish my local commits.

I think that the real conclusion of the discussion is: shouldn't vc-dir
have a command to push?  And, to that, I guess most of us would answer
yes, right?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: VC mode and git

[Eli Zaretskii]

> From: Sebastien Vauban <sva-news@mygooglest.com>
> Date: Tue, 24 Mar 2015 20:05:33 +0100
> 
> I think that the real conclusion of the discussion is: shouldn't vc-dir
> have a command to push?  And, to that, I guess most of us would answer
> yes, right?

A related question is: does "C-x v v" at all make sense with Git and
other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
would it make sense for "C-x v v" to push when the previous action was
commit and there are not uncommitted changes?

Re: VC mode and git

[Daniel Colascione]

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

On 03/24/2015 12:15 PM, Eli Zaretskii wrote:
>> From: Sebastien Vauban <sva-news@mygooglest.com>
>> Date: Tue, 24 Mar 2015 20:05:33 +0100
>>
>> I think that the real conclusion of the discussion is: shouldn't vc-dir
>> have a command to push?  And, to that, I guess most of us would answer
>> yes, right?
> 
> A related question is: does "C-x v v" at all make sense with Git and
> other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
> would it make sense for "C-x v v" to push when the previous action was
> commit and there are not uncommitted changes?

C-x v v should never push. That would be too surprising to user used to
working locally.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 12:29:46 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: emacs-devel@gnu.org
> 
> C-x v v should never push. That would be too surprising to user used to
> working locally.

Users whose workflow is not DWIM should never use "C-x v v".

Re: VC mode and git

[Daniel Colascione]

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

On 03/24/2015 12:51 PM, Eli Zaretskii wrote:
>> Date: Tue, 24 Mar 2015 12:29:46 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: emacs-devel@gnu.org
>>
>> C-x v v should never push. That would be too surprising to user used to
>> working locally.
> 
> Users whose workflow is not DWIM should never use "C-x v v".

C-x v v doesn't push today, so current users don't mean "push".


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Nicolas Richard]

Daniel Colascione <dancol@dancol.org> writes:
> On 03/24/2015 12:51 PM, Eli Zaretskii wrote:
>>> From: Daniel Colascione <dancol@dancol.org>
>>> C-x v v should never push. That would be too surprising to user used to
>>> working locally.
>> 
>> Users whose workflow is not DWIM should never use "C-x v v".
>
> C-x v v doesn't push today, so current users don't mean "push".

C-x v v could ask confirmation before pushing, and then offer to
customize an option for not asking the confirmation again.

-- 
Nicolas

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Users whose workflow is not DWIM should never use "C-x v v".

"DWIM" is not a partial function with values of "I" bound to "Eli
Zaretskii" (and not "RMS", for that matter).  And in fact, many users
have more than one workflow.  If you're a core developer on one
project, and J. Random Committer on another, you may have a rather
branchy workflow on one, and a "lots of one-off commit-and-pushes"
workflow on the other.

It never hurts to commit more often than you push, and many DVCS users
take advantage of that capability.  Currently C-x v v serves both "I
only commit when I push" and "commit early, commit often" workflows.
It doesn't serve the former as well as it could.  But if you make the
change Richard proposed, it doesn't serve the latter at all.

If you make the "if uncommitted changes then commit else push" change,
I suspect it will embarrass users of branchy workflows frequently.
Currently C-x v v is a no-op if there are no uncommitted changes.  With
the proposed change in workflow, it will push what is most likely an
in-progress state of the tree.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Daniel Colascione <dancol@dancol.org>,
>     sva-news@mygooglest.com,
>     emacs-devel@gnu.org
> Date: Wed, 25 Mar 2015 09:41:07 +0900
> 
> It never hurts to commit more often than you push, and many DVCS users
> take advantage of that capability.  Currently C-x v v serves both "I
> only commit when I push" and "commit early, commit often" workflows.
> It doesn't serve the former as well as it could.  But if you make the
> change Richard proposed, it doesn't serve the latter at all.

I'm way beyond what Richard proposed, please read the rest of the
thread.

We could support the "commit much more often" workflows by having an
option that determines whether and when to try pushing after a commit,
one of the values could be 'never'.

> If you make the "if uncommitted changes then commit else push" change,
> I suspect it will embarrass users of branchy workflows frequently.
> Currently C-x v v is a no-op if there are no uncommitted changes.  With
> the proposed change in workflow, it will push what is most likely an
> in-progress state of the tree.

Given an option, users can control that, I think.

Also, a recent suggestion was to "git show" and offer a push from that
display, instead of just pushing.  Perhaps that's better, as it allows
a decision point.

Re: VC mode and git

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Wed, 25 Mar 2015 05:45:07 +0200

   We could support the "commit much more often" workflows by
   having an option that determines whether and when to try
   pushing after a commit, one of the values could be 'never'.

I think in practice many people will set this to ‘never’ and
then continue "manual push" (whether it be in the form of a
future ‘vc-push’ or as a shell command invocation).  Furthermore
when the weirdness happens for slightly-misaligned functionality
for those users who do not set it to ‘never’, those users will
be less likely to report problems and follow through w/ their
resolutions than to query the net.wisdom and finally move to the
‘never’ camp, washing their hands of the mess once and for all.
Thus, long term, such a feature will be underused, undertested
and definitely underappreciated.

So my lazy-maintainer spidey-sense tells me that, rather than
adding an imperfect heuristic layer, it would be better to add a
primitive (i.e., ‘vc-push’) and let people invoke it as part of
their personal (and IME instance-specific!) post-commit workflow
by the standard means (keyboard macro, hook, advice).

In this way, the hacking we encourage will be likewise addative,
instead of deconstructive and ultimately ignorant.

[recips clamped]

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: VC mode and git

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Wed, 25 Mar 2015 08:21:47 +0100
> 
>    We could support the "commit much more often" workflows by
>    having an option that determines whether and when to try
>    pushing after a commit, one of the values could be 'never'.
> 
> I think in practice many people will set this to ‘never’ and
> then continue "manual push"

I see nothing wrong with that.  DWIM-ish operation is not for
everybody, certainly for a package as flexible as Git.

The relevant question is: would this be useful in enough use cases to
justify the feature, at least as an option?

> Thus, long term, such a feature will be underused, undertested
> and definitely underappreciated.

Please note how you put 3 assumptions one on top of the other, and
then made a conclusion out of that, which is basically founded on
nothing but your own experience and preferences.

> So my lazy-maintainer spidey-sense tells me that, rather than
> adding an imperfect heuristic layer, it would be better to add a
> primitive (i.e., ‘vc-push’) and let people invoke it as part of
> their personal (and IME instance-specific!) post-commit workflow
> by the standard means (keyboard macro, hook, advice).

What exactly would be the difference between the proposed vc-push and
invoking "git push" via M-! ?

Re: VC mode and git

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Wed, 25 Mar 2015 19:27:43 +0200

   I see nothing wrong with that.  DWIM-ish operation is not for
   everybody, certainly for a package as flexible as Git.

I agree, nothing wrong.  Still, not as nice as it could be.
Probably in younger days, i would have said: "Lame".

   The relevant question is: would this be useful in enough use
   cases to justify the feature, at least as an option?

I think the time when people would respect VC imposing its
unified model on the underlying VCS is past.  When they were all
centralized, such an imposition lifted the burden of having to
remember fiddly details such as command-line options.  But the
schism between centralized and distributed is here, and here to
stay, and so a unified model spanning these models now is an
impediment to fully exploiting the tools.  It's a lose/lose
situation when DWIM must straddle disparate M based on disparate
models.

That said, within any particular camp (cent or dist), some
unification is still possible (and desirable).  But the thrust
should be away from DWIM and towards clean primitives exposed
directly to the user.  Centralized camp is already happy.
Distributed is only one lacuna away from happiness (IMHO).

So to answer the question: IMHO, no.

   > Thus, long term, such a feature will be underused,
   > undertested and definitely underappreciated.

   Please note how you put 3 assumptions one on top of the
   other, and then made a conclusion out of that, which is
   basically founded on nothing but your own experience and
   preferences.

Noted.

I have only those to offer, made w/ my limited and imperfect
understanding of other human beings, and those are offered in
the best good faith way possible.  I'm sorry i can't do better.

   What exactly would be the difference between the proposed
   vc-push and invoking "git push" via M-! ?

Well, the following is not exact, but i bet if ‘vc-push’ were to
appear, it would become so (i.e., Someone might Write Code).  :-D

I suppose there could be options, e.g., like how ‘vc-diff’ has
‘vc-diff-switches’.  Also, commands are nice places for hooks.
I imagine a brach-display buffer (e.g., ‘M-x git-show-branch’ i
posted some time back) could be updated via such a hook.

All these possibilities are absent from the meager ‘M-!’ path.

Anyway, i'll sit down now.  RMS: i hope you can move your pov.

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: VC mode and git

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Wed, 25 Mar 2015 23:31:18 +0100
> 
>    The relevant question is: would this be useful in enough use
>    cases to justify the feature, at least as an option?
> 
> I think the time when people would respect VC imposing its
> unified model on the underlying VCS is past.

I'm not talking about imposing some model, I'm talking about
recognizing useful and frequent patterns, and then codifying those in
"C-x v v".  See below for the patterns I can easily identify.

Besides, if someone feels "C-x v v" is not for them, they can just
refrain from using it.  That command certainly isn't imposing itself
on users, does it?

> When they were all centralized, such an imposition lifted the burden
> of having to remember fiddly details such as command-line options.

That's not my understanding of the "C-x v v" usefulness.  IMO, it has
very little to do with "centralized".  It had much more to do with the
fact that there is a particular order/pattern of VC commands one needs
to perform while working on changes.  Look at the doc string of
vc-next-action, and you will see that pattern clearly identified for
RCS.

A dVCS, IMO, makes this single-pattern approach too limited, because a
dVCS enables many more workflows that were unavailable with RCS and
its ilk.  But that doesn't mean there are no patterns at all, or that
the patterns are limited to what vc-next-action currently supports for
a dVCS.  Again, if you read the doc string for "merging-based version
control systems", whatever that means, you will, I think, agree that
vc-next-action is next to useless for a modern dVCS, because it
basically always commits and does nothing else.

> But the schism between centralized and distributed is here, and here
> to stay, and so a unified model spanning these models now is an
> impediment to fully exploiting the tools.

The lack of a _single_ pattern doesn't mean there are no patterns at
all.  Here's what I do all the time in Emacs maintenance, when I need
to make a change that is a single one-off job I expect to take an hour
or so:

  . git pull
  # make changes, build, fix errors, test, fix bugs, write logs
  . git pull
  . if new files added:
    . git add NEW-FILES...
  . git status -s
  . git commit -a
  . git show
  . if I found some deficiency in the commit, looking at "git show" display:
    . git reset HEAD^
    # fix whatever needs fixing
    . git commit -a
    . git show # verify all is OK now
  . git push
  . if push rejected:
    . git pull
    . if conflicts found:
      . fix conflicts
      . git commit -a
  . git show
  . git push

I see a clear, non-trivial pattern here that is useful enough to have
vc-next-action remember it for me.  I also am quite sure I'm not the
only one who uses this pattern, perhaps with minor deviations.

There are other useful patterns, e.g., when I work on a larger feature
on a separate branch.  As long as I just make changes and commit them,
the pattern is

   # make changes, build, fix errors, test
  . if new files added:
    . git add NEW-FILES...
  . git status -s
  . git commit -a

Once I want to land the feature on a public branch, there's another
pattern, something like

  . git checkout master
  . git pull
  . git merge FEATURE
  . if there are conflicts:
    # resolve conflicts
    . git add FILES-THAT-CHANGED
  . git status -s
  . git commit
  . git show
  . git push

Etc. etc. -- the only difference is that there are several widely used
patterns instead of just one.

Why can't vc-next-action support these patterns?  If it needs to be
told which pattern to use, that can be solved by a simple command that
is unlikely to be needed too frequently, and so is not an annoyance.

> It's a lose/lose situation when DWIM must straddle disparate M based
> on disparate models.

I don't see where this could lose, and so I don't share your
pessimism.  Having such patterns is certainly a win for people who
don't commit/push changes frequently enough to have the patterns burnt
into their finger memory, because even the simplest patterns are much
more complex with a dVCS than they were with RCS, see above.

And I didn't even start talking about a plight of someone who needs to
use more than one VCS.  Contemporary projects use Git, SVN, and
Mercurial, so remembering the subtly different semantics of their
commands is a burden, especially if you use some of them rarely.
That's where vc-next-action could shine.

> That said, within any particular camp (cent or dist), some
> unification is still possible (and desirable).  But the thrust
> should be away from DWIM and towards clean primitives exposed
> directly to the user.  Centralized camp is already happy.
> Distributed is only one lacuna away from happiness (IMHO).

I see no "centralized vs distributed" schism here.  What I see is the
need to generalize DWIM in a useful way for the modern VCSes.  Having
several DWIM patterns switchable by user commands seems to be one such
useful generalization.  Maybe we could even do better by having VC
intuit the pertinent pattern(s) for at least some cases and suggest
them, or default to them unless told otherwise.

IOW, vc-next-action, IMO, is about making complex, but routine tasks
easier on users, by serving as a substitute for their (absent) finger
memory.  I think having this would be a Good Thing, and is certainly
not impossible.  Patches are welcome, as always.

Re: VC mode and git

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

  > C-x v v should never push. That would be too surprising to user used to
  > working locally.

On the contrary, when it fails to push, that is inconsistent with the
behavior of C-x v v with other VC systems, and very susprising to a user
who normally uses the others.  VC check-in should store into the central
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: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 10:42:36 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, sva-news@mygooglest.com, emacs-devel@gnu.org
> 
> VC check-in should store into the central repository.

This must be optional, because there are widely used workflows where
pushing every commit is not what the user wants.

Re: VC mode and git

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

  > > VC check-in should store into the central repository.

  > This must be optional, because there are widely used workflows where
  > pushing every commit is not what the user wants.

We should have all the options anyone wants.
I'm talking about the default behavior for C-x v v.

  > The notion of "commit" from RCS/CVS/SVN 

Also Bzr.  When I was editing Emacs sources using Bzr, C-x v v
sent all my changes to the repository on Savannah.

Perhaps this is because I made a "bound branch".  I used Bzr that way
because I wanted the same simple behavior that I had had with CVS.
With Bzr, that was possible.  Why shouldn't it be possible with Git?

					    doesn't scale well to Git.

Could you explain what the obstacle is?  I don't see it.

I have made a local Git repository cloned from the one at Savannah.
Supposedly 'git push' would send the changes back to Savannah.  What
is the conceptual difficulty in having C-x v v work with Git just as
it did with Bzr -- commit and push?


-- 
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: VC mode and git

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>   > The notion of "commit" from RCS/CVS/SVN 
>
> Also Bzr.  When I was editing Emacs sources using Bzr, C-x v v
> sent all my changes to the repository on Savannah.
>
> Perhaps this is because I made a "bound branch".  I used Bzr that way
> because I wanted the same simple behavior that I had had with CVS.
> With Bzr, that was possible.  Why shouldn't it be possible with Git?

It is possible with Git. For Tramp, I'm in the same situation like you:
it is hosted in a Git repository on savannah, and I want my local
commits performed by C-x v v being pushed immediately.

The trick is to tell Git that. I have added locally a small script
.../tramp/.git/hooks/post-commit

#!/bin/sh
git push origin master

... and now I am happy.

Best regards, Michael.

Re: VC mode and git

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Also Bzr.  When I was editing Emacs sources using Bzr, C-x v v
> sent all my changes to the repository on Savannah.
> 
> Perhaps this is because I made a "bound branch".  I used Bzr that way
> because I wanted the same simple behavior that I had had with CVS.
> With Bzr, that was possible.  Why shouldn't it be possible with Git?

This makes your position more understandable.  Bzr bound branches were
a kind of amphibian designed to emulate the way a centralized VCS
works.  They enabled you to retain the mental habits of such systems,
at the cost of making much of the rest of what a DVCS can actually do
rather inconvenient - but you don't notice the latter, precisely
because you've retained those mental habits.

The reason you're getting so much pushback is that most other people
here (including me) have adjusted to the DVCS view of the world, in
which "commit" and "repository sync" are very different operations and
the act of recording a changeset is deliberately separated from the
act of publishing it.  We regard this as a feature.

Nobody can make you change your mind.  Speaking as VC's designer I'm
not *entirely* opposed to adding a switch to make it behave the way
you want, though I don't think it would be a better idea than if
you got your mind in better sync with the way DVCSes actually
work.

But changing the default...that would be a bad idea.  That would be
trying to distort all DVCSes into a CVS-like shape. I won't do that, it
would make too many other people unhappy for what I consider to be
no good reason.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[John Yates]

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

I am not a vc user.  I find magit far more helpful.

That said I took a look at vc.el.  Interestingly it has a
vc-checkin command but neither vc-push nor vc-commit.  From
this I surmise that at the time vc.el acquired support for
the DVCS model the choice was made to map vc-checkin to the
local commit operation and leave it to the DCVS backends to
provide a command to push to the central repository.

Though too much water may have flowed under the bridge to
revisit that choice it seems to me an alternative would have
been to preserve vc-checkin as the command that pushed one's
work to the central repository, leaving it to DCVS backends
to support the new concept of committing locally.

/john

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

Re: VC mode and git

[Alexis]

Eric S. Raymond <esr@thyrsus.com> writes:

> Nobody can make you change your mind.  Speaking as VC's designer 
> I'm not *entirely* opposed to adding a switch to make it behave 
> the way you want, though I don't think it would be a better idea 
> than if you got your mind in better sync with the way DVCSes 
> actually work.
>
> But changing the default...that would be a bad idea.  That would 
> be trying to distort all DVCSes into a CVS-like shape. I won't 
> do that, it would make too many other people unhappy for what I 
> consider to be no good reason.

My guess is that, if such a setting /were/ made a default, there 
might well be a rash of people posting to places like 
StackExchange with issues like:

"Help! I thought git commit and push would always be two separate 
operations, and now, using VC, I've accidentally just pushed some 
local commits to the origin repo. How do i undo this, particularly 
before anyone else does a fetch or pull from that repo?"

And that, after being told how to unclobber the remote, it will be 
suggested to these people that they use magit instead. Which would 
be fine by me, since i'm a fan of magit; but it might not be so 
good for convincing people to use VC as their primary source 
control interface.


Alexis.

Re: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 07:59:34 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, sva-news@mygooglest.com,
> 	dancol@dancol.org, emacs-devel@gnu.org
> 
> Bzr bound branches were a kind of amphibian designed to emulate the
> way a centralized VCS works.

There's nothing centralized about bzr's bound branches: you could
still commit locally in such a branch, if you wanted.

Re: VC mode and git

[Eli Zaretskii]

> Date: Thu, 26 Mar 2015 06:57:07 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dancol@dancol.org, sva-news@mygooglest.com, emacs-devel@gnu.org
> 
>   > > VC check-in should store into the central repository.
> 
>   > This must be optional, because there are widely used workflows where
>   > pushing every commit is not what the user wants.
> 
> We should have all the options anyone wants.
> I'm talking about the default behavior for C-x v v.

Why should we care too much about the defaults?  We both know how to
customize Emacs, right?

Defaults should cater to what the majority of users want, and they
nowadays don't want to push automatically every commit.

>   > The notion of "commit" from RCS/CVS/SVN 
> 
> Also Bzr.  When I was editing Emacs sources using Bzr, C-x v v
> sent all my changes to the repository on Savannah.

Only because the branch was bound.  In an un-bound branch, bzr doesn't
automatically push.

Git lacks bound branches, so you cannot easily have the same
functionality.

> 					    doesn't scale well to Git.
> 
> Could you explain what the obstacle is?  I don't see it.

Quite simply, the separation between a commit and a push in Git is so
radical that you cannot reliably do them both in one go, at least IME.
E.g., what happens if the commit succeeds, but the push fails?  From
your POV of a "C-x v v" user, you are in a middle of something you are
used to think of as an atomic operation.  Where do you go to from
there?

> I have made a local Git repository cloned from the one at Savannah.
> Supposedly 'git push' would send the changes back to Savannah.  What
> is the conceptual difficulty in having C-x v v work with Git just as
> it did with Bzr -- commit and push?

Bazaar allowed a workflow that Git doesn't, that's why you could
maintain the illusion of a single operation in a bound branch.

Re: VC mode and git

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

  > > I have made a local Git repository cloned from the one at Savannah.
  > > Supposedly 'git push' would send the changes back to Savannah.  What
  > > is the conceptual difficulty in having C-x v v work with Git just as
  > > it did with Bzr -- commit and push?

  > Bazaar allowed a workflow that Git doesn't, that's why you could
  > maintain the illusion of a single operation in a bound branch.

This seems to be a serious flaw in Git.  People were so enthusiastic
about it.

  > > We should have all the options anyone wants.
  > > I'm talking about the default behavior for C-x v v.

  > Why should we care too much about the defaults?  We both know how to
  > customize Emacs, right?

If our recommendations for how to work on Emacs using Git
include the necessary customization, that could be sufficient
to solve the practical problem.

Dmitry Gutov <dgutov@yandex.ru> proposed 

    git push || git reset HEAD^

Does that work reliably?
-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 09:26:47 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: sva-news@mygooglest.com, dancol@dancol.org, emacs-devel@gnu.org
> 
>   > Bazaar allowed a workflow that Git doesn't, that's why you could
>   > maintain the illusion of a single operation in a bound branch.
> 
> This seems to be a serious flaw in Git.  People were so enthusiastic
> about it.

People who were enthusiastic about it generally didn't use (and didn't
like) the notion of the bound branch anyway.

Re: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > > Bazaar allowed a workflow that Git doesn't, that's why you could
 > > maintain the illusion of a single operation in a bound branch.
 > 
 > This seems to be a serious flaw in Git.

Hardly.  Use of bound branches has always been a minority taste.  As
somebody else commented, I'm surprised you of all people could stand
them, because you need to learn a non-default operation (commit
--local) to work disconnected.  Did you use "bzr commit --local", or
did you just not commit, if you're not connected to Savannah?

I'm not even sure what the semantics of bzr commit are in a bound
branch containing local commits (push all pending? but that's going to
be messy if the push fails).

 > If our recommendations for how to work on Emacs using Git include
 > the necessary customization, that could be sufficient to solve the
 > practical problem.

You have a practical problem: git behavior is not compatible with the
semantics you assign to "commit".  I don't see evidence that Emacs has
a practical problem, as a very large number of contributors have
successfully converted to the documented git workflow for Emacs.  A
few do complain, but most are just git-haters from the get-go, and the
problems reported on this list seem to be one-off, not created by the
recommended workflow.

 > Dmitry Gutov <dgutov@yandex.ru> proposed 
 > 
 >     git push || git reset HEAD^
 > 
 > Does that work reliably?

Not in the sense you mean.  It has deterministic semantics, but it
takes you to the state immediately after the penultimate commit, not
the state immediately before the ultimate commit.  These can differ,
for example if you've git add'ed, git rm'ed, or git mv'ed files in
between.  There may be other issues that would bother people looking
for an atomic commit-and-push operation.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     sva-news@mygooglest.com,
>     dancol@dancol.org,
>     emacs-devel@gnu.org
> Date: Sat, 28 Mar 2015 03:35:17 +0900
> 
> I'm not even sure what the semantics of bzr commit are in a bound
> branch containing local commits

Like if you committed all the local commits on a separate branch, and
then merged to mainline.  IOW, as you'd expect.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Eli Zaretskii <eliz@gnu.org>,
 > >     sva-news@mygooglest.com,
 > >     dancol@dancol.org,
 > >     emacs-devel@gnu.org

Is there a purpose to quoting the Cc?

 > > Date: Sat, 28 Mar 2015 03:35:17 +0900
 > > 
 > > I'm not even sure what the semantics of bzr commit are in a bound
 > > branch containing local commits
 > 
 > Like if you committed all the local commits on a separate branch, and
 > then merged to mainline.  IOW, as you'd expect.

But is that what Richard would expect?  In CVS you'd get the
equivalent of rebasing local on the updated mainline.  Maybe it
doesn't matter what Richard "expects", because he doesn't expect
anything: Richard just doesn't commit in that circumstance, I suppose
(still waiting on an answer at this point).

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sva-news@mygooglest.com,
>     dancol@dancol.org,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Sun, 29 Mar 2015 06:55:31 +0900
> 
> Eli Zaretskii writes:
> 
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
>  > > Cc: Eli Zaretskii <eliz@gnu.org>,
>  > >     sva-news@mygooglest.com,
>  > >     dancol@dancol.org,
>  > >     emacs-devel@gnu.org
> 
> Is there a purpose to quoting the Cc?

A bit too late to ask: Rmail has been doing that since about forever.

>  > > Date: Sat, 28 Mar 2015 03:35:17 +0900
>  > > 
>  > > I'm not even sure what the semantics of bzr commit are in a bound
>  > > branch containing local commits
>  > 
>  > Like if you committed all the local commits on a separate branch, and
>  > then merged to mainline.  IOW, as you'd expect.
> 
> But is that what Richard would expect?

He said he never used that.  I answered _your_ question, just so you
know what happens in that use case.

Re: VC mode and git

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

  > Hardly.  Use of bound branches has always been a minority taste.  As
  > somebody else commented, I'm surprised you of all people could stand
  > them, because you need to learn a non-default operation (commit
  > --local) to work disconnected.

I never had any problem working disconnected with Bzr.  I needed a
connection only to transfer to or from the repository on Savannah,
and that could hardly have been avoided.

  >  Did you use "bzr commit --local", or
  > did you just not commit, if you're not connected to Savannah?

I never did a local commit.  I did commits solely to put the files on
Savannah.

  > You have a practical problem: git behavior is not compatible with the
  > semantics you assign to "commit".

It is bad design of git.  The option of distributed use may be good,
but requiring people to think in such terms is a screw.

  >  I don't see evidence that Emacs has
  > a practical problem, as a very large number of contributors have
  > successfully converted to the documented git workflow for Emacs.

That is no reason to think it isn't a problem.  Others have stated
here that they find it a screw.

Those who want to think the Git way, by all means do so.  But the Git
for Emacs quick start page is meant for people like me.


-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sat, 28 Mar 2015 12:17:50 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: sva-news@mygooglest.com, eliz@gnu.org, dancol@dancol.org,
> 	emacs-devel@gnu.org
> 
> the Git for Emacs quick start page is meant for people like me.

Note that this page tells to push after a commit.

Re: VC mode and git

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

  > > the Git for Emacs quick start page is meant for people like me.

  > Note that this page tells to push after a commit.

Yes, it does -- but in the intervening weeks I forgot about that.

-- 
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: VC mode and git

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

  > Not in the sense you mean.  It has deterministic semantics, but it
  > takes you to the state immediately after the penultimate commit, not
  > the state immediately before the ultimate commit.  These can differ,
  > for example if you've git add'ed, git rm'ed, or git mv'ed files in
  > between.

That seems to be another gap in Git.  Its flexibility goes in certain
directions only.

-- 
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: VC mode and git

[Barry Warsaw]

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

On Mar 28, 2015, at 03:35 AM, Stephen J. Turnbull wrote:

>Hardly.  Use of bound branches has always been a minority taste.

I'm fairly certain bound branches sprang from a desire to make it easier for
users coming from centralized vcses (most specifically, svn) to switch to a
dvcs without having to change their basic workflow.  That bound branches are
even possible is due to architectural choices in bzr.

Having said that, I never used 'em myself.

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> A related question is: does "C-x v v" at all make sense with Git and
> other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
> would it make sense for "C-x v v" to push when the previous action was
> commit and there are not uncommitted changes?

That's an interesting idea.  And certainly doable.

Whether it's really DWIM depends on what workflow git's primitives are being
used to implement. It makes the most sense if the relationship between the
local and remote repo is the simplest one - the local repo is essentially
a cache for the remote, and nobody else pushes to that remote.

It makes less sense if other people are pushing to the remote.  You wander
into several complications here; one is that the remote may reject the push
due to it not being a fast-forward from the repo tip.  There are 
workflow-sensitive choices about what to do in this situation and thus no
one right thing for VC to do here.  

Accordingly, I'm opposed to it at this time.  But my mind could be changed
by a more detailed proposal generic across DVCSes under which the push
operation pays attention to some set of policy switches.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 15:56:38 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Sebastien Vauban <sva-news@mygooglest.com>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > A related question is: does "C-x v v" at all make sense with Git and
> > other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
> > would it make sense for "C-x v v" to push when the previous action was
> > commit and there are not uncommitted changes?
> 
> That's an interesting idea.  And certainly doable.
> 
> Whether it's really DWIM depends on what workflow git's primitives are being
> used to implement. It makes the most sense if the relationship between the
> local and remote repo is the simplest one - the local repo is essentially
> a cache for the remote, and nobody else pushes to that remote.
> 
> It makes less sense if other people are pushing to the remote.  You wander
> into several complications here; one is that the remote may reject the push
> due to it not being a fast-forward from the repo tip.  There are 
> workflow-sensitive choices about what to do in this situation and thus no
> one right thing for VC to do here.  

So perhaps there should be a defcustom that would switch between
several popular workflows, and "C-x v v" could then support each one
of them, when chosen.

Re: VC mode and git

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> So perhaps there should be a defcustom that would switch between
> several popular workflows, and "C-x v v" could then support each one
> of them, when chosen.

In principle, possible.

I'm concerned about our ability to anticipate all possible workflows
well enough to define a set of policy variables that wouldn't be more
straitjacket than help.  A likely outcome seems to be paying a lot of
complexity cost for little gain.

That doesn't mean I'm trying to prevent a design discussion, though.  
My misgivings could be wrong.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[chad]

> On 24 Mar 2015, at 12:15, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> A related question is: does "C-x v v" at all make sense with Git and
> other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
> would it make sense for "C-x v v" to push when the previous action was
> commit and there are not uncommitted changes?

Would a question like “No changes since your last commit; push last commit?” be good enough?

~Chad

Re: VC mode and git

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Tue, 24 Mar 2015 13:52:24 -0700
> 
> 
> > On 24 Mar 2015, at 12:15, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > A related question is: does "C-x v v" at all make sense with Git and
> > other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
> > would it make sense for "C-x v v" to push when the previous action was
> > commit and there are not uncommitted changes?
> 
> Would a question like “No changes since your last commit; push last commit?” be good enough?

I think it's better to have a silent DWIM-ish operation, if we can
find one.

Re: VC mode and git

[Jan D.]

Hi.

> 25 mar 2015 kl. 04:34 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> From: chad <yandros@gmail.com>
>> Date: Tue, 24 Mar 2015 13:52:24 -0700
>> 
>> 
>>> On 24 Mar 2015, at 12:15, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> A related question is: does "C-x v v" at all make sense with Git and
>>> other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
>>> would it make sense for "C-x v v" to push when the previous action was
>>> commit and there are not uncommitted changes?
>> 
>> Would a question like “No changes since your last commit; push last commit?” be good enough?
> 
> I think it's better to have a silent DWIM-ish operation, if we can
> find one.
> 

It depends on who is the I in DWIM.  For me, C-x v v already does DWIM, I would hat it if that changed.

	Jan D.

Re: VC mode and git

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 25 Mar 2015 07:07:33 +0100
> Cc: chad <yandros@gmail.com>, emacs-devel@gnu.org
> 
> > I think it's better to have a silent DWIM-ish operation, if we can
> > find one.
> > 
> 
> It depends on who is the I in DWIM.  For me, C-x v v already does DWIM, I would hat it if that changed.

I think everybody agrees that it should be an option, which could be
disabled, or even off by default.

Re: VC mode and git

[Jan D.]

> 25 mar 2015 kl. 18:24 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Wed, 25 Mar 2015 07:07:33 +0100
>> Cc: chad <yandros@gmail.com>, emacs-devel@gnu.org
>> 
>>> I think it's better to have a silent DWIM-ish operation, if we can
>>> find one.
>>> 
>> 
>> It depends on who is the I in DWIM.  For me, C-x v v already does DWIM, I would hat it if that changed.
> 
> I think everybody agrees that it should be an option, which could be
> disabled, or even off by default.

I don't.  I think there should be a separate vc-push command.

	Jan D.

Re: VC mode and git

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 25 Mar 2015 19:03:09 +0100
> Cc: yandros@gmail.com, emacs-devel@gnu.org
> 
> >> It depends on who is the I in DWIM.  For me, C-x v v already does DWIM, I would hat it if that changed.
> > 
> > I think everybody agrees that it should be an option, which could be
> > disabled, or even off by default.
> 
> I don't.  I think there should be a separate vc-push command.

We can (and probably should) have both.

Re: VC mode and git

[Eric S. Raymond]

Jan D. <jan.h.d@swipnet.se>:
> > I think everybody agrees that it should be an option, which could be
> > disabled, or even off by default.
> 
> I don't.  I think there should be a separate vc-push command.

I'm leaning that way myself.

For at least some front ends there already is a push command.  Perhaps
it needs to be made more prominent.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Stefan Monnier]

> I think everybody agrees that it should be an option, which could be
> disabled, or even off by default.

No, I don't think it's even worth an option.
We do want to support something like `vc-push', OTOH.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Jan D." <jan.h.d@swipnet.se>,  yandros@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 25 Mar 2015 14:21:29 -0400
> 
> > I think everybody agrees that it should be an option, which could be
> > disabled, or even off by default.
> 
> No, I don't think it's even worth an option.
> We do want to support something like `vc-push', OTOH.

There's no contradiction between these two.

The issue I raised was whether "C-x v v" makes sense for Git.  If all
it does is commit, then the answer is NO.  I'm not yet ready to give
up on the idea that we could make "C-x v v" do useful things with Git.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> I think it's better to have a silent DWIM-ish operation, if we can
> find one.

Asking would be annoying, "silent DWIM" is a really bad idea.

This would be the wrong place to put work on vc-git.el.

The place where it needs work is to make it track changes across
renames.

Re: VC mode and git

[Dmitry Gutov]

On 03/24/2015 09:15 PM, Eli Zaretskii wrote:

> A related question is: does "C-x v v" at all make sense with Git and
> other dVCSes?  If it does, what would be the DWIM cycle there?

It's only slightly difference from what we have. For VCSes with a 
staging area (which would have to be displayed separately), the cycle 
would be unstaged -> staged -> commit.

The details would need working out, though. Like, whether "C-x v v" 
would do something in a file buffer other than displaying the vc-dir buffer.

> E.g.,
> would it make sense for "C-x v v" to push when the previous action was
> commit and there are not uncommitted changes?

After a prompt, maybe, like Chad suggested. But I don't know if we want 
to make this too easy: after all, when ChangeLogs are auto-generated, it 
might be better to somehow force the user to review the changes and 
messages before pushing.

However, if the "push now?" action would support that, maybe it'll be a 
good combination.

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 23:18:01 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> > E.g.,
> > would it make sense for "C-x v v" to push when the previous action was
> > commit and there are not uncommitted changes?
> 
> After a prompt, maybe, like Chad suggested. But I don't know if we want 
> to make this too easy: after all, when ChangeLogs are auto-generated, it 
> might be better to somehow force the user to review the changes and 
> messages before pushing.

Then perhaps after a commit "C-x v v" should do a "git show", and
allow to push from the buffer that displays HEAD?

Re: VC mode and git

[Dmitry Gutov]

On 03/25/2015 05:36 AM, Eli Zaretskii wrote:

 > Then perhaps after a commit "C-x v v" should do a "git show", and
> allow to push from the buffer that displays HEAD?

Showing the last commit is not enough; the push command should account 
for all unpushed commits. Showing the messages of each, as well as 
diffstats (the lists of midified files) would be enough, I think. But an 
ability to quickly jump to each diff would be also valuable.

Magit deals with that by displaying a list of all local commits (just 
the summary lines) not yet pushed to the remove in a separate section in 
the magit-status buffer. Which is not bad, but we might prefer to show 
the full messages (and in a different buffer), to encourage the user to 
double-check for typos, etc, for the automated ChangeLog files.

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 17:33:14 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: sva-news@mygooglest.com, emacs-devel@gnu.org
> 
> On 03/25/2015 05:36 AM, Eli Zaretskii wrote:
> 
>  > Then perhaps after a commit "C-x v v" should do a "git show", and
> > allow to push from the buffer that displays HEAD?
> 
> Showing the last commit is not enough; the push command should account 
> for all unpushed commits. Showing the messages of each, as well as 
> diffstats (the lists of midified files) would be enough, I think. But an 
> ability to quickly jump to each diff would be also valuable.

I agree.

Re: VC mode and git

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

  >  > Then perhaps after a commit "C-x v v" should do a "git show", and
  > > allow to push from the buffer that displays HEAD?

  > Showing the last commit is not enough; the push command should account 
  > for all unpushed commits.

If C-x v v, in a default mode, does a push after commit, there will
only be one unpushed commit, unless there has been a failure of some
kind.

-- 
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: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> A related question is: does "C-x v v" at all make sense with Git and
> other dVCSes?

Yes, it does.

I use it on single file changes.  Related changes over multiple files, I
do from magit.

> If it does, what would be the DWIM cycle there?

Make a local commit, pointing to the previous commit of the current
branch and move the HEAD to this commit, and stop there.

> E.g., would it make sense for "C-x v v" to push when the previous
> action was commit and there are not uncommitted changes?

No.

Re: VC mode and git

[Sebastien Vauban]

Steinar Bang wrote:
>>>>>> Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org>:
>
>> A related question is: does "C-x v v" at all make sense with Git and
>> other dVCSes?
>
> Yes, it does.
>
> I use it on single file changes.  Related changes over multiple files,
> I do from magit.

Why that difference?  Why not committing multiple files with `vc-dir'?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: VC mode and git

[Steinar Bang]

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:

> Why that difference?  Why not committing multiple files with `vc-dir'?

Because I started using magit a long time ago, I can't remember if
vc-dir existed then, and if I tried it, but if I did I settled on magit.

Re: VC mode and git

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:
>> Why that difference?  Why not committing multiple files with `vc-dir'?

> Because I started using magit a long time ago, I can't remember if
> vc-dir existed then, and if I tried it, but if I did I settled on magit.

So I tried vc-dir now, some first impressions:
 - Key bindings are similar to magit, my fingers didn't need much
   re-training
 - vc-git seems faster than magit
 - vc-git doesn't group files in the way that magit does
   (ie. "Untracked", "Unstaged" and "Staged"), and I think I like
   magit's way better (vc-git is more similar to the way pcl-cvs and
   svn-status operated)
 - vc-git operates on the directory it's run, while magit skips up to
   the directory containing the .git directory and runs for there, and
   since I use magit-status as a way to look at the current status and
   move up to the top directory, the magit way works better for me
   (especially on Java projects, where 'M-x magit-status RET' updates the
   magit status and takes me to the top where I can use 'M-x compile' to
   do "mvn clean install")
 - The way vc-git shows the diffs for the commits in the commit list was
   a bit annoying: they are shown inline, and I couldn't figure out a
   way to close them. magit opens the diff in a new buffer, and that
   buffer can be exited with 'q', and I like the magit way better here also

Re: VC mode and git

[Stefan Monnier]

[ ...other points about vc-dir vs magit...  ]
>  - The way vc-git shows the diffs for the commits in the commit list was
>    a bit annoying: they are shown inline, and I couldn't figure out a
>    way to close them. magit opens the diff in a new buffer, and that
>    buffer can be exited with 'q', and I like the magit way better here also

I don't understand what you mean here by "shows the diffs for the
commits in the commit list" and "shown inline".


        Stefan

PS: Your comparison is much less critical of vc-dir than I'd have
    expected.  Personally I find that vc-dir is still pretty far from
    what PCL-CVS offered ten years ago, so while I use do it, I find it
    borderline unusable.

Re: VC mode and git

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

> I don't understand what you mean here by "shows the diffs for the
> commits in the commit list" and "shown inline".

The buffer shows a list of commits, one per each line, pressing enter of
a commit expands it, and shows the metadata of the commit.

Saying it shows the diff was wrong.  Also, I found out now how to close
it: just press RET again.  To display the diff, vc-dir, uses the same
command as magit, ie. 'd' (which opens the diff in a different buffer
that can be exited with 'q', which is the same behaviour as magit).

> PS: Your comparison is much less critical of vc-dir than I'd have
>     expected.  Personally I find that vc-dir is still pretty far from
>     what PCL-CVS offered ten years ago, so while I use do it, I find it
>     borderline unusable.

Well, I didn't try to actually *use* it... I just did a drive-by
evaluation by starting it on a repository, and just trying magit
commands blindly.  (Also, I tried to be nice...)

The most immediately annoying feature of vc-dir, was that it didn't
group the files into unstaged and staged, because that's a very
important distinction when manually resolving merge conflicts.

Re: VC mode and git

[Stefan Monnier]

>> I don't understand what you mean here by "shows the diffs for the
>> commits in the commit list" and "shown inline".
> The buffer shows a list of commits, one per each line, pressing enter of
> a commit expands it, and shows the metadata of the commit.

Ah, I see you're talking about the "log", I thought you were talking
about something that had to do with the "commit" operation.

> The most immediately annoying feature of vc-dir, was that it didn't
> group the files into unstaged and staged,

Indeed, this is a particular feature of Git, and vc-git hasn't figured
out how to integrate it in the generic UI of VC.
I tend not to use the index very heavily (I'm still a fairly young Git
user, evidently), so I don't suffer from it too much, but it's clearly
wrong (an obvious problem is when the file is modified in the index and
this modification is undone in the actual file, so "git diff HEAD --
<file>" is empty: then vc-dir will sometimes show the file as "up-to-date"
and sometimes as "modified").

> because that's a very important distinction when manually resolving
> merge conflicts.

Hmm... I never/rarely care about the index while resolving conflicts,
I just use smerge-mode and vc-find-next-conflicted-file and then commit
the result (and I do these kinds of commit from the command line rather
than from vc-dir).


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 25 Mar 2015 11:04:51 -0400
> 
> I tend not to use the index very heavily (I'm still a fairly young Git
> user, evidently), so I don't suffer from it too much, but it's clearly
> wrong (an obvious problem is when the file is modified in the index and
> this modification is undone in the actual file

That's because you are not radical enough in not-using the index.  I
never get to the situation where a file is modified in the index.  One
problem less.

(Of course, now I will be pounced upon by all the people who were
brainwashed to think the index is a good idea.  Please don't bother.)

Re: VC mode and git

[Alan Mackenzie]

Hello, Eli.

On Wed, Mar 25, 2015 at 08:03:17PM +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Wed, 25 Mar 2015 11:04:51 -0400

> > I tend not to use the index very heavily (I'm still a fairly young Git
> > user, evidently), so I don't suffer from it too much, but it's clearly
> > wrong (an obvious problem is when the file is modified in the index and
> > this modification is undone in the actual file

> That's because you are not radical enough in not-using the index.  I
> never get to the situation where a file is modified in the index.  One
> problem less.

> (Of course, now I will be pounced upon by all the people who were
> brainwashed to think the index is a good idea.  Please don't bother.)

The index (stupid name) is an extra layer of complexity.  Even the git
maintainers half-admit it's not (always) a good thing by allowing "git
commit -a".

I'm mystified as to what the git index is for.  What's its motivation,
what's it used for, what does it gain me in exchange for the extra
complexity?  Does anybody have a link to a justification?  I'm genuinely
curious about this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Yuri Khan]

On Thu, Mar 26, 2015 at 12:19 AM, Alan Mackenzie <acm@muc.de> wrote:

> I'm mystified as to what the git index is for.  What's its motivation,
> what's it used for, what does it gain me in exchange for the extra
> complexity?  Does anybody have a link to a justification?  I'm genuinely
> curious about this.

I view the index as a convenience.

The use case goes like this. I work on a feature. At the same time, I
notice some coding style violations, or bad spelling/grammar, or
possible enhancements unrelated to the feature.

Without using the index, I’d have to make a conscious effort to avoid
mixing feature-related work with all those other good and useful
modifications. Make notes on a piece of paper. Finish the feature
work, commit, then go over the notes, do a few more commits.

However, with the index, I can do all of these things as soon as I
feel the need. Then I call up the Magit status buffer which shows me
all unstaged changes. I go over them and stage only those that I want
to put in a single commit, e.g. all the spelling fixes. I make a
commit, then repeat with the reduced set of changes. With a single
key, I can stage all changes, or all changes to a single file, or an
individual hunk, or a selected region.

Occasionally, a line will be changed in two or more unrelated ways. At
this point, I have to go to the file buffer and temporarily edit the
line to have the form I want to commit. After staging, I undo the
change so the file in the working copy remains in its final form.

Bottom line: The index allows me to do several unrelated changes in
the working copy, then separate them in two or more commits.

Re: VC mode and git

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 26 Mar 2015 00:37:06 +0600
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> The use case goes like this. I work on a feature. At the same time, I
> notice some coding style violations, or bad spelling/grammar, or
> possible enhancements unrelated to the feature.
> 
> Without using the index, I’d have to make a conscious effort to avoid
> mixing feature-related work with all those other good and useful
> modifications. Make notes on a piece of paper. Finish the feature
> work, commit, then go over the notes, do a few more commits.

No, you can either:

  . start a new branch, and make all the unrelated changes there, or

  . stash your changes, make the unrelated changes, commit them, then
    pop the stash and continue

> Bottom line: The index allows me to do several unrelated changes in
> the working copy, then separate them in two or more commits.

There are other ways to do that without messing up your brain with the
index.

Re: VC mode and git

[Yuri Khan]

On Thu, Mar 26, 2015 at 12:49 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Without using the index, I’d have to make a conscious effort to avoid
>> mixing feature-related work with all those other good and useful
>> modifications. Make notes on a piece of paper. Finish the feature
>> work, commit, then go over the notes, do a few more commits.
>
> No, you can either:
>
>   . start a new branch, and make all the unrelated changes there, or
>
>   . stash your changes, make the unrelated changes, commit them, then
>     pop the stash and continue

Both these methods can work, but they break the flow even more than
making a note to get back to after committing.

>> Bottom line: The index allows me to do several unrelated changes in
>> the working copy, then separate them in two or more commits.
>
> There are other ways to do that without messing up your brain with the
> index.

By messing it up with other things.

Re: VC mode and git

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 26 Mar 2015 01:03:13 +0600
> Cc: Alan Mackenzie <acm@muc.de>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> >   . start a new branch, and make all the unrelated changes there, or
> >
> >   . stash your changes, make the unrelated changes, commit them, then
> >     pop the stash and continue
> 
> Both these methods can work, but they break the flow even more than
> making a note to get back to after committing.

No, they don't.

> >> Bottom line: The index allows me to do several unrelated changes in
> >> the working copy, then separate them in two or more commits.
> >
> > There are other ways to do that without messing up your brain with the
> > index.
> 
> By messing it up with other things.

No, because they use methods available with most other VCSes.

Re: VC mode and git

[Alan Mackenzie]

Hello, Yuri.

On Thu, Mar 26, 2015 at 12:37:06AM +0600, Yuri Khan wrote:
> On Thu, Mar 26, 2015 at 12:19 AM, Alan Mackenzie <acm@muc.de> wrote:

> > I'm mystified as to what the git index is for.  What's its motivation,
> > what's it used for, what does it gain me in exchange for the extra
> > complexity?  Does anybody have a link to a justification?  I'm genuinely
> > curious about this.

> I view the index as a convenience.

> The use case goes like this. I work on a feature. At the same time, I
> notice some coding style violations, or bad spelling/grammar, or
> possible enhancements unrelated to the feature.

> Without using the index, I’d have to make a conscious effort to avoid
> mixing feature-related work with all those other good and useful
> modifications. Make notes on a piece of paper. Finish the feature
> work, commit, then go over the notes, do a few more commits.

> However, with the index, I can do all of these things as soon as I
> feel the need. Then I call up the Magit status buffer which shows me
> all unstaged changes. I go over them and stage only those that I want
> to put in a single commit, e.g. all the spelling fixes. I make a
> commit, then repeat with the reduced set of changes. With a single
> key, I can stage all changes, or all changes to a single file, or an
> individual hunk, or a selected region.

Isn't this what branches are meant to be for?

> Occasionally, a line will be changed in two or more unrelated ways. At
> this point, I have to go to the file buffer and temporarily edit the
> line to have the form I want to commit. After staging, I undo the
> change so the file in the working copy remains in its final form.

> Bottom line: The index allows me to do several unrelated changes in
> the working copy, then separate them in two or more commits.

OK.  Thanks for the elucidation.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Yuri Khan]

On Thu, Mar 26, 2015 at 1:23 AM, Alan Mackenzie <acm@muc.de> wrote:

>> […] with the index, I can do all of these things as soon as I
>> feel the need. Then I call up the Magit status buffer which shows me
>> all unstaged changes. I go over them and stage only those that I want
>> to put in a single commit, e.g. all the spelling fixes. I make a
>> commit, then repeat with the reduced set of changes. With a single
>> key, I can stage all changes, or all changes to a single file, or an
>> individual hunk, or a selected region.
>
> Isn't this what branches are meant to be for?

Yes, the final result that I want is a set of unrelated series of
commits. The difference is how I arrive at that result.

Traditionally, one creates a branch, makes those and only those
modifications that are meant for that branch, commits, repeats until
ready.

Branch switching in Git is lightweight. But doing all modifications in
a single working copy avoids even that.

Of course, it only scales up to a certain extent. Too many unrelated
modifications become difficult to separate.

Re: VC mode and git

[Steinar Bang]

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

>> However, with the index, I can do all of these things as soon as I
>> feel the need. Then I call up the Magit status buffer which shows me
>> all unstaged changes. I go over them and stage only those that I want
>> to put in a single commit, e.g. all the spelling fixes. I make a
>> commit, then repeat with the reduced set of changes. With a single
>> key, I can stage all changes, or all changes to a single file, or an
>> individual hunk, or a selected region.

> Isn't this what branches are meant to be for?

Actually that sounds like what I do to get multiple commits on the same
branch.

I like to commit what logically belongs together and makes sensible
diffs with a sensible context, when following it later, typically from a
git blame.

Magit and the index, makes what Yuri describes, easy to do.

Re: VC mode and git

[Stefan Monnier]

> However, with the index, I can do all of these things as soon as I
> feel the need. Then I call up the Magit status buffer which shows me
> all unstaged changes. I go over them and stage only those that I want
> to put in a single commit, e.g. all the spelling fixes. I make a
> commit, then repeat with the reduced set of changes. With a single
> key, I can stage all changes, or all changes to a single file, or an
> individual hunk, or a selected region.

This means you only use the index to do partial commits.
This use-case is typically transient.
But the index is much more omnipresent.

IIUC one of the motivations for the index was also to handle situations
such as: I want to merge a change (with "git merge" or "git stash pop")
into a non-committed tree, and I don't want to commit before the merge
because the pending change is not clean enough (or some other reason).

In this case, a naive "git merge/unstash" would lose information, since
after the merge you get a tree with potential conflicts and no way to go
back to the before-merge state.  The problem here is that the merged
tree may be so messed up that you *do* want to go back.  So the "index"
(and I so agree with Alan that this is a poor choice of name) lets Git
store the "pre-merge" state without actually making a commit.

I've never made use of this "feature", tho.  Just like I never make use
of the "feature" that "git stash pop" keeps the stash if the result
has conflicts, which is a design clearly motivated by the same desire to
make it harder for the user to lose some of the work he's done.


        Stefan

Re: VC mode and git

[David Caldwell]

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

On 3/25/15 11:37 AM, Yuri Khan wrote:
> On Thu, Mar 26, 2015 at 12:19 AM, Alan Mackenzie <acm@muc.de> wrote:
> 
>> I'm mystified as to what the git index is for.  What's its motivation,
>> what's it used for, what does it gain me in exchange for the extra
>> complexity?  Does anybody have a link to a justification?  I'm genuinely
>> curious about this.
> 
> I view the index as a convenience.
> 
> The use case goes like this. I work on a feature. At the same time, I
> notice some coding style violations, or bad spelling/grammar, or
> possible enhancements unrelated to the feature.

Git certainly makes this pleasant (especially with `git add -p`). Back
before git I wanted the same type of features so a friend and I wrote
"commit-patch" (http://www.porkrind.org/commit-patch/). It supports a
bunch of different VCSes (including git) and integrates well with
Emacs--you basically get a diff somehow (`C-x v =` or `C-x v D` for me,
usually), edit the diff using Emacs's handy diff mode tools, then commit
that patch with `C-c C-c`. I find it's *much* easier to deal with than
magit or anything else I've seen so far, and it's heavenly to have
fine-grained commit control even when stuck with CVS and SVN.

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

Re: VC mode and git

[Lars Brinkhoff]

Alan Mackenzie <acm@muc.de> writes:
> The index (stupid name) is an extra layer of complexity.  I'm
> mystified as to what the git index is for.

At first, I found this extra layer annying just like you.  But now
that I've been using git for time time, I really miss the index when
I'm working in other DVCs, e.g. Mercurial.

That didn't answer your question, but perhaps the best way to answer
it is to dive head-first into git and just accept the new concepts.

Re: VC mode and git

[Alan Mackenzie]

Hello, Lars.

On Wed, Mar 25, 2015 at 07:49:30PM +0100, Lars Brinkhoff wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > The index (stupid name) is an extra layer of complexity.  I'm
> > mystified as to what the git index is for.

> At first, I found this extra layer annying just like you.  But now
> that I've been using git for time time, I really miss the index when
> I'm working in other DVCs, e.g. Mercurial.

> That didn't answer your question, but perhaps the best way to answer
> it is to dive head-first into git and just accept the new concepts.

No, it didn't answer my question.  ;-)

As for diving head-first into it, that's not really practical for me.
Mastering git is a bit like mastering assembler on a RISC chip - you
are forced to understand all sorts of arcane detail before you do the
most basic things, learning new meanings for already familiar words, and
generally wasting time which would have remained unwasted by the use of
a compiler (or a better VCS).

I now understand a great deal of git's arcane detail, and it is enough
to allow me to get by with a few simple commands in a simple workflow,
with occasional help now and then.  I don't intend to spend any more
time on git, unless I absolutely have to.  I do not look forward to the
occasions when I _must_ use git, e.g. when committing/pushing changes -
it's a miserable experience.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Eli.
>
> On Wed, Mar 25, 2015 at 08:03:17PM +0200, Eli Zaretskii wrote:
>> > From: Stefan Monnier <monnier@iro.umontreal.ca>
>> > Date: Wed, 25 Mar 2015 11:04:51 -0400
>
>> > I tend not to use the index very heavily (I'm still a fairly young Git
>> > user, evidently), so I don't suffer from it too much, but it's clearly
>> > wrong (an obvious problem is when the file is modified in the index and
>> > this modification is undone in the actual file
>
>> That's because you are not radical enough in not-using the index.  I
>> never get to the situation where a file is modified in the index.  One
>> problem less.
>
>> (Of course, now I will be pounced upon by all the people who were
>> brainwashed to think the index is a good idea.  Please don't bother.)
>
> The index (stupid name) is an extra layer of complexity.  Even the git
> maintainers half-admit it's not (always) a good thing by allowing "git
> commit -a".
>
> I'm mystified as to what the git index is for.  What's its motivation,
> what's it used for, what does it gain me in exchange for the extra
> complexity?  Does anybody have a link to a justification?  I'm genuinely
> curious about this.

Did you ever mark a few files to commit from many, in either pcl-cvs or
vc-dir? That's one thing that git allows you to do using its
command-line interface and index, only better. You mark changes to
commit by putting them into the index (that is now officially called
"staging area"), and you can even do this per-diff-chunk. Magit supports
this, by not trying to hide staging area (it does ask to commit
everything when nothing is staged, but anyway.)

[Side note]: now comes reasonable question: how about testing exact
to-be-committed state before commit? That's what 'git stash
--keep-index' provides (see "Testing partial commits" in the git-stash
manual.) And yes, magit supports this as well.

There are other uses of the staging area, notably to save multiple trees
on merges and getting diffs w.r.t both sides of the merge, that helps in
not-trivial conflicts resolution, but the use-case above should be
rather familiar to many.

-- Sergey.

P.S. Haters will hate, anyway.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Thu, 26 Mar 2015 00:15:26 +0300
> 
> Did you ever mark a few files to commit from many, in either pcl-cvs or
> vc-dir? That's one thing that git allows you to do using its
> command-line interface and index, only better.

You can do the same by stating the files on the commit command line.
No need to use the staging area, or even know about it.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> You can do the same by stating the files on the commit command line.

Of course you can, but not as conveniently.

> No need to use the staging area, or even know about it.

The index, and the way magit exposes, it is very convenient.  I
recommend trying it out.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 25 Mar 2015 09:52:08 +0100
> 
> > A related question is: does "C-x v v" at all make sense with Git and
> > other dVCSes?
> 
> Yes, it does.
> 
> I use it on single file changes.  Related changes over multiple files, I
> do from magit.

There are almost no single-file changes in Emacs: documentation and
NEWS need to be updated as well, to say nothing of ChangeLog.

And I see no reason why "C-x v v" should be limited to such a small
and insignificant minority of use cases as single-file changes.

> > If it does, what would be the DWIM cycle there?
> 
> Make a local commit, pointing to the previous commit of the current
> branch and move the HEAD to this commit, and stop there.

That stops short of being useful, because omitting "push" altogether
makes the workflow deficient, at least when you work on a public
project.

Also, what you propose means "C-x v v" with Git is just an alias for a
single command, which is not what "C-x v v" was supposed to do.

> > E.g., would it make sense for "C-x v v" to push when the previous
> > action was commit and there are not uncommitted changes?
>
> No.

Great argumentation, thanks.

vc-dwim when nothing to commit (was: VC mode and git)

[Ted Zlatanov]

On Tue, 24 Mar 2015 21:15:31 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Sebastien Vauban <sva-news@mygooglest.com>
>> Date: Tue, 24 Mar 2015 20:05:33 +0100
>> 
>> I think that the real conclusion of the discussion is: shouldn't vc-dir
>> have a command to push?  And, to that, I guess most of us would answer
>> yes, right?

EZ> A related question is: does "C-x v v" at all make sense with Git and
EZ> other dVCSes?  If it does, what would be the DWIM cycle there?  E.g.,
EZ> would it make sense for "C-x v v" to push when the previous action was
EZ> commit and there are not uncommitted changes?

My suggestion is really simple: if there is nothing to commit (implying
that a push may be wanted), `vc-dwim' should run `vc-runthis'.

Now, `vc-runthis' (name can be changed) will initially present "git
push" in the minibuffer with history, for a Git repo. So if I previously
said "git push myrepo onebranch:otherbranch" that's the command that
shows up. I edit it, then hit `RET' and it runs. Or I don't want it and
hit `C-g'. Or I move back in the history to a previous command.

This is how many other interactions in Emacs work when they don't know
what to do next automatically, so I think it makes sense here too.
Maybe it could even have completion.

Note the new `vc-runthis' command is also available for explicit
invocation.  I suspect in Git's case that will be very useful.
Currently I use `M-x eshell' all the time inside VC.

(Sorry if my suggestion is a duplicate. I was literally unable to read
the whole damn thread. For such a simple thing, a lot of arguing over
semantics and technicalities...)

Ted

Re: vc-dwim when nothing to commit (was: VC mode and git)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 17 Apr 2015 21:38:55 -0400
> 
> Now, `vc-runthis' (name can be changed) will initially present "git
> push" in the minibuffer with history, for a Git repo. So if I previously
> said "git push myrepo onebranch:otherbranch" that's the command that
> shows up. I edit it, then hit `RET' and it runs. Or I don't want it and
> hit `C-g'. Or I move back in the history to a previous command.

Could be a good idea, assuming the presented command will never
include tricky switches that the user didn't use in one of the
previous commands.  Otherwise, the presented command will be another
riddle, which IMO flies in the face of the design and purpose of
vc-next-action.

Of course, bonus points for guessing the next command (not necessarily
"git push") given the previous one and the existence of telltale files
below .git/.  That would be much more in line with the spirit of
vc-next-action, IMO.

Unfortunately, we don't seem to have an active maintainer of VC, in
particular in the Git area, so Git support in VC remains rudimentary
and at times buggy (e.g., see bug#20292, which remains without any
response, let alone fix).  And since most sophisticated Git users seem
to use magit anyway, I see no hope for having vc-git fixed any time
soon.

> For such a simple thing, a lot of arguing over semantics and
> technicalities...

And no practical result, except perhaps GitQuickStartForEmacsDevs,
which is probably not read anyway.

Re: vc-dwim when nothing to commit

[Ted Zlatanov]

On Sat, 18 Apr 2015 10:39:15 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 17 Apr 2015 21:38:55 -0400
>> 
>> Now, `vc-runthis' (name can be changed) will initially present "git
>> push" in the minibuffer with history, for a Git repo. So if I previously
>> said "git push myrepo onebranch:otherbranch" that's the command that
>> shows up. I edit it, then hit `RET' and it runs. Or I don't want it and
>> hit `C-g'. Or I move back in the history to a previous command.

EZ> Could be a good idea, assuming the presented command will never
EZ> include tricky switches that the user didn't use in one of the
EZ> previous commands.  Otherwise, the presented command will be another
EZ> riddle, which IMO flies in the face of the design and purpose of
EZ> vc-next-action.

Any kind of shell history has that feature (or problem, depending on
your point of view). I think it's a reasonable compromise.

EZ> Of course, bonus points for guessing the next command (not necessarily
EZ> "git push") given the previous one and the existence of telltale files
EZ> below .git/.  That would be much more in line with the spirit of
EZ> vc-next-action, IMO.

Right, so the history would be per repository and the very first initial
guess would be "git push" usually?  I would use that.

Unless there's a strong protest, I can try implementing a first cut of
this. I like that it fills a void, where you say "DWIM" after a Git
commit and VC goes "huh? go away!" :)

EZ> Unfortunately, we don't seem to have an active maintainer of VC, in
EZ> particular in the Git area, so Git support in VC remains rudimentary
EZ> and at times buggy (e.g., see bug#20292, which remains without any
EZ> response, let alone fix).  And since most sophisticated Git users seem
EZ> to use magit anyway, I see no hope for having vc-git fixed any time
EZ> soon.

That's unfortunate.  I use both, but VC is definitely more convenient
for "smaller" interactions.  Magit tends to be an all-day workflow.

Ted

Re: vc-dwim when nothing to commit

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 18 Apr 2015 06:22:37 -0400
> 
> EZ> Of course, bonus points for guessing the next command (not necessarily
> EZ> "git push") given the previous one and the existence of telltale files
> EZ> below .git/.  That would be much more in line with the spirit of
> EZ> vc-next-action, IMO.
> 
> Right, so the history would be per repository and the very first initial
> guess would be "git push" usually?  I would use that.
> 
> Unless there's a strong protest, I can try implementing a first cut of
> this. I like that it fills a void, where you say "DWIM" after a Git
> commit and VC goes "huh? go away!" :)

Please do, and TIA!  Don't be bothered by "strong protest", I don't
think we will see anything like that.

> EZ> Unfortunately, we don't seem to have an active maintainer of VC, in
> EZ> particular in the Git area, so Git support in VC remains rudimentary
> EZ> and at times buggy (e.g., see bug#20292, which remains without any
> EZ> response, let alone fix).  And since most sophisticated Git users seem
> EZ> to use magit anyway, I see no hope for having vc-git fixed any time
> EZ> soon.
> 
> That's unfortunate.  I use both, but VC is definitely more convenient
> for "smaller" interactions.  Magit tends to be an all-day workflow.

For me, the main problem with magit is that it's specific to Git, so
it's useless with other VCSes, which I still use almost every day,
including with important GNU projects (like Texinfo, for example).

Re: vc-dwim when nothing to commit

[Ted Zlatanov]

On Sat, 18 Apr 2015 14:03:24 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 18 Apr 2015 06:22:37 -0400
>> 
EZ> Of course, bonus points for guessing the next command (not necessarily
EZ> "git push") given the previous one and the existence of telltale files
EZ> below .git/.  That would be much more in line with the spirit of
EZ> vc-next-action, IMO.
>> 
>> Right, so the history would be per repository and the very first initial
>> guess would be "git push" usually?  I would use that.
>> 
>> Unless there's a strong protest, I can try implementing a first cut of
>> this. I like that it fills a void, where you say "DWIM" after a Git
>> commit and VC goes "huh? go away!" :)

EZ> Please do, and TIA!  Don't be bothered by "strong protest", I don't
EZ> think we will see anything like that.

I tried this for myself.  Just adding a command prompt is trivial:

#+begin_src diff
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index bb4dd60..a7af2ed 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1175,7 +1175,8 @@ (defun vc-next-action (verbose)
 	(dolist (file files) (vc-checkout file)))
        (t
         ;; do nothing
-        (message "Fileset is up-to-date"))))
+        (message "Fileset is up-to-date")
+        (call-interactively 'shell-command))))
      ;; Files have local changes
      ((vc-compatible-state state 'edited)
       (let ((ready-for-commit files))
#+end_src

but it doesn't have its own history or context, doesn't prefill the
command, and the output is displayed in an annoying buffer.

I tried polishing the interaction but I kept coming back to "run eshell
or ansi-term and up-arrow brings up the last 'git push' in the current
directory" which is one keystroke for me.  That's because I really,
really want to know if `git push' fails, and which refs it failed to
push.  If there's a failure, I usually want to be in a shell and to fix
it.  If not, I don't want to see any popup buffers.

So maybe the best way to do it for Git is:

1) check to see if there's anything to push (local tracking branch is
ahead of remote).  If not, do nothing.

2) Else, prompt to "git push" and capture the output.  This piece should
have its own command history.

3) if there was any failure (I don't know if the return code is
sufficient to determine that), bring up eshell or ansi-term with the
failure output pre-inserted

Does that seem reasonable?  It's what I would want to use, but maybe
it's too heavy for most people.

Ted

Re: vc-dwim when nothing to commit

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Mon, 04 May 2015 16:18:51 -0400
> 
> I tried polishing the interaction but I kept coming back to "run eshell
> or ansi-term and up-arrow brings up the last 'git push' in the current
> directory" which is one keystroke for me.  That's because I really,
> really want to know if `git push' fails, and which refs it failed to
> push.

Does it really fail so much for you?  I almost never see it fail here.

> So maybe the best way to do it for Git is:
> 
> 1) check to see if there's anything to push (local tracking branch is
> ahead of remote).  If not, do nothing.

Why not suggest "git pull" instead?  (Only suggest.)

> 2) Else, prompt to "git push" and capture the output.  This piece should
> have its own command history.
> 
> 3) if there was any failure (I don't know if the return code is
> sufficient to determine that), bring up eshell or ansi-term with the
> failure output pre-inserted

Not sure why you want a shell in case of failure.  What commands are
you likely to invoke in that case?  Can't we do that without bringing
up a shell?

Re: vc-dwim when nothing to commit

[Dmitry Gutov]

On 04/18/2015 10:39 AM, Eli Zaretskii wrote:

> Unfortunately, we don't seem to have an active maintainer of VC, in
> particular in the Git area, so Git support in VC remains rudimentary
> and at times buggy (e.g., see bug#20292, which remains without any
> response, let alone fix).

By that measure, we have no maintainer for the subprocesses facility, 
which looks a lot more worrying to me:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19729
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19860
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20207

(Just noticed that the last is a duplicate of the first; please someone 
who remembers debbugs syntax, merge them).

Re: vc-dwim when nothing to commit

[Eric S. Raymond]

Dmitry Gutov <dgutov@yandex.ru>:
> On 04/18/2015 10:39 AM, Eli Zaretskii wrote:
> 
> >Unfortunately, we don't seem to have an active maintainer of VC, in
> >particular in the Git area, so Git support in VC remains rudimentary
> >and at times buggy (e.g., see bug#20292, which remains without any
> >response, let alone fix).
> 
> By that measure, we have no maintainer for the subprocesses facility, which
> looks a lot more worrying to me:

I'm still here, but my attention is only available in intense bursts with
unpredictable timing. I've made a note to look into this one after I
get back from Detroit next week.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-dwim when nothing to commit

[Eli Zaretskii]

> Date: Sat, 18 Apr 2015 12:23:21 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > On 04/18/2015 10:39 AM, Eli Zaretskii wrote:
> > 
> > >Unfortunately, we don't seem to have an active maintainer of VC, in
> > >particular in the Git area, so Git support in VC remains rudimentary
> > >and at times buggy (e.g., see bug#20292, which remains without any
> > >response, let alone fix).
> 
> I'm still here, but my attention is only available in intense bursts with
> unpredictable timing. I've made a note to look into this one after I
> get back from Detroit next week.

Thank you!

Re: vc-dwim when nothing to commit

[Eli Zaretskii]

> Date: Sat, 18 Apr 2015 19:11:32 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19729
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19860
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20207
> 
> (Just noticed that the last is a duplicate of the first; please someone 
> who remembers debbugs syntax, merge them).

The syntax is in admin/notes/bugtracker.

I merged them.

Re: vc-dwim when nothing to commit

[Dmitry Gutov]

On 04/18/2015 07:30 PM, Eli Zaretskii wrote:

 > The syntax is in admin/notes/bugtracker.
>
> I merged them.

Thanks. Should this file be mentioned in CONTRIBUTE?

Re: vc-dwim when nothing to commit

[Eli Zaretskii]

> Date: Sat, 18 Apr 2015 22:22:39 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 04/18/2015 07:30 PM, Eli Zaretskii wrote:
> 
>  > The syntax is in admin/notes/bugtracker.
> >
> > I merged them.
> 
> Thanks. Should this file be mentioned in CONTRIBUTE?

I don't know.  If this file is mentioned, then why not other files in
admin/notes/, as well as files in admin/?

If CONTRIBUTE is going to have all this, it should probably be a
full-fledged Info manual, with TOC, index, etc., and should _replace_
all those random files.

Re: vc-dwim when nothing to commit

[Dmitry Gutov]

On 04/18/2015 10:35 PM, Eli Zaretskii wrote:

> I don't know.  If this file is mentioned, then why not other files in
> admin/notes/, as well as files in admin/?

Because users (and especially contributors) need to interact with the 
bug tracker? Not every file in notes/ applies, but it already references 
admin/notes/git-workflow, for instance.

> If CONTRIBUTE is going to have all this, it should probably be a
> full-fledged Info manual, with TOC, index, etc., and should _replace_
> all those random files.

That's a big leap from adding one line (or even a few).

Re: vc-dwim when nothing to commit

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> Unfortunately, we don't seem to have an active maintainer of VC, in
>> particular in the Git area, so Git support in VC remains rudimentary
>> and at times buggy (e.g., see bug#20292, which remains without any
>> response, let alone fix).
>
> By that measure, we have no maintainer for the subprocesses facility,
> which looks a lot more worrying to me:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19729
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19860
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20207
>
> (Just noticed that the last is a duplicate of the first; please
> someone who remembers debbugs syntax, merge them).

If you use M-x debbugs-gnu, you don't need to remember the syntax.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: vc-dwim when nothing to commit

[Dmitry Gutov]

On 04/18/2015 08:13 PM, Lars Magne Ingebrigtsen wrote:

> If you use M-x debbugs-gnu, you don't need to remember the syntax.  :-)

Thanks for the reminder. I've meant to try this a few times already, 
then I stumble on some problem with it (the package or debbugs itself), 
get angry and forget all but the basics.

I've tried it out, and apparently did something different from what I 
expected: http://debbugs.gnu.org/cgi/bugreport.cgi?msg=13;bug=16345

Would someone else revert this? Or should I continue experimenting?

Re: vc-dwim when nothing to commit

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I've tried it out, and apparently did something different from what I
> expected: http://debbugs.gnu.org/cgi/bugreport.cgi?msg=13;bug=16345
>
> Would someone else revert this? Or should I continue experimenting?

Done. Maybe we should add also the possibility to remove tags via debbugs-gnu.

Best regards, Michael.

Re: VC mode and git

[Steinar Bang]

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:

> I think that the real conclusion of the discussion is: shouldn't vc-dir
> have a command to push?  And, to that, I guess most of us would answer
> yes, right?

I've never used vc-dir, but magit has a push command.

But it is an explicit command, run by the user.

Re: VC mode and git

[Sebastien Vauban]

Steinar Bang wrote:
>>>>>> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>:
>
>> I think that the real conclusion of the discussion is: shouldn't vc-dir
>> have a command to push?  And, to that, I guess most of us would answer
>> yes, right?
>
> I've never used vc-dir, but magit has a push command.
>
> But it is an explicit command, run by the user.

That's what is missing currently from `vc-dir', IMHO.

I leave the question about the Git workflows and the integration of such
a command into `C-x v v' to others.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: VC mode and git

[Steinar Bang]

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:

> Steinar Bang wrote:

>> I've never used vc-dir, but magit has a push command.

>> But it is an explicit command, run by the user.

> That's what is missing currently from `vc-dir', IMHO.

magit is available from marmalade and melpa:
 https://marmalade-repo.org/packages/magit
 http://melpa.org/#/magit

Re: VC mode and git

[Sebastien Vauban]

Steinar Bang wrote:
>>>>>> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>:
>
>> Steinar Bang wrote:
>
>>> I've never used vc-dir, but magit has a push command.
>
>>> But it is an explicit command, run by the user.
>
>> That's what is missing currently from `vc-dir', IMHO.
>
> magit is available from marmalade and melpa:
>  https://marmalade-repo.org/packages/magit
>  http://melpa.org/#/magit

I'm aware of it, even aware of `egg' (which seemed better for
customization at some point).

Though, I'm dreaming of using one and only one interface for the common
backends I'm using (currently SVN and Git).

I'm sure that Magit may outrun `vc-dir' (even with the push command),
though I'm not that proficient yet with Git to use those advanced
functions.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: VC mode and git

[Steinar Bang]

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:

> Though, I'm dreaming of using one and only one interface for the
> common backends I'm using (currently SVN and Git).

An understandable desire: my fingers picked up the vc-* command
sequences way back on vc-rcs.el and vc-cvs.el and I'm really happy that
they still work on vc-git.el (and vc-svn.el and even vc-hg.el and
vc-bzr.el when I've had to look at projects managed by these).

But at the same time I've always used something other (and something not
distributed with emacs) for the directory/multi file commits: pcl-cvs
for CVS and svn-status (from psvn) for svn... so using magit here
doesn't feel so strange.

Re: VC mode and git

[Eric S. Raymond]

Sebastien Vauban <sva-news@mygooglest.com>:
> Though, I'm dreaming of using one and only one interface for the common
> backends I'm using (currently SVN and Git).

That was my original goal when I wrote VC back in 1992, though the choices
then were SCCS or RCS.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Stefan Monnier]

> Though, I'm dreaming of using one and only one interface for the common
> backends I'm using (currently SVN and Git).

There's another way to solve this problem: "git clone svn::<...>"


        Stefan

Re: VC mode and git

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Though, I'm dreaming of using one and only one interface for the common
>> backends I'm using (currently SVN and Git).
>
> There's another way to solve this problem: "git clone svn::<...>"

While it works, it's not as easy as a pure git workflow because it
requires to rebase all your changes everytime you push to svn. (either
that, or I didn't use it appropriately -- which wouldn't surprise me
either).

-- 
Nicolas

Re: VC mode and git

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

Marmalade and melpa are not maintained as part of Emacs.  If a package
is there, we should not recommend it as the preferred way to do
something.  Rather, we should improve VC with the features and commands
that it is missing.

-- 
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: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> Marmalade and melpa are not maintained as part of Emacs.  If a package
> is there, we should not recommend it as the preferred way to do
> something.  Rather, we should improve VC with the features and commands
> that it is missing.

Will having magit in GNU ELPA be sufficient?

Re: VC mode and git

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

  > > Marmalade and melpa are not maintained as part of Emacs.  If a package
  > > is there, we should not recommend it as the preferred way to do
  > > something.  Rather, we should improve VC with the features and commands
  > > that it is missing.

  > Will having magit in GNU ELPA be sufficient?

That would make it ok to recommend Magit, but it might still be better
and simpler overall to integrate Magit's useful features to VC rather
than have it as a separate package.

-- 
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: VC mode and git

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

  > I think that the real conclusion of the discussion is: shouldn't vc-dir
  > have a command to push?  And, to that, I guess most of us would answer
  > yes, right?

C-x v v should do a full commit, comparable to what it does for
other vc systems.

To have a VC command for a local commit seems fine too.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Wed, 25 Mar 2015 10:42:26 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> C-x v v should do a full commit, comparable to what it does for
> other vc systems.

The notion of "commit" from RCS/CVS/SVN doesn't scale well to Git.  So
simply copying the net effect is not useful.  Instead, we needto think
how to generalize the notion so that "C-x v v" continues to be useful
in more than just one possible worklfow, where a commit gets
immediately pushed.

Re: VC mode and git

[Tak Kunihiro]

>   > I think that the real conclusion of the discussion is: shouldn't vc-dir
>   > have a command to push?  And, to that, I guess most of us would answer
>   > yes, right?
> 
> C-x v v should do a full commit, comparable to what it does for
> other vc systems.

I have the same opinion.  One realistic discussion is about `default'
value for following.

 (defcustom vc-git-push-on-commit)

Advantage to use vc-mode for me is to have consistent interface to
both subversion and git.  For me `t' seems more appropriate.

Re: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> C-x v v should do a full commit, comparable to what it does for
> other vc systems.

A local commit _is_ a full commit.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

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

  > > C-x v v should do a full commit, comparable to what it does for
  > > other vc systems.

  > A local commit _is_ a full commit.

I mean, a commit that goes to the remote repository -- which in git
terminology is called "commit" and "push".

I think you knew that.


-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I mean, a commit that goes to the remote repository

This is a flawed concept.  You are throwing away the very advantage of a
DVCS.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Fri, 27 Mar 2015 08:48:53 +0100
> Cc: sva-news@mygooglest.com, emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > I mean, a commit that goes to the remote repository
> 
> This is a flawed concept.  You are throwing away the very advantage of a
> DVCS.

Isn't it clear, after all the flood of the messages, that Richard has
no use for those advantages?  Why cannot he have a VC feature, which
should be optional, to do what he want under certain circumstances and
given specific customizations?  This _is_ Emacs, after all, isn't it?

Why won't people in this thread stop trying to educate others, and
start being more helpful?

I think we need to identify a pattern suitable for "C-x v v" for a
workflow of simple changes where a commit leads to a push that pushes
only that one commit.  I'm not sure it should as simple as a push
following a commit, and even if it is, "C-x v v" should handle the
potential rejection of the push.  But given that we do identify a
suitable pattern, and provide a user option to activate it, I see
nothing wrong in having "C-x v v" follow it; I think that would suit
Richard needs.

Re: VC mode and git

[Stefan Monnier]

> Isn't it clear, after all the flood of the messages, that Richard has
> no use for those advantages?  Why cannot he have a VC feature, which
> should be optional, to do what he want under certain circumstances and
> given specific customizations?  This _is_ Emacs, after all, isn't it?

I think this should be implemented on the Git side, FWIW.
But we could also have an `after-commit-hook' to which Richard could
attach a call to `vc-push'.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@suse.de>,  sva-news@mygooglest.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 27 Mar 2015 08:54:31 -0400
> 
> > Isn't it clear, after all the flood of the messages, that Richard has
> > no use for those advantages?  Why cannot he have a VC feature, which
> > should be optional, to do what he want under certain circumstances and
> > given specific customizations?  This _is_ Emacs, after all, isn't it?
> 
> I think this should be implemented on the Git side, FWIW.

If you are talking about a kind-of "bound branch", I agree.

But I'm not sure this is the issue here, or at least not the only
one.  For example, we could have "C-x v v" do a commit, and then the
next "C-x v v" do a push.

The broader issue is how to generalize RCS-style vc-next-action to
modern dVCSes.  I think the current "generalization" is mostly a net
loss; we can and should do better.

Re: VC mode and git

[Stefan Monnier]

> The broader issue is how to generalize RCS-style vc-next-action to
> modern dVCSes.  I think the current "generalization" is mostly a net
> loss; we can and should do better.

Back in RCS times, the set of possible actions at any given time was
limited by constraints imposed by the tool.
A lot of the motivation behind the subsequent tools has been to try and
lift this constraints, and as a result, unsurprisingly most operations
can now be applied at any time.
So the DWIM element of C-x v v is indeed by nature very difficult to
port from RCS to Git/Hg/Bzr/Younameit.

So I think that refining C-x v v is pretty hopeless.  I won't stop
anyone from doing it, but I think it's a complete waste of time.


        Stefan

Re: VC mode and git

[Filipp Gunbin]

On 27/03/2015 13:53 -0400, Stefan Monnier wrote:

> So I think that refining C-x v v is pretty hopeless.  I won't stop
> anyone from doing it, but I think it's a complete waste of time.
>
>
>         Stefan

As a rather new user of vc, I can say that `C-x v v' always frightens me
(as do other dwimmy commands), because I am always not sure what it will
do next.  Rather, I just review my changes with vc-dir and just call
'commit -am "..."' in async-shell-command.  The same with conflicts
while merging and rebasing ("git rebase --continue" etc.).

Directing emacs or git to do something particular is much more
comfortable for me.

Filipp

Re: VC mode and git

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Cc: Eli Zaretskii <eliz@gnu.org>,  sva-news@mygooglest.com,  schwab@suse.de,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 27 Mar 2015 21:42:17 +0300
> 
> As a rather new user of vc, I can say that `C-x v v' always frightens me
> (as do other dwimmy commands), because I am always not sure what it will
> do next.

Does Emacs in general frightens you?

Re: VC mode and git

[Paul Eggert]

On 03/27/2015 12:16 PM, Eli Zaretskii wrote:
>> As a rather new user of vc, I can say that `C-x v v' always frightens me
>> >(as do other dwimmy commands), because I am always not sure what it will
>> >do next.
> Does Emacs in general frightens you?
>

Let's not bite the new users.  I also use Emacs VC without using C-x v 
v, as I'm fairly cautious as well.  It's a reasonable way to operate, 
even for experienced Emacs users.

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 12:45:54 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 03/27/2015 12:16 PM, Eli Zaretskii wrote:
> >> As a rather new user of vc, I can say that `C-x v v' always frightens me
> >> >(as do other dwimmy commands), because I am always not sure what it will
> >> >do next.
> > Does Emacs in general frightens you?
> >
> 
> Let's not bite the new users.  I also use Emacs VC without using C-x v 
> v, as I'm fairly cautious as well.  It's a reasonable way to operate, 
> even for experienced Emacs users.

There's nothing wrong in being cautious or frightened when you use
sophisticated software.  I'm personally frightened whenever I build a
complex package with GCC.

But that doesn't mean the tools we use cannot do a good job in doing
what we expect.  "C-x v v" never let me down in the many years I use
it.  (I don't use it with Git, because it's basically useless in that
case.)

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > But that doesn't mean the tools we use cannot do a good job in doing
 > what we expect.  "C-x v v" never let me down in the many years I use
 > it.  (I don't use it with Git, because it's basically useless in that
 > case.)

It occured to me last night that to me the git-ish DWIM in the
circumstance "last action commit && no changes to commit" would be to
prompt for a branch name and do "git checkout -b".

I'm not sure I'm really serious, I don't think many people, even
experienced git users, branch as much as I do.  But think about it.

Re: VC mode and git

[Tak Kunihiro]

> It occured to me last night that to me the git-ish DWIM in the
> circumstance "last action commit && no changes to commit" would be to
> prompt for a branch name and do "git checkout -b".

I think this is a good idea.  Maybe another option to be "git push"?

Re: VC mode and git

[martin rudalics]

 > Let's not bite the new users.  I also use Emacs VC without using C-x v v, as I'm fairly cautious as well.  It's a reasonable way to operate, even for experienced Emacs users.

I don't use vc at all.  Can I hope that your new ChangeLog generation
facility will have guidelines for such users too?

Thanks in advance, martin

Re: VC mode and git

[Paul Eggert]

martin rudalics wrote:
> I don't use vc at all.  Can I hope that your new ChangeLog generation
> facility will have guidelines for such users too?

Yes, that's the goal.  The draft patch in <http://bugs.gnu.org/19113#119> has 
general guidelines already.  I've tried them out with the Git techniques that I 
use (typically vc-dwim or plain 'git commit').  Quite possibly there will be 
glitches (I expect easily overcome) when people try them out with other 
techniques, and we can modify the guidelines as needed to help iron out any such 
glitches.

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@suse.de,  sva-news@mygooglest.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 27 Mar 2015 13:53:52 -0400
> 
> > The broader issue is how to generalize RCS-style vc-next-action to
> > modern dVCSes.  I think the current "generalization" is mostly a net
> > loss; we can and should do better.
> 
> Back in RCS times, the set of possible actions at any given time was
> limited by constraints imposed by the tool.

That's why generalization is non-trivial.

> A lot of the motivation behind the subsequent tools has been to try and
> lift this constraints, and as a result, unsurprisingly most operations
> can now be applied at any time.
> So the DWIM element of C-x v v is indeed by nature very difficult to
> port from RCS to Git/Hg/Bzr/Younameit.
> 
> So I think that refining C-x v v is pretty hopeless.  I won't stop
> anyone from doing it, but I think it's a complete waste of time.

I posted earlier 2 workflows I routinely use that are clear candidates
for "C-x v v".

Re: VC mode and git

[Allen S. Rout]

On 03/27/2015 03:03 PM, Eli Zaretskii wrote:

> I posted earlier 2 workflows I routinely use that are clear candidates
> for "C-x v v".
> 

It might be most useful, and generate the least additional heat, to just
let people who want to use Git as Git be happy in magit-land.   It's
clearly superior to vc.el in a long list of ways.

Richard can articulate that what he wants is to work with git in a
manner that doesn't differ from what he's been doing for *handwave*
time.  A formula to let him bend vc.el into that shape should satisfy
him, and anyone else who wants to ignore the differences.

Paradigms shift when the existing professors retire.



- Allen S. Rout

Re: VC mode and git

[Eli Zaretskii]

> From: "Allen S. Rout" <asr@ufl.edu>
> Date: Fri, 27 Mar 2015 15:19:53 -0400
> 
> On 03/27/2015 03:03 PM, Eli Zaretskii wrote:
> 
> > I posted earlier 2 workflows I routinely use that are clear candidates
> > for "C-x v v".
> > 
> 
> It might be most useful, and generate the least additional heat, to just
> let people who want to use Git as Git be happy in magit-land.   It's
> clearly superior to vc.el in a long list of ways.

No one said that magit users should switch to vc.el, and no one
suggested to make any changes whatsoever to magit.  This discussion is
only about vc.el and its vc-next-action feature.  People who are not
interested in that feature and don't use it, or don't use vc.el at
all, should not fear any changes that will affect them.

Re: VC mode and git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> It might be most useful, and generate the least additional heat, to just
>> let people who want to use Git as Git be happy in magit-land.   It's
>> clearly superior to vc.el in a long list of ways.
>
> No one said that magit users should switch to vc.el, and no one
> suggested to make any changes whatsoever to magit.  This discussion is
> only about vc.el and its vc-next-action feature.  People who are not
> interested in that feature and don't use it, or don't use vc.el at
> all, should not fear any changes that will affect them.

This discussion is not about choosing among two sensible options as the
candidates for the default configuration. Just giving the possibility of
"C-x v v" to push as an option is questionable to me. Such request can
only come from someone who do not fully understands what a dVCS is
about. OTOH, allowing "C-x v v" to push as a default is just a
disservice to the Emacs community. Plain and simple. It is a trap with
the potential of embarrassing Emacs users and annoying the rest who
participate on the same project.

"C-x v v" makes little sense on a chageset-based VCS (not only Git, but
Subversion as well.) vc-dir, Magit, psvn, etc, are the sensible way of
dealing with those VCSs. Insisting on a CVS workflow when you are using
tools that are based on different paradigms is a recipe for melancholy.

Re: VC mode and git

[Stefan Monnier]

FWIW,

This discussion is a waste of time.  If someone provides a patch to add
an optional new behavior to vc-next-action, it'll probably be accepted
(as long as it's clean enough).  And as long as noone writes such
a patch this discussion is just hot air.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Fri, 27 Mar 2015 18:34:36 -0400
> 
> If someone provides a patch to add an optional new behavior to
> vc-next-action, it'll probably be accepted (as long as it's clean
> enough).  And as long as noone writes such a patch this discussion
> is just hot air.

How many people even use vc-next-action these days?  IOW, would it be
okay to make it work very differently for modern dVCSes than what it
does now?

For example, in a Git repository where "git status" shows nothing,
vc-next-action invoked without an argument currently says "Fileset is
up-to-date" and does nothing, which is IMO less than useful.  Would
someone mind if it suggested a "git pull" instead?

Also, there's no handling of pull problems, and the handling of
conflicts is rudimentary at best.  And, of course, there's no sup[port
at all for pushing; there's no notion of local commits that are
missing upstream.  Would someone mind if vc-next-action were changed
in these regards?

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> How many people even use vc-next-action these days?

??? Since there is no vc-commit this is the only way to do it.

Andreas.

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

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>,  emacs-devel@gnu.org
> Date: Sat, 28 Mar 2015 08:27:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How many people even use vc-next-action these days?
> 
> ??? Since there is no vc-commit this is the only way to do it.

Well, magit seems to be one way; there could be others, like the
command line.  I really don't know, which is why I'm asking here
first.

If the answer is "many people do, but only as a replacement for a
missing vc-commit", that's also valuable information.

Re: VC mode and git

[Stefan Monnier]

> If the answer is "many people do, but only as a replacement for a
> missing vc-commit", that's also valuable information.

I use "git commit" after merges, but to actual commit a change (where
I need to write a ChangeLog), I use vc-dir and hence vc-next-action.
So, yes, I use vc-next-action frequently, and it always means "commit".

I suggested it many years ago (in the context of CVS, IIRC): VC should
offer each operation via a separate command (and vc-next-action would
simply be built on top of it).

Regarding your other suggestions: I'm fine with extending
vc-next-action, but it should not offer a functionality which is not
already available via some other command.


        Stefan

Re: VC mode and git

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

  > I use "git commit" after merges, but to actual commit a change (where
  > I need to write a ChangeLog), I use vc-dir and hence vc-next-action.
  > So, yes, I use vc-next-action frequently, and it always means "commit".

That's how I use it, also.
-- 
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: VC mode and git

[Jan D.]

Hi.

> 28 mar 2015 kl. 08:17 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> How many people even use vc-next-action these days?  IOW, would it be
> okay to make it work very differently for modern dVCSes than what it
> does now?
> 
> For example, in a Git repository where "git status" shows nothing,
> vc-next-action invoked without an argument currently says "Fileset is
> up-to-date" and does nothing, which is IMO less than useful.  Would
> someone mind if it suggested a "git pull" instead?

How do you commit without vc-next-action in vc?  I would assume people use it all the time.

	Jan D.

Re: VC mode and git

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sat, 28 Mar 2015 09:18:03 +0100
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
> 
> How do you commit without vc-next-action in vc?  I would assume people use it all the time.

I replied to the same question earlier.

In any case, the question is not about committing, it's about the
other uses of vc-next-action, if there are any.  I also asked a few
specific questions about the changes I have in mind.  Please see all
those questions as context to the above one.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sat, 28 Mar 2015 11:34:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
> > From: "Jan D." <jan.h.d@swipnet.se>
> > Date: Sat, 28 Mar 2015 09:18:03 +0100
> > Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
> > 
> > How do you commit without vc-next-action in vc?  I would assume people use it all the time.
> 
> I replied to the same question earlier.

Btw, all we need to have a vc-commit is a trivial interactive wrapper
around vc-checkin.  Would that be a welcome addition?

Re: VC mode and git

[Stefan Monnier]

> Btw, all we need to have a vc-commit is a trivial interactive wrapper
> around vc-checkin.  Would that be a welcome addition?

Yes.


        Stefan

Re: VC mode and git

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Stefan Monnier  Date: Fri, 27 Mar 2015 18:34:36 -0400

 >> If someone provides a patch to add an optional new behavior to
 >> vc-next-action, it'll probably be accepted (as long as it's clean
 >> enough).  And as long as noone writes such a patch this discussion
 >> is just hot air.

 > How many people even use vc-next-action these days?

	With Git, I use it strictly as a substitute for the (otherwise
	unavailable) vc-commit.

 > IOW, would it be okay to make it work very differently for modern
 > dVCSes than what it does now?

 > For example, in a Git repository where "git status" shows nothing,
 > vc-next-action invoked without an argument currently says "Fileset is
 > up-to-date" and does nothing, which is IMO less than useful.  Would
 > someone mind if it suggested a "git pull" instead?

 > Also, there's no handling of pull problems, and the handling of
 > conflicts is rudimentary at best.  And, of course, there's no support
 > at all for pushing; there's no notion of local commits that are
 > missing upstream.  Would someone mind if vc-next-action were changed
 > in these regards?

	My Git usage is neither typical nor exemplary, but I both
	git-fetch(1) and git-push(1) from outside of the chroot
	environments I use for development.  (If only because such
	environments lack access to the relevant SSH keys.)

	I have no objections against such features as long as they’re
	optional and never affect the vc-commit function I use.  And
	should they come to be /not/ optional, I guess I’d be able to
	bear with them, either.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: VC mode and git

[Simon Leinen]

On Sat, Mar 28, 2015 at 8:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> How many people even use vc-next-action these days?  IOW, would it be
> okay to make it work very differently for modern dVCSes than what it
> does now?

I use it frequently.  Though I use it *less* frequently with Git than
with centralized CVSes, I do use it sometimes with Git, mostly to
commit small changes.  For more complex changes I tend to use Magit.
(I guess I should consistently use Magit, but I like VC because it's
more lightweight, and probably also because I've been using it for 15
years or so.)

Just a data point.
-- 
Simon.

Re: VC mode and git

[Steinar Bang]

>>>>> Simon Leinen <simon.leinen@gmail.com>:

> I use it frequently.  Though I use it *less* frequently with Git than
> with centralized CVSes, I do use it sometimes with Git, mostly to
> commit small changes.  For more complex changes I tend to use Magit.
> (I guess I should consistently use Magit, but I like VC because it's
> more lightweight, and probably also because I've been using it for 15
> years or so.)

+1

Re: VC mode and git

[Allen S. Rout]

On 03/27/2015 03:38 PM, Eli Zaretskii wrote:

> No one said that magit users should switch to vc.el, and no one
> suggested to make any changes whatsoever to magit.  

I know.

> This discussion is
> only about vc.el and its vc-next-action feature.  People who are not
> interested in that feature and don't use it, or don't use vc.el at
> all, should not fear any changes that will affect them.

Agreed.  Apologies for failing to make my point; I'll try again.

Don't try to teach vc.el adherents that a git way might be better.   No
light, only heat.  Instead, use magit, and wait.

- Allen S. Rout

Re: VC mode and git

[Thien-Thi Nguyen]

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

() "Allen S. Rout" <asr@ufl.edu>
() Fri, 27 Mar 2015 16:31:45 -0400

   Don't try to teach vc.el adherents that a git way might be
   better.  No light, only heat.  Instead, use magit, and wait.

That is a fine strategy if the teachers were not to care about
vc.el and vc.el adherents, and their fate going forward.  Too,
there are vc.el semi-adherents (FTR, like myself) in the mix.
Teaching is not a tranquil tradition...

Anyway, i see the discourse not so much as "the git way" vs
"the non-git way" but more along the lines of electrolysis of
water into its constituent hydrogen and oxygen.  Perhaps the
heat[0] can be put to (thermodynamic) work, perhaps not; some
habits are hard to crack[1], and water being wet is one of its
charms[2].  :-D

__________________________________________
[0] of the resulting explosion when the hydrogen and oxygen
    encounter a spark
[1] http://www.merriam-webster.com/dictionary/crack
    (definition 7b)
[2] now people will accuse me of calling RMS all wet, sigh

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: VC mode and git

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

  > A lot of the motivation behind the subsequent tools has been to try and
  > lift this constraints, and as a result, unsurprisingly most operations
  > can now be applied at any time.
  > So the DWIM element of C-x v v is indeed by nature very difficult to
  > port from RCS to Git/Hg/Bzr/Younameit.

It is not difficult, as long as you don't ask too much of it.

It may be impossible to make DWIM serve a sophisticated user whose use
of Git follows no simple pattern.  However, it is not hard to make
DWIM useful when a user is using Git in RCS fashion.

If a given user uses Git in RCS fashion _most of the time_, then the
DWIM would still serve _most of the time_, which is quite useful.

-- 
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: VC mode and git

[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 we could also have an `after-commit-hook' to which Richard could
  > attach a call to `vc-push'.

1. In principle, that would do the job, but people are saying that
that is unreliable, that if the push fails it would leave things
in a bad state.

I have not yet seen a definitive answer about whether git reset is a
reliable fix for that.

2. It would be ok if this asks for user approval rather than just
going ahead.

3. It would be good to make a simple way to request this in the
repository, perhaps by touching a certain file name, so that the
simple Git recommendations could tell people a simple way to do this.

Can the repository itself have a file that directs git to run a shell
command after pushing?  That command could be a shell conditional that
does a push if a certain file name exists.  Then the simple Git
recommendations could say to touch that file name.  The command could
check for the file in the current directory and each of its parents,
stopping at the root dir of the 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: VC mode and git

[Stefan Monnier]

> I have not yet seen a definitive answer about whether git reset is a
> reliable fix for that.

I think it is, but it should be "git reset --soft HEAD^", which AFAIK is
the way to spell "uncommit" in Git (where "uncommit" to me means to
do just the reverse of commit, i.e. just like commit it shouldn't touch
the files's contents, only the metadata).

> Can the repository itself have a file that directs git to run a shell
> command after pushing?

Depends what you mean by "repository".  Your local Git clone is
a repository.  So the hooks discussed here would indeed be placed in
your repository.  But I don't think there's a way to change Emacs's
git.sv.gnu.org repository such that when you clone it, you automatically
get such hooks.


        Stefan

Re: VC mode and git

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

  > Depends what you mean by "repository".  Your local Git clone is
  > a repository.  So the hooks discussed here would indeed be placed in
  > your repository.  But I don't think there's a way to change Emacs's
  > git.sv.gnu.org repository such that when you clone it, you automatically
  > get such hooks.

The quick start instructions could suggest creating that file.

-- 
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: VC mode and git

[Mike Gerwitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Mar 28, 2015 at 15:52:07 -0400, Stefan Monnier wrote:
> But I don't think there's a way to change Emacs's git.sv.gnu.org
> repository such that when you clone it, you automatically get such
> hooks.

There is not---that is a security issue, running arbitrary commands on a
user's system when they invoke otherwise standard commands.  It would be
akin to setting PATH="$PATH:$(pwd)/.git/malicious" containing a `git`
command.

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVGPpKAAoJEPIruBWO4w6rGIEP/1O/NorM3Gv0ZjAqP59xgxrp
S5B8u/mPekgOIsANKi9klkBrHWNosZqf3jYJj0CFVIoXAnpAPFmLkY/wCjcfzHH7
S4cVvr/SQPyWoML99L2OvtkGytt9oPEzpC5i4LuKkA+mmqqQlE3Uj64/295DsZ3k
cPUYpidts0+jizy6+v1B+ytHn1ULzlHe89vfK53wSLNyrQ7u++l3Yh73UhECKnhK
oi5w0SiDrgtdJlaW3L/Qa4At9ZmMMqoce2X9EXGvQW9Jb9OlrPKHowUMUJZmEWMA
BEnENn5Kz9PNPhoDH7cXfVVSFdqi75hlDHxRXbnEcc5sKa3/wQU0mA9fOXQpnlkH
S7l6vNjdvBdWAlvprfSBVtDLh6F/wkBYXjn2r+VtFvpHFx2sWvTZGOnaIsrmo/98
iYvJEB9as8izYY+82Nox1mohXeM39bL9xegzOs1OUyhPpyaDOvwuCr9BOffa9HNY
ATzE6c/BglXXVLDKWPDQnRhME93eH5yWXTQNVm54+T5w2P1qcOH1TbP3JIcV13sm
FhsWcc8HVUlxyRqRz54I8Dp9kgtEdSa0ApaengokafHccp7hfmJu5R3IRiaAGbOd
VSxCk7/YDE6NQFyATIgqWrlA7xfovlzO8AoA9IOcrabkU+lxAg7fD2oIUOMbLdy3
oWQE+/Ij0yCk/vV0NLZs
=mqnW
-----END PGP SIGNATURE-----

Re: VC mode and git

[Mike Gerwitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Mar 28, 2015 at 12:15:59 -0400, Richard Stallman wrote:
> I have not yet seen a definitive answer about whether git reset is a
> reliable fix for that.

If a push fails, that does not necessarily indicate a "bad state"---it
simply represents that your history is different than what the remote
server has, and that the tip of the branch you are pushing to cannot
simply be "fast-forwarded" to your commit.

After a failed push, you are in no different state than you were before
the push (aside from a possibly puzzled mental state).

In your case, since you just want to commit and push in one operation,
you likely want to run `git pull --rebase`, which would get those
changes and then automatically re-commit your work on top of them, as if
you had those changes all along.  You could then push.  So, something
like:

  # commit all changes and attempt to push, pulling in changes if
  # necessary and re-pushing; on failure, restore to previous state with
  # changes uncomitted
  git commit -am Foo \
    && {
      git push \
        || {
          { git pull --rebase || handle-pull-conflicts; } \
            && git push;
        }
    } \
    || {
      git reset --soft HEAD^
      echo 'Commit failed.'
    }

But what if rebasing fails?  Then you are left resolving a conflict
before you can attempt the push operation again.  I do not know how you
would want to handle this.  `handle-pull-conflicts` might simply perform
a `git rebase --abort` and exit with a non-zero status, or it may open a
UI/shell to help resolve changes.  If you are pushing after every
change, this amounts to correcting a single commit, so it might be worth
having VC maintain the state here, allow you to correct your commit, and
then the vc-next-action would be to run `git rebase --continue` after
adding the files that conflicted.

This will be how the majority of Git users will resolve rejected pushes.

Does that make sense?

  [Aside: `git pull` without `--rebase` performs a `git fetch && git
  merge whatever-branch-you-are-tracking`, which has the unfortunate
  side-effect of creating a merge commit if histories are different;
  this muddies up history.  `git pull --rebase` performs `git fetch &&
  git rebase whatever-branch-you-are-tracking`.  The difference in the
  two styles of conflicts here is that, with rebasing, since you are
  re-committing each and every changeset, you may get multiple
  conflicts on any number of commits, whereas a merge will give you a
  single conflict that must be resolved at once.  The benefit of
  rebasing is that it gives you a clean history and does not produce an
  unnecessary merge conflict which you would then push to origin, akin
  to leaving a bag of poop on origin's doorstep.]

For other users, it may represent a wholly different problem.  For
example, if I were to push to GNU ease.js' repo and get that message,
that would be a problem, since that means that someone has committed to
my repository without my permission.  An automatic pull and re-push
would be bad in this case, since that makes it look like I'm okay with
that.

A failed push could also mean that you are tracking the wrong
branch, or pushing to the wrong repository.  Git allows you to set a
"tracking branch", which can be anything---a local branch, a remote
branch, or a branch in an entirely different repository, local or
remote.  Further, you can override the tracking branch by specifying
which remote to push to as part of the `push` command.

In your case, you'd always want to respect the tracking branch and
assume that there are no problems pushing, since you use only one
remote, and the tracking branch is always a branch of the same name on
origin.

A failed push could also mean that someone rudely rewrote history on the
remote branch (using `git push --force`) and someone needs a talkin' to.

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVGQFQAAoJEPIruBWO4w6r9lMP/j9jILNs178Ty6iF5TqZapjU
LBpLANcEra5P2hKQ9qZXnOIuibysTXMTdMGRhwYnK/A/zPxNpsBXhDYvY9ELZTw4
CHDxGqdGxWXHC42qGRA+x7pcpw7WhO6DTmml3ovRXnp1QFkoZvHNwgShVg4hOteS
EZM/93NBo6C4YYLSfiCo4FedcYQ/xY29IfHQcLmjLSmOJ6PaQzuEUPVJwq8bZkjf
i4RI077FOzwbglHOc+rUWSBHTU+pzJUUS0kPClik4dveKtbN2Bl568PGGwPCyp6F
SXAlKy5RDRwBHD+CfHL9EO1Y6x+RTde04tBz0TJqP1GpBH+uIm9+wyR3Kbm/I8G9
ijdLhOSmHtlgs3nl1NF5KzwqQlvYogl2egUWpjLpLQSnzEV6k591PMSlHiVg8xNz
C/spyvOvWxqNEIw6OyYgrw2e3KbXG50kCJ79Z/0e11cG+xMoeFDL+C2Ovt/iiz/Y
f+91mJAE++58hSNXLKz0hLepTnVuHtDD5enmw8CsLrA92HVDjgs9pyr50IFagwZq
WqLKkvzo84mRZufYCTzIc7gjd0EMvPb/a0XYl3vec42Gul6J6Bb84c3ZuGGCMw5Y
UFB/tznEtdGwCxW8qiYhfLVvu6ig7WXpEz2l6A0k+HsMCWgVlDV0ztPQ2wC+2/LK
QnDA5hLak+2nZQ/U8sWV
=61Yc
-----END PGP SIGNATURE-----

Re: VC mode and git

[Eli Zaretskii]

> From: Mike Gerwitz <mikegerwitz@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  sva-news@mygooglest.com,  schwab@suse.de,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 30 Mar 2015 03:54:55 -0400
> 
> > I have not yet seen a definitive answer about whether git reset is a
> > reliable fix for that.
> 
> If a push fails, that does not necessarily indicate a "bad state"---it
> simply represents that your history is different than what the remote
> server has, and that the tip of the branch you are pushing to cannot
> simply be "fast-forwarded" to your commit.

It is "bad" from the POV of someone who started with uncommitted
changes, and ended with them committed locally, but not pushed
upstream.  IOW, the command did half the work, and now the user needs
to use commands she might consider "advanced" to fix that.

> After a failed push, you are in no different state than you were before
> the push (aside from a possibly puzzled mental state).

Yes, he is in a different state: before that, the changes were
uncommitted.

> In your case, since you just want to commit and push in one operation,
> you likely want to run `git pull --rebase`, which would get those
> changes and then automatically re-commit your work on top of them, as if
> you had those changes all along.

We decided some time ago that we don't want to rebase, but to pull
instead.

> But what if rebasing fails?  Then you are left resolving a conflict
> before you can attempt the push operation again.  I do not know how you
> would want to handle this.

Ideally, "C-x v v" should DTRT in that case.  But no one coded it to
do that, yet.

> This will be how the majority of Git users will resolve rejected pushes.

Are you sure there's such a majority?  I don't consider myself a Git
expert, but even I can propose at least 3 different ways of dealing
with the above situation.  Ideally, someone who _is_ an expert will
suggest the best way, and then "C-x v v" could be amended to support
that.

In any case, I think it is clear now that post-commit hooks cannot be
the solution, because they are not versatile enough, and because user
interaction will almost certainly be needed during resolution of such
situations.

>   [Aside: `git pull` without `--rebase` performs a `git fetch && git
>   merge whatever-branch-you-are-tracking`, which has the unfortunate
>   side-effect of creating a merge commit if histories are different;
>   this muddies up history.

We already decided not to worry about this, since we use a merge-based
workflow with the release branch anyway (see admin/gitmerge.el).

> For other users, it may represent a wholly different problem.  For
> example, if I were to push to GNU ease.js' repo and get that message,
> that would be a problem, since that means that someone has committed to
> my repository without my permission.  An automatic pull and re-push
> would be bad in this case, since that makes it look like I'm okay with
> that.

First, no one suggested any automation here.  "C-x v v" is a command
that is invoked by the user, it doesn't invoke itself.  It could also
show a warning and ask for confirmation in dubious situations.

And second, with VCSes as versatile as Git (and assuming that people
who use Git in such workflows will at all want to use VC, an
assumption that proved questionable in this discussion), VC should
offer to customize its "next action" decisions so as to adapt them to
a particular workflow.

> A failed push could also mean that you are tracking the wrong
> branch, or pushing to the wrong repository.  Git allows you to set a
> "tracking branch", which can be anything---a local branch, a remote
> branch, or a branch in an entirely different repository, local or
> remote.  Further, you can override the tracking branch by specifying
> which remote to push to as part of the `push` command.

"C-x v v" is not supposed to be able to cover every contingency and
every workflow out there.  It should support the widely used ones, and
left the rest to manual invocation of commands at user discretion.

> A failed push could also mean that someone rudely rewrote history on the
> remote branch (using `git push --force`) and someone needs a talkin' to.

When a push fails, the user should read the error message, and try to
understand what it means.  There's no way around that; no one is
suggesting that only the exit status of the push command is enough to
decide what to do next.

Re: VC mode and git

[Stefan Monnier]

>> But what if rebasing fails?  Then you are left resolving a conflict
>> before you can attempt the push operation again.  I do not know how you
>> would want to handle this.

The way we'd normally handle this (e.g. the way Bazaar handled it, and
the way CVS handled it) is to abort the commit operation.  Then the user
can do the "pull" any which way he wants, and try to commit again.

Doing "git pull --rebase" and trying to handle conflicts directly from
the commit hook is madness, IMNSHO.

> In any case, I think it is clear now that post-commit hooks cannot be
> the solution,

To me, it's clear that such hooks can definitely, cleanly, reliably
provide the expected "cvs commit"-like semantics.


        Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mike Gerwitz <mikegerwitz@gnu.org>,  rms@gnu.org,  sva-news@mygooglest.com,  schwab@suse.de,  emacs-devel@gnu.org
> Date: Mon, 30 Mar 2015 13:24:04 -0400
> 
> > In any case, I think it is clear now that post-commit hooks cannot be
> > the solution,
> 
> To me, it's clear that such hooks can definitely, cleanly, reliably
> provide the expected "cvs commit"-like semantics.

Then please write it up, and let's see it in action.

Re: VC mode and git

[Stefan Monnier]

> Then please write it up, and let's see it in action.

It was already provided:

    #!/bin/sh
    git push || git reset --soft HEAD^


-- Stefan

Re: VC mode and git

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 30 Mar 2015 16:37:48 -0400
> Cc: sva-news@mygooglest.com, mikegerwitz@gnu.org, emacs-devel@gnu.org,
> 	rms@gnu.org, schwab@suse.de
> 
> > Then please write it up, and let's see it in action.
> 
> It was already provided:
> 
>     #!/bin/sh
>     git push || git reset --soft HEAD^

Are you sure this is all that's needed?  I have at least 2 potential
issues with it:

  . If the commit fails, will the hook run anyway?  (I cannot find any
    documentation on this.)

  . If the push fails and the hook runs "git reset", will the commit
    command exit with a non-zero status?  (I'm guessing not, but again
    found no documentation.)  If it exits with a zero status anyway,
    then "C-x v v" will not know the operation failed, would it?

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Mike Gerwitz <mikegerwitz@gnu.org>

 > > If a push fails, that does not necessarily indicate a "bad
 > > state"---it simply represents that your history is different than
 > > what the remote server has, and that the tip of the branch you
 > > are pushing to cannot simply be "fast-forwarded" to your commit.
 > 
 > It is "bad" from the POV of someone who started with uncommitted
 > changes,

I don't think it's useful to call this "bad" or "a screw" (speaking of
name-calling).  However, Mike's answer clearly doesn't account for
Richard's point of view.

 > > After a failed push, you are in no different state than you were
 > > before the push (aside from a possibly puzzled mental state).
 > 
 > Yes, he is in a different state: before that, the changes were
 > uncommitted.

Technically, Mike is right (he writes of before/after push, which is
unambiguous).  What he's missing is that the requirement is an atomic
commit-and-push.

 > In any case, I think it is clear now that post-commit hooks cannot
 > be the solution, because they are not versatile enough,

Eli, that's ridiculous.  While I don't think it's obvious that a
post-commit hook can meet all requirements (specifically, when I
explained to Richard that files add'ed, rm'ed, or mv'ed since HEAD^
and committed in HEAD will be not be in the same state after "git
reset --soft HEAD^", he characterized that as a defect in git), they
come pretty close already (in Emacs practice, manipulations of
directories are relatively rare, so this is going to bite only in very
rare circumstances).  I believe those are the only state changes that
get reverted by reset --soft.  File modifications are preserved, and
I'm pretty sure that chmod is as well.

Furthermore, a complex pre-commit hook probably can parse the output
of git status and preserve the add/rm/mv state.  Or maybe the thing to
do is save the index (it may be possible to just stash that state, and
I'm pretty sure it can be committed to a temporary branch, and
restored from that if the push fails) -- that would preserve
everything that's observable by git.

 > and because user interaction will almost certainly be needed during
 > resolution of such situations.

That's not part of the requirement.  Of course user interaction will
be needed to deal with modification conflicts, and it's not obvious
what the right thing to do in case of losing the push race.  (Note:
what's "right" *not* a question of "git expertise".  That's purely a
question of workflow, which is partly a project decision and partly a
personal decision.)

However, the requirement for the hook functions is to make it possible
to commit and push as a single atomic operation.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 31 Mar 2015 04:24:48 +0900
> Cc: rms@gnu.org, sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org,
> 	Mike Gerwitz <mikegerwitz@gnu.org>, monnier@iro.umontreal.ca
> 
>  > In any case, I think it is clear now that post-commit hooks cannot
>  > be the solution, because they are not versatile enough,
> 
> Eli, that's ridiculous.  While I don't think it's obvious that a
> post-commit hook can meet all requirements (specifically, when I
> explained to Richard that files add'ed, rm'ed, or mv'ed since HEAD^
> and committed in HEAD will be not be in the same state after "git
> reset --soft HEAD^", he characterized that as a defect in git), they
> come pretty close already (in Emacs practice, manipulations of
> directories are relatively rare, so this is going to bite only in very
> rare circumstances).  I believe those are the only state changes that
> get reverted by reset --soft.  File modifications are preserved, and
> I'm pretty sure that chmod is as well.
> 
> Furthermore, a complex pre-commit hook probably can parse the output
> of git status and preserve the add/rm/mv state.  Or maybe the thing to
> do is save the index (it may be possible to just stash that state, and
> I'm pretty sure it can be committed to a temporary branch, and
> restored from that if the push fails) -- that would preserve
> everything that's observable by git.

If it needs to cater to non-experts, let alone people who cannot
afford or be bothered to learn enough of Git, it should also make sure
the repository is left in a state from which it is easy to proceed
with fixing whatever problems are left after backing out the commit.
I'm not sure this is easy.

But if someone who knows their ways around Git comes up with such a
script, I'll be the first to applaud.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > If it needs to cater to non-experts, let alone people who cannot
 > afford or be bothered to learn enough of Git, it should also make sure
 > the repository is left in a state from which it is easy to proceed
 > with fixing whatever problems are left after backing out the commit.
 > I'm not sure this is easy.
 
"Easy to proceed with fixing" is an impossible standard, when you're
talking about people who don't follow instructions to the letter and
probably don't remember exactly what they did.  For example, I have no
fscking idea how Richard put his workspace into a state where git
thinks a zillion source files are modified.  The burden of resolving
that should not be placed on git or on the Emacs workflow.

What can be done is revert to the exact state in which "git commit"
was invoked.  I explained in general how to do that.  I am rather sure
that approach works.  The problems are (1) I lack the *shell-foo* to
script it reliably (including cleaning up leftover stashes or
temporary branches etc), and (2) I really don't think it will be used
by anybody but Richard, and I've got a plane to catch so for the
foreseeable future I'm not going to spend effort on making it robust.

 > But if someone who knows their ways around Git comes up with such a
 > script, I'll be the first to applaud.

As Stefan posted, put "git push || git reset --soft HEAD^" in the
post-commit hook.  Richard should try that.  He may or may not ever be
back complaining that it forgot about a "git add".  In the meantime,
you can worry about fixing that problem (or finding somebody to test
my suggestions about stash and branching for you).

Re: VC mode and git

[Harald Hanche-Olsen]

Stephen J. Turnbull wrote:
> "Easy to proceed with fixing" is an impossible standard, when you're
> talking about people who don't follow instructions to the letter and
> probably don't remember exactly what they did.  For example, I have no
> fscking idea how Richard put his workspace into a state where git
> thinks a zillion source files are modified.

That one is easy: He did a pull. His local repo had been modified, since 
he had been doing some work there. And then the pull failed due to a 
merge conflict in lisp/ChangeLog. As a result, all the files resulting 
from the successful part of the merge are in the index, and hence marked 
as modified. There are a lot of them because a lot had been happening in 
the central repo while Richard was hacking on his own.

I am quite confident that all the changes he made are safely stored in 
the dca743f0941909a80e3f28c023977120b6203e20 commit in his local repo. 
The *only* possible data loss is in lisp/ChangeLog, since that was (I 
believe) in an edited, uncommitted state when he did the pull.

– Harald

Re: VC mode and git

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:
> I am quite confident that all the changes he made are safely stored in
> the dca743f0941909a80e3f28c023977120b6203e20 commit in his local repo.
> The *only* possible data loss is in lisp/ChangeLog, since that was (I
> believe) in an edited, uncommitted state when he did the pull.

Oh, but Richard: If you run “git reflog” and post the result it may 
further help us understand in more detail what has happened. Better yet, 
run it as

   git reflog | cat

in order to stop it from invoking the pager.

– Harald

Re: VC mode and git

[Andreas Schwab]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

>   git reflog | cat
>
> in order to stop it from invoking the pager.

git --no-pager

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:
> Harald Hanche-Olsen wrote:
>
> Oh, but Richard: If you run “git reflog” and post the result it may
> further help us understand in more detail what has happened. Better yet,
> run it as

   git --no-pager reflog

(thanks, Andreas). And also:

   git ls-files -u

which I expect will list up to three (!) staged versions of 
lisp/ChangeLog, and not much else.

– Harald

Re: VC mode and git

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

     > git ls-files -u

That gave no output.

-- 
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: VC mode and git

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

     > git reflog | cat

Here is the output.

dca743f HEAD@{0}: commit: Recognize more format variation. Automatically reshow decrypted text.
1a80be1 HEAD@{1}: commit: Echo area shows when displaying a mime message.
414e79f HEAD@{2}: commit: Prefer IceCat to Firefox and Iceweasel.
f1cea3e HEAD@{3}: checkout: moving from TEST to master
f1cea3e HEAD@{4}: checkout: moving from master to TEST
f1cea3e HEAD@{5}: pull: Fast-forward
3517da7 HEAD@{6}: clone: from rms@git.sv.gnu.org:/srv/git/emacs.git

-- 
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: VC mode and git

[Andreas Schwab]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> The *only* possible data loss is in lisp/ChangeLog, since that was (I
> believe) in an edited, uncommitted state when he did the pull.

git would have refused to start the merge if that were the case.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Harald Hanche-Olsen]

Andreas Schwab wrote:
> Harald Hanche-Olsen<hanche@math.ntnu.no>  writes:
>
>> The *only* possible data loss is in lisp/ChangeLog, since that was (I
>> believe) in an edited, uncommitted state when he did the pull.
>
> git would have refused to start the merge if that were the case.

If you say so. But then why do we see this warning from “git help merge”?

        Warning: Running git merge with non-trivial
        uncommitted changes is discouraged: while possible,
        it may leave you in a state that is hard to back out
        of in the case of a conflict.

– Harald

Re: VC mode and git

[Andreas Schwab]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> Andreas Schwab wrote:
>> Harald Hanche-Olsen<hanche@math.ntnu.no>  writes:
>>
>>> The *only* possible data loss is in lisp/ChangeLog, since that was (I
>>> believe) in an edited, uncommitted state when he did the pull.
>>
>> git would have refused to start the merge if that were the case.
>
> If you say so. But then why do we see this warning from “git help merge”?

That is about files that are not modified by the merge.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

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

  > If you say so. But then why do we see this warning from “git help merge”?

  >         Warning: Running git merge with non-trivial
  >         uncommitted changes is discouraged: while possible,
  >         it may leave you in a state that is hard to back out
  >         of in the case of a conflict.

Reportedly pull includes merge, so this implies that git pull is also
dangerous when you have made changes.

It usually takes weeks from when I write a change to when I check it
in to Savannah.  To check them in, I must first get the latest changes
from Savannah.  If I can't do a pull in that state, how can I ever
check them in?

(I am using the term "check in" to mean "put my changes into the
central repository".  How this breaks down into git operations is
implementation details.  I would rather not have to know the details,
but if git makes it necessary for me to know them, I will still think
of what I am doing as "check in" despite the cumbersome technicalities
required to carry it out.)

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> It usually takes weeks from when I write a change to when I check it
> in to Savannah.  To check them in, I must first get the latest changes
> from Savannah.  If I can't do a pull in that state, how can I ever
> check them in?

Check them in, then pull.  It's as simple as that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Harald Hanche-Olsen]

Andreas Schwab wrote:
> Richard Stallman<rms@gnu.org>  writes:
>
>> It usually takes weeks from when I write a change to when I check it
>> in to Savannah.  To check them in, I must first get the latest changes
>> from Savannah.  If I can't do a pull in that state, how can I ever
>> check them in?
>
> Check them in, then pull.  It's as simple as that.

But Richard just said that “checking in”‚ to him, means putting it in 
the central repository.

A better phrasing is:  Commit, then pull. Committing is a local 
operation. Checking in, as Richard sees it, is pushing.

Actually, I think “checking in” isn't even in the git vocabulary. Better 
not to use the term in order to avoid confusion.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 31 Mar 2015 17:34:41 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> Cc: stephen@xemacs.org, Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> Andreas Schwab wrote:
> > Richard Stallman<rms@gnu.org>  writes:
> >
> >> It usually takes weeks from when I write a change to when I check it
> >> in to Savannah.  To check them in, I must first get the latest changes
> >> from Savannah.  If I can't do a pull in that state, how can I ever
> >> check them in?
> >
> > Check them in, then pull.  It's as simple as that.
> 
> But Richard just said that “checking in”‚ to him, means putting it in 
> the central repository.
> 
> A better phrasing is:  Commit, then pull.

No, it's better for Richard to pull, then checkin.  That's closer to
what he is used to, and even if there's trouble (pull fails due to
uncommitted changes), that trouble is closer in spirit to what he
would have in a similar situation with CVS and bzr, so it would be
easier for him to understand the situation and fix it.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Tue, 31 Mar 2015 17:34:41 +0200
>> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
>> Cc: stephen@xemacs.org, Richard Stallman<rms@gnu.org>, emacs-devel@gnu.org
>>
>> But Richard just said that “checking in”‚ to him, means putting it in
>> the central repository.
>>
>> A better phrasing is:  Commit, then pull.
>
> No, it's better for Richard to pull, then checkin.  That's closer to
> what he is used to, and even if there's trouble (pull fails due to
> uncommitted changes), that trouble is closer in spirit to what he
> would have in a similar situation with CVS and bzr, so it would be
> easier for him to understand the situation and fix it.

Okay, now you have me terminally confused.

What do you mean by checkin here? Does it mean commit, or push? There is 
a huge difference. To be more specific, my suggestion is

   git commit
   git pull
   deal with conflicts, if any, ending with another git commit
   git push

Are you saying it is better for Richard to do git pull before git 
commit, if he has uncommited changes?

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 31 Mar 2015 18:36:32 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: schwab@suse.de, stephen@xemacs.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 31 Mar 2015 17:34:41 +0200
> >> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
> >> Cc: stephen@xemacs.org, Richard Stallman<rms@gnu.org>, emacs-devel@gnu.org
> >>
> >> But Richard just said that “checking in”‚ to him, means putting it in
> >> the central repository.
> >>
> >> A better phrasing is:  Commit, then pull.
> >
> > No, it's better for Richard to pull, then checkin.  That's closer to
> > what he is used to, and even if there's trouble (pull fails due to
> > uncommitted changes), that trouble is closer in spirit to what he
> > would have in a similar situation with CVS and bzr, so it would be
> > easier for him to understand the situation and fix it.
> 
> Okay, now you have me terminally confused.
> 
> What do you mean by checkin here?

The same as you: put in the upstream repository.  IOW, commit, then
push.

> To be more specific, my suggestion is
> 
>    git commit
>    git pull
>    deal with conflicts, if any, ending with another git commit
>    git push
> 
> Are you saying it is better for Richard to do git pull before git 
> commit, if he has uncommited changes?

Yes.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Tue, 31 Mar 2015 18:36:32 +0200
>> From: Harald Hanche-Olsen<hanche@math.ntnu.no>
>> CC: schwab@suse.de, stephen@xemacs.org, rms@gnu.org, emacs-devel@gnu.org
 >>
>> Are you saying it is better for Richard to do git pull before git
>> commit, if he has uncommited changes?
>
> Yes.

All right, then. Since I do not understand why this is not madness, it 
is perhaps time for me to withdraw from the discussion. Sorry if I have 
been sowing confusion.

– Harald

Re: VC mode and git

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

  > > Are you saying it is better for Richard to do git pull before git 
  > > commit, if he has uncommited changes?

  > Yes.

I think that's what I did, that caused this problem.
But I can't remember for certain.  It is possible that I had
committed all the changes and then did pull.

-- 
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: VC mode and git

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:

 > Actually, I think “checking in” isn't even in the git vocabulary. Better 
 > not to use the term in order to avoid confusion.

No, that's precisely why it's a good term for Richard to use.  The
unusual phrasing will alert others that Richard has different
semantics.  If he uses "commit" to mean "commit-and-push", that will
be confusing.

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 31 Mar 2015 10:07:26 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: schwab@suse.de, stephen@xemacs.org, emacs-devel@gnu.org
> 
> It usually takes weeks from when I write a change to when I check it
> in to Savannah.  To check them in, I must first get the latest changes
> from Savannah.  If I can't do a pull in that state, how can I ever
> check them in?

IME, the only situation where a pull can fail if you have uncommitted
changes is when your changes touch the same portions that were
meanwhile modified by someone else's commits in the repository.  Then
you'd have a merge conflict, and will have to fix it manually.

Otherwise, I always pull before committing in my local mirror, and it
generally doesn't fail.

Re: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> Reportedly pull includes merge, so this implies that git pull is also
> dangerous when you have made changes.

Dangerous in which way?

If you have committed your changes locally, and do a pull, and there are
no conflicts, will be a new commit on your master (the merge commit),
but no harm done otherwise.

If you get a conflict in the merge, git will not complete the commit
until the conflict is handled (much as any version control system).

If you have uncommitted changes and the merge in the pull command
doesn't touch any of the files with uncommitted changes, and there is no
conflict, there may be a new commit (the pull could also be a
fast-forward, in which case there is no commit), and your changes will
still be in the working directory.

If there is a conflict, the merged files with no conflict will be staged
for commit, both your local changes and the files will be seen as
unstaged modified files (but the conflicted files are shown as such, at
least in magit).

If the pull merge affects any of the files you have uncommitted changes
in, then git refuses to merge (refuses to overwrite your local changes).

You need to either stash your local changes, or put them on a local
commit before git will do the merge.

> It usually takes weeks from when I write a change to when I check it
> in to Savannah.  To check them in, I must first get the latest changes
> from Savannah.  If I can't do a pull in that state, how can I ever
> check them in?

You can do a pull.  The simplest way to avoid most of the possible
conflicts would be to
 git stash
 git pull
 git stash pop
before you commit.

But note that "git stash pop" can have conflicts, and git pull may have
conflicts (if you don't have any other local changes except your
uncommitted changes, ie. no local commits, then pull will never have
conflicts).

Re: VC mode and git

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

  > > Reportedly pull includes merge, so this implies that git pull is also
  > > dangerous when you have made changes.

  > Dangerous in which way?

I don't know.  The git documentation says it can cause some sort of
lossage, but was not specific.

  > If you get a conflict in the merge, git will not complete the commit
  > until the conflict is handled (much as any version control system).

1. Is that what happened to me?  I've sent the output of several
diagnostic commands; perhaps you can tell from them.

2. With CVS, merge conflicts are easy to handle -- just edit the file,
look for the <<< and >>> that indicate conflicts, and fix up each one.
Can I do it that way in Git?

  > If the pull merge affects any of the files you have uncommitted changes
  > in, then git refuses to merge (refuses to overwrite your local changes).

1. Is that what happened to me?  I've sent the output of several
diagnostic commands; perhaps you can tell from them.

2. If it doesn't show me the conflicts in the file, what can I do then?

  > You can do a pull.  The simplest way to avoid most of the possible
  > conflicts would be to
  >  git stash
  >  git pull
  >  git stash pop
  > before you commit.

  > But note that "git stash pop" can have conflicts, and git pull may have
  > conflicts (if you don't have any other local changes except your
  > uncommitted changes, ie. no local commits, then pull will never have
  > conflicts).

Once again, what can I do if it has conflicts?

-- 
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: VC mode and git

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> 2. With CVS, merge conflicts are easy to handle -- just edit the file,
> look for the <<< and >>> that indicate conflicts, and fix up each one.

And if you did something wrong you are lost.  No way to redo the merge.

> Can I do it that way in Git?

Yes, only much better.  If the merge went wrong in some way, just redo
it.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

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

  > Yes, only much better.  If the merge went wrong in some way, just redo
  > it.

Sorry, I do not understand you.

-- 
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: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

>> Yes, only much better.  If the merge went wrong in some way, just
>> redo it.

> Sorry, I do not understand you.

I think he means that, if you've committed or stashed your changes
before pulling, you can abort the pull's merge, and start again, without
losing your changes.

If you haven't saved your local changes, aborting the merge and starting
again isn't so easy.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Fri, 03 Apr 2015 09:27:56 +0200
> 
> >>>>> Richard Stallman <rms@gnu.org>:
> 
> >> Yes, only much better.  If the merge went wrong in some way, just
> >> redo it.
> 
> > Sorry, I do not understand you.
> 
> I think he means that, if you've committed or stashed your changes
> before pulling, you can abort the pull's merge, and start again, without
> losing your changes.
> 
> If you haven't saved your local changes, aborting the merge and starting
> again isn't so easy.

I don't understand why there's a need to use stash in this case.

The situation is that a pull was done and failed because of
conflicting local commits.  The merge part of the pull in this case is
already aborted.  All Richard needs to do is resolve the conflicts one
by one (AFAIU, he only had one to begin with, in a ChangeLog file),
and then do:

  git commit
  git push

(In general, one needs to "git add" each file whose conflicts were
resolved, but resolving the conflicts in Emacs should have invoked
"git add" automatically when each files with resolved conflicts is
saved, so no "git add" commands should be required at all.)

So why would Richard need to use "stash" in this situation?  It sounds
like an unnecessary complication.  Am I missing something?

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > The situation is that a pull was done and failed because of
 > conflicting local commits.  The merge part of the pull in this case
 > is already aborted.

"Abort" means *nothing is done* as far as I can tell from the
documentation and experimentation with a couple of toy repos.  In
particular, files that were modified on remote are *not* updated
locally (although the commits and dependent objects are in the origin
branch), and there are *no* conflict markers added to the file that
would have conflicts if the merge was conducted.

 > All Richard needs to do is resolve the conflicts one by one (AFAIU,
 > he only had one to begin with, in a ChangeLog file), and then do:
 > 
 >   git commit
 >   git push

I guess this procedure will create a commit without any of the most
recently pulled content.  He will need to do the merge again, which
may result in more conflicts.  (I can't be sure since I can't figure
out how he got the repo in that state.)

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Steinar Bang <sb@dod.no>,
>     emacs-devel@gnu.org
> Date: Fri, 03 Apr 2015 17:16:30 +0900
> 
>  > All Richard needs to do is resolve the conflicts one by one (AFAIU,
>  > he only had one to begin with, in a ChangeLog file), and then do:
>  > 
>  >   git commit
>  >   git push
> 
> I guess this procedure will create a commit without any of the most
> recently pulled content.  He will need to do the merge again, which
> may result in more conflicts.

If that's true (and I'm not sure it is), then the procedure after
resolving conflicts is simply

  git pull
  git push

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> The situation is that a pull was done and failed because of
> conflicting local commits.  The merge part of the pull in this case is
> already aborted.

But if so, where are all the modified files in the index coming from? My 
hypothesis is that they come from the merge. More precisely, I expect 
they are exact copies from origin/master.

> All Richard needs to do is resolve the conflicts one
> by one (AFAIU, he only had one to begin with, in a ChangeLog file),
> and then do:
>
>    git commit
>    git push

Agreed, though I don't think he should push without doing a sanity check 
first. Basically, “git diff origin/master” to check that he is merely 
committing his own changes. (I *think* that will be so, but I don't 
*know* it.) Also, he will need to do another git pull, possibly followed 
by resolving more conflicts, before being able to push.

> So why would Richard need to use "stash" in this situation?  It sounds
> like an unnecessary complication.  Am I missing something?

No need for a stash. If the result of fixing the ChangeLog and 
committing is not what is desired, that can be fixed later. There is no 
possible information loss from the proposed course of action, apart from 
in lisp/ChangeLog, and that shouldn't be hard to remedy.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 03 Apr 2015 10:34:23 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: Steinar Bang <sb@dod.no>, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > The situation is that a pull was done and failed because of
> > conflicting local commits.  The merge part of the pull in this case is
> > already aborted.
> 
> But if so, where are all the modified files in the index coming from? My 
> hypothesis is that they come from the merge. More precisely, I expect 
> they are exact copies from origin/master.

Yes, I think so too.  But then they are already in the index, and "git
commit" after resolving the conflicts should finish the merge by
creating a merge-commit with all the changes that were pulled in all
those files.

> > All Richard needs to do is resolve the conflicts one
> > by one (AFAIU, he only had one to begin with, in a ChangeLog file),
> > and then do:
> >
> >    git commit
> >    git push
> 
> Agreed, though I don't think he should push without doing a sanity check 
> first.  Basically, “git diff origin/master” to check that he is merely 
> committing his own changes.

Yes, that's always a Good Thing.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> So why would Richard need to use "stash" in this situation?  It sounds
> like an unnecessary complication.

No, you're right.  Keep it simple, no stash or rebase in the examples.

To commit:
 git commit
 git push

If push fails:
 git pull
 git push

If pull fails with conflicts, fix the conflict markers like in CVS, then
 git commit
 git push

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Fri, 03 Apr 2015 11:22:36 +0200
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > So why would Richard need to use "stash" in this situation?  It sounds
> > like an unnecessary complication.
> 
> No, you're right.  Keep it simple, no stash or rebase in the examples.
> 
> To commit:
>  git commit
>  git push
> 
> If push fails:
>  git pull
>  git push
> 
> If pull fails with conflicts, fix the conflict markers like in CVS, then
>  git commit
>  git push

Thanks.

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 01 Apr 2015 06:22:15 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>  > > Reportedly pull includes merge, so this implies that git pull is also
>   > > dangerous when you have made changes.
> 
>   > Dangerous in which way?
> 
> I don't know.  The git documentation says it can cause some sort of
> lossage, but was not specific.

I suggest that you disregard that hypothetical lossage.

>   > If you get a conflict in the merge, git will not complete the commit
>   > until the conflict is handled (much as any version control system).
> 
> 1. Is that what happened to me?  I've sent the output of several
> diagnostic commands; perhaps you can tell from them.

That was my conclusion, yes.

> 2. With CVS, merge conflicts are easy to handle -- just edit the file,
> look for the <<< and >>> that indicate conflicts, and fix up each one.
> Can I do it that way in Git?

Yes, you can.  The files with conflicts has the same merge-conflict
markers that you are used to.  When you edit a file with
merge-conflict markers, the development version (Emacs 25.0.50) should
automatically enter the smerge-mode, which is a minor mode with
support for that (see its documentation for a few useful commands).
Furthermore, for each file you save after fixing all the conflicts, VC
should automatically invoke Git with the "git add" command, so that
the de-conflicted file being saved is ready to be committed.

Once you fix all the conflicts, invoke "git commit" to complete the
merge (which "git pull" normally does automatically, but didn't do due
to the conflicts).  After that, you should "git push" to update the
repository on Savannah with your local commits.

I think this is very similar to what you used to do with CVS and bzr,
the only difference is that a singe commit command after fixing the
conflicts is replaced with 2 separate commands: first commit locally,
then push upstream.

Re: VC mode and git

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

> Once you fix all the conflicts, invoke "git commit" to complete the
> merge (which "git pull" normally does automatically, but didn't do due
> to the conflicts).  After that, you should "git push" to update the
> repository on Savannah with your local commits.

Just out of curiosity: what is supposed to be the way to perform that
commit from inside Emacs? vc-next-action on a file where I've resolved
the conflicts gets me:

fatal: cannot do a partial commit during a merge.

(I don't normally use vc-* at all)

Robert

Re: VC mode and git

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 01 Apr 2015 17:25:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Once you fix all the conflicts, invoke "git commit" to complete the
> > merge (which "git pull" normally does automatically, but didn't do due
> > to the conflicts).  After that, you should "git push" to update the
> > repository on Savannah with your local commits.
> 
> Just out of curiosity: what is supposed to be the way to perform that
> commit from inside Emacs? vc-next-action on a file where I've resolved
> the conflicts gets me:
> 
> fatal: cannot do a partial commit during a merge.

Doesn't "git commit" work from the shell prompt?

Re: VC mode and git

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 01 Apr 2015 17:25:02 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Once you fix all the conflicts, invoke "git commit" to complete the
>> > merge (which "git pull" normally does automatically, but didn't do due
>> > to the conflicts).  After that, you should "git push" to update the
>> > repository on Savannah with your local commits.
>> 
>> Just out of curiosity: what is supposed to be the way to perform that
>> commit from inside Emacs? vc-next-action on a file where I've resolved
>> the conflicts gets me:
>> 
>> fatal: cannot do a partial commit during a merge.
>
> Doesn't "git commit" work from the shell prompt?

Of course it does, but that's not the point. When you've done 'git pull'
and gotten conflicts, git won't let you do a commit that specifies a
filename since you're in the middle of a merge, and vc apparently
doesn't handle that case.

Robert

Re: VC mode and git

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 02 Apr 2015 09:01:33 +0200
> 
> >> Just out of curiosity: what is supposed to be the way to perform that
> >> commit from inside Emacs? vc-next-action on a file where I've resolved
> >> the conflicts gets me:
> >> 
> >> fatal: cannot do a partial commit during a merge.
> >
> > Doesn't "git commit" work from the shell prompt?
> 
> Of course it does, but that's not the point. When you've done 'git pull'
> and gotten conflicts, git won't let you do a commit that specifies a
> filename since you're in the middle of a merge, and vc apparently
> doesn't handle that case.

I think you are supposed to commit the entire changeset, after all the
conflicts are resolved.  Maybe it's worth a bug report against VC.

Re: VC mode and git

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 02 Apr 2015 09:01:33 +0200
>> 
>> >> Just out of curiosity: what is supposed to be the way to perform that
>> >> commit from inside Emacs? vc-next-action on a file where I've resolved
>> >> the conflicts gets me:
>> >> 
>> >> fatal: cannot do a partial commit during a merge.
>> >
>> > Doesn't "git commit" work from the shell prompt?
>> 
>> Of course it does, but that's not the point. When you've done 'git pull'
>> and gotten conflicts, git won't let you do a commit that specifies a
>> filename since you're in the middle of a merge, and vc apparently
>> doesn't handle that case.
>
> I think you are supposed to commit the entire changeset, after all the
> conflicts are resolved.  Maybe it's worth a bug report against VC.

Well, my changeset in this case consisted of exactly one file :)

I guess using vc-dir to commit might do it, but I think I'll just stick
to using magit.

Re: VC mode and git

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

  > I think you are supposed to commit the entire changeset, after all the
  > conflicts are resolved.  Maybe it's worth a bug report against VC.

I always commit an entire changeset -- that's why I use vc-dir -- but
the changeset is often not all of the files I have edited.  Over a few
weeks I may have fixed a few bugs in different files.  I commit the
different fixes separately.

vc-dir is good for that.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Fri, 03 Apr 2015 07:02:39 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
> I always commit an entire changeset -- that's why I use vc-dir -- but
> the changeset is often not all of the files I have edited.  Over a few
> weeks I may have fixed a few bugs in different files.  I commit the
> different fixes separately.

Do you also push each such commit immediately, or do you wait for all
of the fixes to be ready and committed, and then push them all in one
go?

If the former, then having uncommitted changes should not be a
problem, except if "git pull" complains about conflicts.  I'd suggest
to hold off your ChangeLog entries until just before you commit the
changeset, because most conflicts are caused by ChangeLog's.  (This
issue will disappear in a few days, when we stop maintaining ChangeLog
files in the repository.)

Re: VC mode and git

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

  > > I always commit an entire changeset -- that's why I use vc-dir -- but
  > > the changeset is often not all of the files I have edited.  Over a few
  > > weeks I may have fixed a few bugs in different files.  I commit the
  > > different fixes separately.

  > Do you also push each such commit immediately, or do you wait for all
  > of the fixes to be ready and committed, and then push them all in one
  > go?

I have only once tried to install changes with Git, so there is no
"usual" answer.  This time, I committed two or three change sets,
separately.  Then I think I did a pull again.

  >   I'd suggest
  > to hold off your ChangeLog entries until just before you commit the
  > changeset, because most conflicts are caused by ChangeLog's.

That's what I always do.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sat, 04 Apr 2015 10:48:03 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
>   > > I always commit an entire changeset -- that's why I use vc-dir -- but
>   > > the changeset is often not all of the files I have edited.  Over a few
>   > > weeks I may have fixed a few bugs in different files.  I commit the
>   > > different fixes separately.
> 
>   > Do you also push each such commit immediately, or do you wait for all
>   > of the fixes to be ready and committed, and then push them all in one
>   > go?
> 
> I have only once tried to install changes with Git, so there is no
> "usual" answer.  This time, I committed two or three change sets,
> separately.  Then I think I did a pull again.

My recommendation is to try pushing any change you commit that you
feel is ready to be pushed, as soon as you can, preferably right after
you commit it locally.  That will drive the probability of merge
conflicts during a pull even lower.

Re: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> I always commit an entire changeset -- that's why I use vc-dir -- but
> the changeset is often not all of the files I have edited.  Over a few
> weeks I may have fixed a few bugs in different files.  I commit the
> different fixes separately.

> vc-dir is good for that.

If this is your work pattern, you should commit all of your changesets
before attempting a push.

Ie.
 <commit changeset from vc-dir>
 <commit changeset from vc-dir>
 git push

Then if git fails because someone else have pushed since your last push, do
 git pull
 git push

If "git pull" gets conflicts, resolve the conflicts like with CVS, then
 git commit
 git push

Re: VC mode and git

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

  > If this is your work pattern, you should commit all of your changesets
  > before attempting a push.

Sometimes I have changes that should be installed, and other changes
in other files that are not ready for installation.  With vc-dir, that
has been easy to do.  How can I handle that with Git?

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sat, 04 Apr 2015 10:46:37 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>   > If this is your work pattern, you should commit all of your changesets
>   > before attempting a push.
> 
> Sometimes I have changes that should be installed, and other changes
> in other files that are not ready for installation.  With vc-dir, that
> has been easy to do.  How can I handle that with Git?

The same you did with CVS: just pull.  In most cases, this should
"just work".  It might fail if there are conflicts with stuff you pull
from upstream, in which case you should resolve the conflicts (like
you did with CVS).

Steinar's advice is valid, because having your changes committed
locally makes the probability that you will lose them in some rare
situations lower (or maybe zero).  So you should try committing
locally what you feel is ready to be committed.  But it shouldn't be
fatal if you don't.

I tried to make the instructions about this simpler and more clear,
please see http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs,
I'd appreciate your comments about the new version.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> The same you did with CVS: just pull.  In most cases, this should
> "just work".  It might fail if there are conflicts with stuff you pull
> from upstream, in which case you should resolve the conflicts (like
> you did with CVS).

Note that git will refuse to pull if there are uncommitted changes in
any of the files touched by the pull.

So in the minimal CVS-like workflow either one need to extend that
workflow to use stash in some cases, or one need to keep committing
files/changesets until the pull is able to succeed.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Sat, 04 Apr 2015 17:23:02 +0200
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > The same you did with CVS: just pull.  In most cases, this should
> > "just work".  It might fail if there are conflicts with stuff you pull
> > from upstream, in which case you should resolve the conflicts (like
> > you did with CVS).
> 
> Note that git will refuse to pull if there are uncommitted changes in
> any of the files touched by the pull.

I think it will succeed in fetching, and then refuse to merge.

But the way to handle this is the same as if the conflicted changes
are committed: fix the conflicts, and then "git pull" again.  Right?

> So in the minimal CVS-like workflow either one need to extend that
> workflow to use stash in some cases, or one need to keep committing
> files/changesets until the pull is able to succeed.

I'd like to avoid stashing in the CVS-like workflow, if at all
possible.

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> I think it will succeed in fetching, and then refuse to merge.

Correct.

> But the way to handle this is the same as if the conflicted changes
> are committed: fix the conflicts, and then "git pull" again.  Right?

No, that won't work: since the merge hasn't happened, there will be no
conflicts, just the uncommitted changes.

The only way to make git do the merge is to move away the uncommitted
changes, either by committing them, or by stashing them.

So to get out of the unpullable situation one either have to keep
committing changesets (and try a pull), or do
 git stash
 git pull
 git stash pop

(unfortunately the "git stash pop" may also have a conflict, and getting
out of fixing the conflict without committing, is sort-of-advanced git,
at least nothing to put in a simple workflow)

Re: VC mode and git

[martin rudalics]

 > The only way to make git do the merge is to move away the uncommitted
 > changes, either by committing them,

IIUC this will fail miserably with

git commit -a

as I sketched in the scenario I posted earlier.

martin

Re: VC mode and git

[Steinar Bang]

>>>>> martin rudalics <rudalics@gmx.at>:

>> The only way to make git do the merge is to move away the uncommitted
>> changes, either by committing them,

> IIUC this will fail miserably with

> git commit -a

> as I sketched in the scenario I posted earlier.

I think your problem in the scenario you posted was that one of your
merges with conflict didn't get committed, and git refused to do
anything else on that branch until it was committed or reset.

Possibly ChangeLog wasn't staged for commit once the conflict markers
had been removed? Possibly there were conflicts in other files.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Sat, 04 Apr 2015 18:09:58 +0200
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > I think it will succeed in fetching, and then refuse to merge.
> 
> Correct.
> 
> > But the way to handle this is the same as if the conflicted changes
> > are committed: fix the conflicts, and then "git pull" again.  Right?
> 
> No, that won't work: since the merge hasn't happened, there will be no
> conflicts, just the uncommitted changes.
> 
> The only way to make git do the merge is to move away the uncommitted
> changes, either by committing them, or by stashing them.

Right, so I amended the instructions by describing the commit
alternative.

Re: VC mode and git

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

  > The only way to make git do the merge is to move away the uncommitted
  > changes, either by committing them, or by stashing them.

  > So to get out of the unpullable situation one either have to keep
  > committing changesets (and try a pull), or do
  >  git stash
  >  git pull
  >  git stash pop

  > (unfortunately the "git stash pop" may also have a conflict, and getting
  > out of fixing the conflict without committing, is sort-of-advanced git,

I am not sure what the last sentence means.  Suppose git stash pop
reports a conflict.  Suppose I am willing to fix the conflict right
then, but I don't want to commit all those changes now (because some
should not be installed).  Is that straightforward to do?

If so, how?

-- 
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: VC mode and git

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

  > The same you did with CVS: just pull.

Since it makes pulling so difficult, perhaps we should
change its name to Teeth instead of Git.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 13:43:26 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: sb@dod.no, emacs-devel@gnu.org
> 
>   > The same you did with CVS: just pull.
> 
> Since it makes pulling so difficult, perhaps we should
> change its name to Teeth instead of Git.

:-)

I don't think it makes it more difficult than CVS, it just manifests
the same basic problem -- conflicts with local changes -- differently.

Re: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

>> Dangerous in which way?

> I don't know.  The git documentation says it can cause some sort of
> lossage, but was not specific.

As Eli said in a different message: disregard this as hypothetical.

>> If you get a conflict in the merge, git will not complete the commit
>> until the conflict is handled (much as any version control system).

> 1. Is that what happened to me?  I've sent the output of several
> diagnostic commands; perhaps you can tell from them.

I haven't followed the diagnostics too closely, but I know that you had
several unpushed commits, and your ChangeLog changes in one of these
commits conflicted with savannah's version of the ChangeLog.

What I'm not sure of is whether or not you also had uncommitted changes?
Did you commit before you pulled? Or did you commit and then pull?

> 2. With CVS, merge conflicts are easy to handle -- just edit the file,
> look for the <<< and >>> that indicate conflicts, and fix up each one.
> Can I do it that way in Git?

As Eli says: yes

 1. Edit the file, search for the conflict markers and fix them
 2. git add name-of-conflicted-file ("git add ChangeLog" in your case)
 3. git commit

The commit will open an editor, asking you to complete/confirme the
commit message (there will be a default message there indicating that
this is a merge commit, and what files conflicted in the merge. I
usually add stuff like "Manually resolved conflicted files" when I have
fixed things, but you can just close the editor and let the default
message stand).

What editor git chooses, depends on your EDITOR environment variable (I
use emacsclient).

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 01 Apr 2015 17:43:46 +0200
> 
> > 2. With CVS, merge conflicts are easy to handle -- just edit the file,
> > look for the <<< and >>> that indicate conflicts, and fix up each one.
> > Can I do it that way in Git?
> 
> As Eli says: yes
> 
>  1. Edit the file, search for the conflict markers and fix them
>  2. git add name-of-conflicted-file ("git add ChangeLog" in your case)

This 2nd item should be done automatically by VC when you save a file
whose conflicts were resolved.

>  3. git commit

Re: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > It usually takes weeks from when I write a change to when I check
 > it in to Savannah.  To check them in, I must first get the latest
 > changes from Savannah.  If I can't do a pull in that state, how can
 > I ever check them in?

    git stash
    git pull
    git stash apply
    # fix any conflicts
    git stash drop
    git commit <arguments>
    git push

If conflict fixing gets wedged, don't "stash drop" yet.  Instead, "git
reset --hard", then go to "git stash apply", and continue from there.

Andreas's suggestion[1] is simpler but makes the history DAG ugly.  In
particular, your commit message may get buried deep in the commit log
behind those of all of the pulled commits.  You'll have to ask Stefan
and the other frequent committers if they care about the ugliness.
Some do and some don't.

    git commit
    git pull
    # fix any conflicts
    # if fixed conflicts, commit
    git push

Note that if the conflict resolution work gets wedged, the "git reset
--hard" strategy works here as well.  You need to pull again rather
than "stash apply", of course.[2]


Footnotes: 
[1]  Andreas was laconic as ever, but I'm pretty sure the intended
strategy is to commit locally as soon as the change is complete to your
satisfaction, then when you have net access to Savannah do the pulling
and pushing.

[2]  This "pull" operation can also be done without a net connection,
but you may need to use "git merge origin/master" instead of "git pull".

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 01 Apr 2015 02:11:29 +0900
> Cc: schwab@suse.de, Harald Hanche-Olsen <hanche@math.ntnu.no>,
> 	emacs-devel@gnu.org
> 
> Andreas's suggestion[1] is simpler but makes the history DAG ugly.  In
> particular, your commit message may get buried deep in the commit log
> behind those of all of the pulled commits.  You'll have to ask Stefan
> and the other frequent committers if they care about the ugliness.

We don't.

Re: VC mode and git

[Alan Mackenzie]

Hello, Andreas.

On Tue, Mar 31, 2015 at 09:35:07AM +0200, Andreas Schwab wrote:
> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> > The *only* possible data loss is in lisp/ChangeLog, since that was (I
> > believe) in an edited, uncommitted state when he did the pull.

> git would have refused to start the merge if that were the case.

That is the case in the current git version.  I think that in previous
versions, git took the liberty of simply overwriting changed files in
the workspace.  At least, I think that's what happened to me a couple of
times around the beginning of the year.

Why can't git simply merge changes properly into the workspace, thus
saving users the unwelcome hassle of, e.g., git stash followed by git
merge followed by git stash pop?

> Andreas.

> -- 
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> That is the case in the current git version.  I think that in previous
> versions, git took the liberty of simply overwriting changed files in
> the workspace.  At least, I think that's what happened to me a couple of
> times around the beginning of the year.

No, it never did that.  Unlike CVS, git is very serious about not
overwriting uncommitted changes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > That is the case in the current git version.  I think that in previous
 > versions, git took the liberty of simply overwriting changed files in
 > the workspace.

git has never done that, and never will (if it does, there will
immediately be a fork that doesn't and all sane users will switch).

git reset --hard will do that, and there may be a --force option to
checkout that will do that.  But you have to explicitly request git to
overwrite files that are not in the state that git last committed
them, and as far as I know merge never does that.  (There may be
circumstances where it will do a 3-way merge on an uncommitted file,
but normally it will balk, and always has done so AFAICR.)

Note that all VCSes have the equivalent of git reset --hard.

 > Why can't git simply merge changes properly into the workspace, thus
 > saving users the unwelcome hassle of, e.g., git stash followed by git
 > merge followed by git stash pop?

It does, the same way that bzr or Mercurial does.[1]  I don't see why you
would think otherwise.


Footnotes: 
[1]  There are slight differences in algorithms, but they mostly don't
make a difference -- you'll get the same result.

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Tue, Mar 31, 2015 at 06:24:46PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > That is the case in the current git version.  I think that in previous
>  > versions, git took the liberty of simply overwriting changed files in
>  > the workspace.

> git has never done that, and never will (if it does, there will
> immediately be a fork that doesn't and all sane users will switch).

I lost some changes in my working directory after doing something like
git pull.  I can't remember the details any more.  I was able to
reconstruct the changes without too much difficulty.

> git reset --hard will do that, and there may be a --force option to
> checkout that will do that.  But you have to explicitly request git to
> overwrite files that are not in the state that git last committed
> them, and as far as I know merge never does that.  (There may be
> circumstances where it will do a 3-way merge on an uncommitted file,
> but normally it will balk, and always has done so AFAICR.)

> Note that all VCSes have the equivalent of git reset --hard.

>  > Why can't git simply merge changes properly into the workspace, thus
>  > saving users the unwelcome hassle of, e.g., git stash followed by git
>  > merge followed by git stash pop?

> It does, the same way that bzr or Mercurial does.[1]  I don't see why you
> would think otherwise.

Partly due to the following bug report which is near the start of the
git-merge man page:  "Warning: Running git merge with non-trivial
uncommitted changes is discouraged: while possible, it may leave you in a
state that is hard to back out of in the case of a conflict.".  I can't
imagine why the git maintainers don't fix this.

With git pull, if there are changes in the working directory, the merge
(i.e. merge from remote/master into master) part of the operation is
aborted before it starts, giving a message describing its refusal.  It
does this even when there are no conflicts to deal with.

Mercurial will complete hg pull regardless of any changes in its working
directory; in the case of conflicts it may leave several heads which
require merging.

Part of the problem is that the git-merge man page doesn't say that it
messes with the working tree (or, more precisely, it vaguely alludes to
it in the small print several hundred pages down).  In fact, it doesn't
say up front _what_ it is merging, or where the merged result goes - it
merely says "Join two or more development histories together", leaving it
as an exercise for the reader to figure out exactly what is meant by a
"development history".  By contrast, hg merge is documented concisely and
adequately as "merge another revision into working directory".


> Footnotes: 
> [1]  There are slight differences in algorithms, but they mostly don't
> make a difference -- you'll get the same result.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> With git pull, if there are changes in the working directory, the merge
> (i.e. merge from remote/master into master) part of the operation is
> aborted before it starts, giving a message describing its refusal.  It
> does this even when there are no conflicts to deal with.

Only if you use --rebase.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Tue, 31 Mar 2015 13:02:05 +0200
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Harald Hanche-Olsen <hanche@math.ntnu.no>, rms@gnu.org, emacs-devel@gnu.org
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > With git pull, if there are changes in the working directory, the merge
> > (i.e. merge from remote/master into master) part of the operation is
> > aborted before it starts, giving a message describing its refusal.  It
> > does this even when there are no conflicts to deal with.
> 
> Only if you use --rebase.

Perhaps Alan has that in his .gitconfig?

Re: VC mode and git

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> Part of the problem is that the git-merge man page doesn't say that it
> messes with the working tree

Because it doesn't do that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Steinar Bang]

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

> I lost some changes in my working directory after doing something like
> git pull.  I can't remember the details any more.  I was able to
> reconstruct the changes without too much difficulty.

I've have *never* had git overwrite my changes except using "git reset
--hard" or any of the "--force" arguments.

> Partly due to the following bug report which is near the start of the
> git-merge man page:  "Warning: Running git merge with non-trivial
> uncommitted changes is discouraged: while possible, it may leave you in a
> state that is hard to back out of in the case of a conflict.".  I can't
> imagine why the git maintainers don't fix this.

Their fix is to ask you to commit (or stash) before you pull (which is
fetch followed by merge).

If the commits stops because if something, you will have a workspace
with some staged files, some unstaged files holding conflicted files,
and some unstaged files holding your uncommitted changes (potentially
there could be staged files unrelated to the merge as well, but anyone
knowing how to stage files have probably committed before the pull...).

In short: it can be difficult to know what changes belongs to the merge
and what were local uncommitted changes prior to the merge.  One
heuristic could be that the unconflicted uncommitted changes don't
belong to the merge, but it if was that simple I suspect that this would
already be the case.

> With git pull, if there are changes in the working directory, the merge
> (i.e. merge from remote/master into master) part of the operation is
> aborted before it starts, giving a message describing its refusal.  It
> does this even when there are no conflicts to deal with.

> Mercurial will complete hg pull regardless of any changes in its working
> directory; in the case of conflicts it may leave several heads which
> require merging.

FWIW git completes the fetch before doing the merge, so all the upstream
changes are present and can be manually merged.

> Part of the problem is that the git-merge man page doesn't say that it
> messes with the working tree (or, more precisely, it vaguely alludes to
> it in the small print several hundred pages down).  In fact, it doesn't
> say up front _what_ it is merging, or where the merged result goes - it
> merely says "Join two or more development histories together", leaving it
> as an exercise for the reader to figure out exactly what is meant by a
> "development history".

This chapter of "Pro Git", is quite good:
 http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

Re: VC mode and git

[Alan Mackenzie]

Hello, Steinar.

On Tue, Mar 31, 2015 at 02:42:14PM +0200, Steinar Bang wrote:
> >>>>> Alan Mackenzie <acm@muc.de>:

> > I lost some changes in my working directory after doing something like
> > git pull.  I can't remember the details any more.  I was able to
> > reconstruct the changes without too much difficulty.

> I've have *never* had git overwrite my changes except using "git reset
> --hard" or any of the "--force" arguments.

I've never used git reset or a git --force argument.  I did lose some
changes, however.

> > Partly due to the following bug report which is near the start of the
> > git-merge man page:  "Warning: Running git merge with non-trivial
> > uncommitted changes is discouraged: while possible, it may leave you in a
> > state that is hard to back out of in the case of a conflict.".  I can't
> > imagine why the git maintainers don't fix this.

> Their fix is to ask you to commit (or stash) before you pull (which is
> fetch followed by merge).

That's a fix?  So every time I want to do a pull I have to stash, pull,
unstash.  Yuck!  A proper fix would be for merge to actually merge the
new changes into the working directory.

> If the commits stops because if something, you will have a workspace
> with some staged files, some unstaged files holding conflicted files,
> and some unstaged files holding your uncommitted changes (potentially
> there could be staged files unrelated to the merge as well, but anyone
> knowing how to stage files have probably committed before the pull...).

Not me.  In my normal workflow, I commit at the last minute, then push.
Just before committing, I get the latest changes from savannah, do any
necessary merging, then commit and push as quickly as possible.  This is
to minimise the hassle which invariably occurs when other people's
commits get mixed up with my own.  Is it really too much to expect that
git merge should merge these new fetched changes into my working
directory?

> In short: it can be difficult to know what changes belongs to the merge
> and what were local uncommitted changes prior to the merge.

I don't know what you mean by "the" merge.  When one mixes up committing
with staging with fetching with pushing, inevitably there will sometimes
be merge operations required all over the place.

> One heuristic could be that the unconflicted uncommitted changes don't
> belong to the merge, ...

Sorry, this is ceasing to make sense to me.  I can't visualise what
you're trying to say.  When there are uncommitted changes and some merge
takes place at a place where these changes are, the changes can't avoid
being part of that merge.

> ..., but it if was that simple I suspect that this would already be the
> case.

> > With git pull, if there are changes in the working directory, the merge
> > (i.e. merge from remote/master into master) part of the operation is
> > aborted before it starts, giving a message describing its refusal.  It
> > does this even when there are no conflicts to deal with.

> > Mercurial will complete hg pull regardless of any changes in its working
> > directory; in the case of conflicts it may leave several heads which
> > require merging.

> FWIW git completes the fetch before doing the merge, so all the upstream
> changes are present and can be manually merged.

I think I'm OK with the fetch part.  It's the merge part I have
difficulties with.

> > Part of the problem is that the git-merge man page doesn't say that it
> > messes with the working tree (or, more precisely, it vaguely alludes to
> > it in the small print several hundred pages down).  In fact, it doesn't
> > say up front _what_ it is merging, or where the merged result goes - it
> > merely says "Join two or more development histories together", leaving it
> > as an exercise for the reader to figure out exactly what is meant by a
> > "development history".

> This chapter of "Pro Git", is quite good:
>  http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

It may be quite good, but it's information density is very low.  It's
written for beginners in VCS.  Every time I read, yet again, that VCSs
have the concept of a branch and what it's used for, my eyes glaze over,
and I start subconsciously skimming the text in the hope of coming across
something solid and useful.

The information density in the git-merge man page is low in a different
way: being so vague and imprecise it makes little sense on its own,
because you've got to keep searching externally for information needed to
get meaning out of it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > I've never used git reset or a git --force argument.  I did lose
 > some changes, however.

The only other possibilities I can think of is that for some reason
you nuked them yourself and forgot about it (perhaps you never saved
them), or that you "lost" them on a different branch, and they're
still in your repo, you just don't know where to find them.

 > That's a fix?  So every time I want to do a pull I have to stash, pull,
 > unstash.  Yuck!  A proper fix would be for merge to actually merge the
 > new changes into the working directory.

You may think that's a fix, but the git developers will call it a bug,
because it's irreversible -- there's no way for git to get back to the
pre-merge state, ensuring that your uncommitted changes are preserved.

And they're in good company: Mercurial won't allow you to do that *at
all* AFAICT (and the restriction is *not* documented in that man page
you think is so concise and adequate), and Bazaar requires that you
use "bzr merge --force".  I really don't understand how you can
criticize git alone for this.

 > Not me.  In my normal workflow, I commit at the last minute, then
 > push.

Risk-lover!  No wonder you lose changes.

 > Just before committing, I get the latest changes from savannah, do
 > any necessary merging, then commit and push as quickly as possible.
 > This is to minimise the hassle which invariably occurs when other
 > people's commits get mixed up with my own.

I think that "git pull --rebase" was made in heaven for you.

 > Is it really too much to expect that git merge should merge these
 > new fetched changes into my working directory?

If you have uncommitted changes, yes, it's too much to expect.  See
above.

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Wed, Apr 01, 2015 at 02:38:34AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > I've never used git reset or a git --force argument.  I did lose
>  > some changes, however.

> The only other possibilities I can think of is that for some reason
> you nuked them yourself and forgot about it (perhaps you never saved
> them), or that you "lost" them on a different branch, and they're
> still in your repo, you just don't know where to find them.

Maybe you're right.  I can't remember any more.

>  > That's a fix?  So every time I want to do a pull I have to stash, pull,
>  > unstash.  Yuck!  A proper fix would be for merge to actually merge the
>  > new changes into the working directory.

> You may think that's a fix, but the git developers will call it a bug,
> because it's irreversible -- there's no way for git to get back to the
> pre-merge state, ensuring that your uncommitted changes are preserved.

Irreversable?  Any patch operation without conflicts is reversable, and
if there are conflicts, a backup of the original should have been made by
the patch program.

Anyhow, there are lots of irreversable things that happen in a VCS
repository.  The act of having committed, or merged, or whatever cannot,
with some exceptions, be reversed.

> And they're in good company: Mercurial won't allow you to do that *at
> all* AFAICT (and the restriction is *not* documented in that man page
> you think is so concise and adequate), ....

It is documented in the hg page.  It says (under merge): "The current
working directory is updated with all changes made in the requested
revision since the last common predecessor revision.".  If this doesn't
work when a file in the W.D. has been changed, that looks like a bug,
whether in the code or the documentation.

> .... and Bazaar requires that you use "bzr merge --force".  I really
> don't understand how you can criticize git alone for this.

Because it's only git that's ever given me problems in this respect.  I
don't recall ever having problems with bzr update when I had uncommitted
changes.  I use hg in such a way that mergeing is rarely, if ever,
needed.

>  > Not me.  In my normal workflow, I commit at the last minute, then
>  > push.

> Risk-lover!  No wonder you lose changes.

I do not love risk.  The risk of getting my repository in an inextricable
tangle, like Richard has done, far outweighs any supposed risks of
just-in-time committing.

>  > Just before committing, I get the latest changes from savannah, do
>  > any necessary merging, then commit and push as quickly as possible.
>  > This is to minimise the hassle which invariably occurs when other
>  > people's commits get mixed up with my own.

> I think that "git pull --rebase" was made in heaven for you.

I think I've used this at one time or another.

>  > Is it really too much to expect that git merge should merge these
>  > new fetched changes into my working directory?

> If you have uncommitted changes, yes, it's too much to expect.  See
> above.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:
 
 > Irreversable?  Any patch operation without conflicts is reversable, and
 > if there are conflicts, a backup of the original should have been made by
 > the patch program.

In a VCS, backup is spelled C-O-M-M-I-T.  Which is exactly what you
say you don't want to do.  *shrug*

 > Anyhow, there are lots of irreversable things that happen in a VCS
 > repository.  The act of having committed, or merged, or whatever
 > cannot, with some exceptions, be reversed.

Of course.  But I mean irreversible changes to the working tree.

 > It is documented in the hg page.  It says (under merge): "The current
 > working directory is updated with all changes made in the requested
 > revision since the last common predecessor revision.".  If this doesn't
 > work when a file in the W.D. has been changed, that looks like a bug,
 > whether in the code or the documentation.

The code won't permit.

 > > .... and Bazaar requires that you use "bzr merge --force".  I really
 > > don't understand how you can criticize git alone for this.
 > 
 > Because it's only git that's ever given me problems in this
 > respect.  I don't recall ever having problems with bzr update when
 > I had uncommitted changes.  I use hg in such a way that mergeing is
 > rarely, if ever, needed.

It seems bzr update doesn't have that restriction.  I don't know why
not, bzr merge does have it.  Both are so documented.  My experience
with hg in XEmacs is that when other developers are active, I need an
explicit merge frequently.

If bzr and hg don't give you problems but git does, then either your
git workflow deviates substantially from the workflows you use with
bzr and hg, or you've just been lucky to not get nasty conflicts that
are difficult to resolve with bzr and hg.  I suspect it's the latter,
and the big difference is the projects, not the VCSes.  Specifically,
I suppose Emacs gets a lot more changes from other developers per unit
time than your other projects do.

 > I do not love risk.  The risk of getting my repository in an
 > inextricable tangle, like Richard has done, far outweighs any
 > supposed risks of just-in-time committing.

Richard's repo is tangled *because* he, like you, doesn't commit until
he's ready to push.  If you keep your changes in commits instead of
the working tree, it's *very* hard to get inextricably tangled in git
because a quick reset puts you back in control, in a known state.

Re: VC mode and git

[Harald Hanche-Olsen]

Stephen J. Turnbull wrote:
> Richard's repo is tangled *because* he, like you, doesn't commit until
> he's ready to push.

That's overstating it; it is clear from his reflog (posted to the list) 
that he committed three times before the disaster. He did neglect to 
commit *once* before pulling, that is true. I used to think that is what 
caused his problems too, but Eli says he *should* pull before 
committing, so that can't be the reason.

– Harald

Re: VC mode and git

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:
 > Stephen J. Turnbull wrote:

 > > Richard's repo is tangled *because* he, like you, doesn't commit until
 > > he's ready to push.
 > 
 > That's overstating it;

OK, I'll concede that it's overstatement to say that it has been
proven to be the reason they have trouble.

Still, it's a plausible line of argument to say that the longer the
time between pulls, the more likely that a pull will cause a conflict
*and* touch a lot of files.  The number of files touched will only be
visible to the user when there is a conflict, otherwise the merge is
silent (unless the user directly investigates).  In Richard's case, he
testifies to weeks between pulls.  I don't know how long Alan goes
between pulls (where "how long" should be measured in number of
others' commits or maybe number of files touched), but he's probably
not close to Richard.  So I admit this is hardly well-calibrated.

 > but Eli says he *should* pull before committing, so that can't be
 > the reason.

Eli says it's OK to do so; AFAIK Eli is basically neutral towards
others' preferred workflows.  But I don't think Eli has a theory of
git that says it's OK, just his own experience.  But I rather doubt
Eli goes more than a couple days between pulls, so he would be
unlikely to see startling numbers of files touched, whereas Richard is
likely to run into that if he does have conflict.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 01 Apr 2015 16:14:06 +0900
> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> 
> > but Eli says he *should* pull before committing, so that can't be
>  > the reason.
> 
> Eli says it's OK to do so; AFAIK Eli is basically neutral towards
> others' preferred workflows.  But I don't think Eli has a theory of
> git that says it's OK, just his own experience.

I explained in a previous message what I meant by "it's OK" in this
case.

> But I rather doubt Eli goes more than a couple days between pulls,
> so he would be unlikely to see startling numbers of files touched,
> whereas Richard is likely to run into that if he does have conflict.

I generally pull every day, sometimes several times.  I also have the
git-merge-changelog driver installed, so conflicts due to ChangeLog
files almost never happen to me.

Re: VC mode and git

[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 Richard's case, he
  > testifies to weeks between pulls.

That is the way I need to do it.  There is nothing wrong with this,
and our previous version control systems supported it with no trouble.

-- 
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: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 >   >   In Richard's case, he
 >   > testifies to weeks between pulls.
 > 
 > That is the way I need to do it.  There is nothing wrong with this,

You protest too much.  Nobody said that there was anything wrong with
your timing of pulls.  I'm sure most of us have projects where we
often pull only with intervals of weeks or months.  The question is
how to deal with that.

 > and our previous version control systems supported it with no
 > trouble.

Of course, git does too!  What git doesn't do is support your CVS/bzr
workflow without changes.  git itself will resist incorporating the
changes you want, I'm pretty sure.  ESR has resisted the changes you
suggest to vc.el.

The easy road for you and Alan is to learn a git-adapted workflow, or
perhaps adopt the hook that Stefan advocates[1].  (Really, it is
easier.)  If you two had spent as much effort learning git as you have
on what has basically been a flamewar, you'd be have a reasonably
problem-free (VCS) workflow already, without changing your programming
workflows.  IMHO YMMV, but actually implementing the changes will be a
lot of work, and integration to the upstream projects will be an
uphill battle.

And that's why I think that what "everybody does" is relevant.  You
ask "why doesn't git (or vc.el) support the same workflow as CVS?"
The answer is quite complicated, actually, but from your point of view
can be proxied by "the maintainers don't want to".  Since you are
apparently a small minority and clearly "refusenik" in nature, the
maintainers are hardly motivated to make efforts on your behalf.

I believe it unlikely that there's little chance that vc.el will
address your needs directly (and zero that git will).  Your protests
that there must be lots of developers like you is empirically
unsupported (doesn't mean it's not true, just that your introspective
evidence isn't a head count), and to some extent the maintainers
believe supporting a CVS-style workflow is counterproductive.

Specifically, there *is* a lot of evidence that people who have tried
git-adapted workflows quickly learn to like them (even if they never
learn to really like git!)  I often get replies like "this is cool/
surprisingly effective, too bad it's not default/requires specifying
an option/isn't more discoverable" when I help people tweak their
workflows.  I'm sure the maintainers get the same response only more
so.


Footnotes: 
[1]  Apologies to the person who actually proposed it, I forget who
you were.

Re: VC mode and git

[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 Richard's case, he
  >  >   > testifies to weeks between pulls.
  >  > 
  >  > That is the way I need to do it.  There is nothing wrong with this,

  > You protest too much.  Nobody said that there was anything wrong with
  > your timing of pulls.

Someone did, but it isn't quoted above.  It was in a previous message.

So are you saying that, if I criticize the demand that I change my
way of working, that is proof that I should change it?
"You complained, so you're wrong"??

You can't make that valid by misusing a famous quotation.

Re: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 >   > You protest too much.  Nobody said that there was anything
 >   > wrong with your timing of pulls.
 > 
 > Someone did, but it isn't quoted above.  It was in a previous
 > message.

Then quote them, please.  Not me.

 > So are you saying that, if I criticize the demand that I change my
 > way of working, that is proof that I should change it?

No.  There are good reasons why you would be better off changing
it.[1]  Characterizing arguments that you should as "demands" is
inaccurate.  What people are *demanding* is that you not make or
instigate changes to Emacs for your convenience that would force
*them* to change their ways of working.

Footnotes: 
[1]  I concede that you have not accepted them.  "Good" is only my
partially informed opinion.

Re: VC mode and git

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

  > The easy road for you and Alan is to learn a git-adapted workflow, or
  > perhaps adopt the hook that Stefan advocates[1].

You seem ready to gloat to see people forced to work as Git demands,
but don't start gloating just yet.  I may do my own local version
control, and not touch the Git repository except to install changes in
Savannah.  Or I may post my bug fixes to the list and leave it to
others to install them.

  > I believe it unlikely that there's little chance that vc.el will
  > address your needs directly

I can make that a certainty by installing changes myself.  I've already
come to agreement with Stefan.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Wed, 01 Apr 2015 08:18:56 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> 
>     Richard's repo is tangled *because* he, like you, doesn't commit until
>     he's ready to push.
> 
> That's overstating it; it is clear from his reflog (posted to the list) that he committed three times before the disaster. He did neglect to commit *once* before pulling, that is true. I used to think that is what caused his problems too, but Eli says he *should* pull before committing, so that can't be the reason.

No, this is a misunderstanding.  I didn't say that pulling before
committing will never cause any problems, I just said that problems it
could cause, such as this one, will be easier for Richard to
understand, because they are very similar to what happens with CVS in
the same situation.

In any case, whether he pulls before checkin, or tries to checkin and
if that fails, commits locally, then pulls, then retries the checkin,
Richard will have to learn how to deal with the failure.  I just think
it will be easier for him to adapt to the former than to the latter.
But it's for Richard to decide, obviously.

In addition, Richard should install the git-merge-changelog driver (or
wait until we stop using ChangeLog files), because then the merge
conflicts during pull with uncommitted changes will be much more rare.

Re: VC mode and git

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

The reason I don't commit a change immediately after I write it is
that I want to test it in real (and varied) use.  Sometimes I find
bugs and have to change it.  After some period in which it works well,
I decide it is ready to install.

-- 
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: VC mode and git

[Harald Hanche-Olsen]

Richard Stallman wrote:
> The reason I don't commit a change immediately after I write it is
> that I want to test it in real (and varied) use.  Sometimes I find
> bugs and have to change it.  After some period in which it works well,
> I decide it is ready to install.

That is a good reason. However, for your information there is the 
variant “git commit --amend”, which as the option suggests amends the 
current commit. Just “git add“ the files you changed and run “git commit 
--amend”. It also lets you edit the commit message. After discovering 
this option, I find I am less fearful of making premature commits, since 
they are easily fixed. (But not after pushing, of course. That way lies 
madness.)

– Harald

Re: VC mode and git

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:
 > Richard Stallman wrote:
 > > The reason I don't commit a change immediately after I write it is
 > > that I want to test it in real (and varied) use.  Sometimes I find
 > > bugs and have to change it.  After some period in which it works well,
 > > I decide it is ready to install.
 > 
 > That is a good reason.

But not sufficient, IMHO.  It has its plus side from the point of view
of tidiness.  However, as Eli describes in more detail, it is a good
idea to record the history of fixes and enhancements.  This is *very*
useful to third-party maintainers who want to preserve the original
developer's intent.  Proverbs about "the only thing we learn from
history"[1] notwithstanding, people can and do learn from others'
mistakes and improvements.


Footnotes: 
[1]  "... is that people don't learn from history."

Re: VC mode and git

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

  > That is a good reason. However, for your information there is the 
  > variant “git commit --amend”, which as the option suggests amends the 
  > current commit. Just “git add“ the files you changed and run “git commit 
  > --amend”.

Maybe vc-dir should have a command to do this.

-- 
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: VC mode and git

[Steinar Bang]

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

> I've never used git reset or a git --force argument.  I did lose some
> changes, however.

I agree with Stephen's assesments here.

>> Their fix is to ask you to commit (or stash) before you pull (which is
>> fetch followed by merge).

> That's a fix?  So every time I want to do a pull I have to stash, pull,
> unstash.

If you want to work with uncommitted changes on a tracking branch, yes.

Note: you can always just try a pull first, it will stop if it needs to
merge some of the files you have changes in.

Ie. with no conflicts betwen pull and your modified files:
 git pull
 git commit
 git push
and with conflicts between pull and your modified files:
 git pull
 <oops! pull wants to merge some of your open files>
 git stash
 git pull
 git stash pop
 git commit
 git push

Or you can just do the stash anyway, even if it's needed or not:
git stash
git pull
git stash pop
git commit
git push

Or:
 git commit
 git pull --rebase
 git push
(forgive me, Eli, I said the "r" word...)

> Yuck!  A proper fix would be for merge to actually merge the new
> changes into the working directory.

Um... no.  I agree with Stephen here also.

> Not me.  In my normal workflow, I commit at the last minute, then push.
> Just before committing, I get the latest changes from savannah, do any
> necessary merging, then commit and push as quickly as possible.  This is
> to minimise the hassle which invariably occurs when other people's
> commits get mixed up with my own.  Is it really too much to expect that
> git merge should merge these new fetched changes into my working
> directory?

Then either always do this:
Or you can just do the stash anyway, even if it's needed or not:
git stash
git pull
git stash pop
git commit
git push

Or, this:
 git commit
 git pull --rebase
 git push

>> In short: it can be difficult to know what changes belongs to the merge
>> and what were local uncommitted changes prior to the merge.

> I don't know what you mean by "the" merge.

The merge part of "pull".  "git pull" is actually:
 git fetch
 git merge origin/master

> When one mixes up committing with staging with fetching with pushing,
> inevitably there will sometimes be merge operations required all over
> the place.

Not sure what you mean here.

>> One heuristic could be that the unconflicted uncommitted changes don't
>> belong to the merge, ...

> Sorry, this is ceasing to make sense to me.  I can't visualise what
> you're trying to say.

You have the following modified files in the workspace:
 ChangeLog
 a.c
 b.c
 c.c
 d.c
and then you modify a.c and c.c and in magit you will see:
 Unstaged changes:
          Modified a.c
          Modified c.c

and then you pull, and that results in d.c being succsessfully merged,
but ChangeLog failing with a conflict, and in magit it looks like this:
 Unstaged changes:
        C Modified ChangeLog
          Modified a.c
          Modified c.c
 Staged changes:
          Modified d.c

(since there was a conflict the merge wasn't completed commit, and there
are now many changes unrelated to the merge that could become part of
the merge commit)

> When there are uncommitted changes and some merge takes place at a
> place where these changes are, the changes can't avoid being part of
> that merge.

Actually, that's what git tries to encourage, either by having you
commit your changes before pulling or alternatively, stashing the
changes before you pull, and then unstashing them and creating a new
commit separate to the merge commit.

>> This chapter of "Pro Git", is quite good:
>> http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

> It may be quite good, but it's information density is very low.  It's
> written for beginners in VCS.

Um... it may not be the book for you, but it's not written for beginners
in VCS.  In fact it requires quite a bit in understanding of data
structures.

> Every time I read, yet again, that VCSs have the concept of a branch
> and what it's used for, my eyes glaze over, and I start subconsciously
> skimming the text in the hope of coming across something solid and
> useful.

To read it you need to read it like you read code examples and
think about and visualize what the datastructures look like.  It was
when I read this (after having used git for a year or so), that git
started making sense to me.

> The information density in the git-merge man page is low in a
> different way: being so vague and imprecise it makes little sense on
> its own, because you've got to keep searching externally for
> information needed to get meaning out of it.

FWIW you're in good company here.  I just use them to get the exact
command line arguments when I can't remember them.

Re: VC mode and git

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Or:
>  git commit
>  git pull --rebase
>  git push
> (forgive me, Eli, I said the "r" word...)

So, avoiding rebase, this works as well:
 git commit
 git pull
 git push

There will be an extra commit in the history (from the pull's merge),
but this will always be safe, nothing's lost, and any merge will be in a
separate commit.

Re: VC mode and git

[Sebastien Vauban]

Alan Mackenzie wrote:
> On Tue, Mar 31, 2015 at 06:24:46PM +0900, Stephen J. Turnbull wrote:
>> Alan Mackenzie writes:
>
>>> Why can't git simply merge changes properly into the workspace, thus
>>> saving users the unwelcome hassle of, e.g., git stash followed by
>>> git merge followed by git stash pop?
>
>> It does, the same way that bzr or Mercurial does.[1] I don't see why
>> you would think otherwise.
>
> Partly due to the following bug report which is near the start of the
> git-merge man page: "Warning: Running git merge with non-trivial
> uncommitted changes is discouraged: while possible, it may leave you
> in a state that is hard to back out of in the case of a conflict.".
> I can't imagine why the git maintainers don't fix this.
>
> With git pull, if there are changes in the working directory, the
> merge (i.e. merge from remote/master into master) part of the
> operation is aborted before it starts, giving a message describing its
> refusal.  It does this even when there are no conflicts to deal with.

What are we supposed to do in that case, if we're not yet ready to
commit our files?

Something like:

--8<---------------cut here---------------start------------->8---
git stash
git pull
git stash apply
--8<---------------cut here---------------end--------------->8---

or putting our work into a new branch, like:

--8<---------------cut here---------------start------------->8---
git checkout -b new-branch-name
git commit -a -m "Edited"
git checkout master
git pull
...
--8<---------------cut here---------------end--------------->8---

Are there other (more elegant, or more clever) ways to deal with that
situation (fetching something someone has fixed without committing we're
not yet ready to commit and push on master)?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: VC mode and git

[Eli Zaretskii]

> From: Sebastien Vauban <sva-news@mygooglest.com>
> Date: Tue, 31 Mar 2015 15:34:10 +0200
> 
> > With git pull, if there are changes in the working directory, the
> > merge (i.e. merge from remote/master into master) part of the
> > operation is aborted before it starts, giving a message describing its
> > refusal.  It does this even when there are no conflicts to deal with.
> 
> What are we supposed to do in that case, if we're not yet ready to
> commit our files?

Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
changes doesn't fail.  I do this every time before committing a
changeset I intend to push, and it always worked for me.

By contrast, if you do commit, and _then_ pull, your pull might fail
to merge the new stuff from upstream, and _then_ you'd need to do
something to fix that.  (I usually just "git reset HEAD^" and pull
again, then commit my changes again, after fixing the ChangeLog
entries to be in the correct order.)

Re: VC mode and git

[Dmitry Gutov]

On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
 > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
> changes doesn't fail.  I do this every time before committing a
> changeset I intend to push, and it always worked for me.

Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
changes can succeed if the newly pulled changes don't touch the locally 
changed files, but will fail otherwise. Which makes a lot of sense.

> By contrast, if you do commit, and _then_ pull, your pull might fail
> to merge the new stuff from upstream, and _then_ you'd need to do
> something to fix that.

If your local changes didn't touch the same files that were changed 
upstream, there shouldn't be any conflicts, aside from ChangeLog-related 
ones. Which should become no problem soon.

 > (I usually just "git reset HEAD^" and pull
> again, then commit my changes again, after fixing the ChangeLog
> entries to be in the correct order.)

I'd usually rebase (as long as there haven't been any local merges), but 
that's not something we can put in the common workflow, of course.

Re: VC mode and git

[Eli Zaretskii]

> Date: Tue, 31 Mar 2015 17:26:41 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
>  > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
> > changes doesn't fail.  I do this every time before committing a
> > changeset I intend to push, and it always worked for me.
> 
> Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
> changes can succeed if the newly pulled changes don't touch the locally 
> changed files, but will fail otherwise. Which makes a lot of sense.

Yes, and is expected.  Even CVS did that ;-)

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 31 Mar 2015 17:26:41 +0300
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>> 
>> On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
>>  > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
>> > changes doesn't fail.  I do this every time before committing a
>> > changeset I intend to push, and it always worked for me.
>> 
>> Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
>> changes can succeed if the newly pulled changes don't touch the locally 
>> changed files, but will fail otherwise. Which makes a lot of sense.
>
> Yes, and is expected.  Even CVS did that ;-)

No, CVS overwrites your changed files unconditionally.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Tue, 31 Mar 2015 16:39:24 +0200
> Cc: sva-news@mygooglest.com, emacs-devel@gnu.org,
> 	Dmitry Gutov <dgutov@yandex.ru>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Tue, 31 Mar 2015 17:26:41 +0300
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> CC: emacs-devel@gnu.org
> >> 
> >> On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
> >>  > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
> >> > changes doesn't fail.  I do this every time before committing a
> >> > changeset I intend to push, and it always worked for me.
> >> 
> >> Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
> >> changes can succeed if the newly pulled changes don't touch the locally 
> >> changed files, but will fail otherwise. Which makes a lot of sense.
> >
> > Yes, and is expected.  Even CVS did that ;-)
> 
> No, CVS overwrites your changed files unconditionally.

And makes a merge conflict, AFAIR.

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Date: Tue, 31 Mar 2015 16:39:24 +0200
>> Cc: sva-news@mygooglest.com, emacs-devel@gnu.org,
>> 	Dmitry Gutov <dgutov@yandex.ru>
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Tue, 31 Mar 2015 17:26:41 +0300
>> >> From: Dmitry Gutov <dgutov@yandex.ru>
>> >> CC: emacs-devel@gnu.org
>> >> 
>> >> On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
>> >>  > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
>> >> > changes doesn't fail.  I do this every time before committing a
>> >> > changeset I intend to push, and it always worked for me.
>> >> 
>> >> Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
>> >> changes can succeed if the newly pulled changes don't touch the locally 
>> >> changed files, but will fail otherwise. Which makes a lot of sense.
>> >
>> > Yes, and is expected.  Even CVS did that ;-)
>> 
>> No, CVS overwrites your changed files unconditionally.
>
> And makes a merge conflict, AFAIR.

Unconditionally.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: sva-news@mygooglest.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 31 Mar 2015 16:52:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Date: Tue, 31 Mar 2015 16:39:24 +0200
> >> Cc: sva-news@mygooglest.com, emacs-devel@gnu.org,
> >> 	Dmitry Gutov <dgutov@yandex.ru>
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> Date: Tue, 31 Mar 2015 17:26:41 +0300
> >> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> >> CC: emacs-devel@gnu.org
> >> >> 
> >> >> On 03/31/2015 05:07 PM, Eli Zaretskii wrote:
> >> >>  > Nothing, IME.  Contrary to the cited text, "git pull" with uncommitted
> >> >> > changes doesn't fail.  I do this every time before committing a
> >> >> > changeset I intend to push, and it always worked for me.
> >> >> 
> >> >> Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
> >> >> changes can succeed if the newly pulled changes don't touch the locally 
> >> >> changed files, but will fail otherwise. Which makes a lot of sense.
> >> >
> >> > Yes, and is expected.  Even CVS did that ;-)
> >> 
> >> No, CVS overwrites your changed files unconditionally.
> >
> > And makes a merge conflict, AFAIR.
> 
> Unconditionally.

Right.

Re: VC mode and git

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

  > > Neither is exactly true. Since 1.7.0 or so, "git pull" with uncommitted 
  > > changes can succeed if the newly pulled changes don't touch the locally 
  > > changed files, but will fail otherwise. Which makes a lot of sense.

  > Yes, and is expected.  Even CVS did that ;-)

With CVS, it would indicate the conflicts in those files,
and I only had to edit them to resolve the conflicts.
I do that by hand, since that way I know exactly what's going on
and I can do them in any order.

It seems that git handles this much worse.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Wed, 01 Apr 2015 06:22:19 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dgutov@yandex.ru, sva-news@mygooglest.com, emacs-devel@gnu.org
> 
> With CVS, it would indicate the conflicts in those files,
> and I only had to edit them to resolve the conflicts.
> I do that by hand, since that way I know exactly what's going on
> and I can do them in any order.

You can do (almost) the same with Git, see my other message.

> It seems that git handles this much worse.

If you follow the procedure I suggested, I think you will find that
Git handles this almost the same.  That's why I suggested it, and not
the alternatives.

Re: VC mode and git

[Stephen J. Turnbull]

Sebastien Vauban writes:
 > Alan Mackenzie wrote:

 > > With git pull, if there are changes in the working directory, the
 > > merge (i.e. merge from remote/master into master) part of the
 > > operation is aborted before it starts, giving a message describing its
 > > refusal.  It does this even when there are no conflicts to deal with.
 > 
 > What are we supposed to do in that case, if we're not yet ready to
 > commit our files?

If you have work-in-progress and feel unable to commit, but at the
same time feel the need to pull into that workspace, I suggest you get
up and walk around, fight off the pull urge, then finish the commit
after your head cools off.

If that isn't satisfactory, then

 > or putting our work into a new branch, like:
 > 
 > --8<---------------cut here---------------start------------->8---
 > git checkout -b new-branch-name
 > git commit -a -m "Edited"
 > git checkout master
 > git pull
 > ...
 > --8<---------------cut here---------------end--------------->8---

is one way to go.  Another possibility is creating a new workspace,
with cp -a or similar.

If you need the pulled code for your work, then a quick stash is the
better idea.

Re: VC mode and git

[Steinar Bang]

>>>>> Sebastien Vauban <sva-news@mygooglest.com>:

> Are there other (more elegant, or more clever) ways to deal with that
> situation (fetching something someone has fixed without committing
> we're not yet ready to commit and push on master)?

Well, one way would be not to work directly on master, but instead work
on a feature branch, and only merge in the feature branch when you're
ready to commit.

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > I lost some changes in my working directory after doing something
 > like git pull.  I can't remember the details any more.

"Something like."  "Can't remember."  That's the real problem, and git
(or whatever the VCS in use is, but for Emacs it's git) is the
solution.  "Commit early, commit often", and you won't have to worry
about remembering the details of your workflow.

 > I was able to reconstruct the changes without too much difficulty.

That's good.  But people aren't always that lucky.

 > > It does, the same way that bzr or Mercurial does.[1]  I don't see
 > > why you would think otherwise.
 > 
 > Partly due to the following bug report which is near the start of the
 > git-merge man page:  "Warning: Running git merge with non-trivial
 > uncommitted changes is discouraged: while possible, it may leave you in a
 > state that is hard to back out of in the case of a conflict.".  I can't
 > imagine why the git maintainers don't fix this.

Fix what?  One can do it if one wants to.  It's usually not dangerous
because merge will abort if there are any local uncommitted changes in
a file that would be changed by the merge.  It's actually rather
useful in certain limited use cases, for example when I have a
different ignore file from upstream.  In Mercurial, I have a patch in
a queue that handles this but it's PITA to deal with.  (Note that
everybody's favorite blunted plastic scissors, aka Bazaar, has a
"merge --force" option to allow the user to make the choice.)

It is indeed a bad idea to do a lot of work without committing and
then merging.  But that's a trivial deduction from the general
theorem: it is a bad idea to do a lot of work without committing.

 > With git pull, if there are changes in the working directory, the merge
 > (i.e. merge from remote/master into master) part of the operation is
 > aborted before it starts, giving a message describing its refusal.  It
 > does this even when there are no conflicts to deal with.

No, it only does it if a locally changed file is to be updated by the
merge.  That is a conflict, because git has no way to bring you back
to the current state if you want to come back.  Git only knows how to
bring you back to a state that was committed.

 > Mercurial will complete hg pull regardless of any changes in its working
 > directory; in the case of conflicts it may leave several heads which
 > require merging.

Which is exactly what git does:

    b 22:00$ git pull
    remote: Counting objects: 3, done.
    remote: Compressing objects: 100% (3/3), done.
    remote: Total 3 (delta 1), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From /tmp/test/./a
       684eca7..d47c24c  master     -> origin/master  <<<< LOOK LOOK LOOK
    Updating 684eca7..d47c24c
    error: Your local changes to the following files would be overwritten
    by merge:
       quuz
    Please, commit your changes or stash them before you can merge.
    Aborting

I think you're partly confused by the fact that what Mercurial calls
pull is what git calls fetch, and what git calls pull has no
equivalent in core Mercurial AFAIK (pull -u only updates on a fast
forward).

 > Part of the problem is that the git-merge man page doesn't say that
 > it messes with the working tree

What else would it do?  Merge tools have changed the working tree from
time immemorial.

What's different from traditional 3-way merge tools (that aren't part
of a VCS) is that git *also* creates a commit with more than one
parent (which is what is meant by joining development histories).  I
find it a PITA that Mercurial doesn't, but rather requires a separate
merge operation and then an explicit commit.

 > By contrast, hg merge is documented concisely and adequately as
 > "merge another revision into working directory".

Everybody hates git's documentation.  I thought you were complaining
about bugs in the program?

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

> "Commit early, commit often", and you won't have to worry about
> remembering the details of your workflow.

And have my repository clogged up with meaningless arbitrary commits with
commit messages like "Just before resync with savannah, 2015-03-31
22-58"?  Then I'd have the hassle of somehow ensuring these silly commits
wouldn't find their way back to savannah.  I know vaguely this is a
solved problem, but it's one more thankless bit of drudgery I don't want
to get involved with.

>  > > It does, the same way that bzr or Mercurial does.[1]  I don't see
>  > > why you would think otherwise.

>  > Partly due to the following bug report which is near the start of the
>  > git-merge man page:  "Warning: Running git merge with non-trivial
>  > uncommitted changes is discouraged: while possible, it may leave you in a
>  > state that is hard to back out of in the case of a conflict.".  I can't
>  > imagine why the git maintainers don't fix this.

> Fix what?  One can do it if one wants to.  It's usually not dangerous
> because merge will abort if there are any local uncommitted changes in
> a file that would be changed by the merge.  It's actually rather
> useful in certain limited use cases, for example when I have a
> different ignore file from upstream.  In Mercurial, I have a patch in
> a queue that handles this but it's PITA to deal with.  (Note that
> everybody's favorite blunted plastic scissors, aka Bazaar, has a
> "merge --force" option to allow the user to make the choice.)

> It is indeed a bad idea to do a lot of work without committing and
> then merging.

Why?

> But that's a trivial deduction from the general theorem: it is a bad
> idea to do a lot of work without committing.

Why?

These two "why?"s are not rhetorical questions.

[ .... ]

>  > Mercurial will complete hg pull regardless of any changes in its working
>  > directory; in the case of conflicts it may leave several heads which
>  > require merging.

> Which is exactly what git does:

>     b 22:00$ git pull
>     remote: Counting objects: 3, done.
>     remote: Compressing objects: 100% (3/3), done.
>     remote: Total 3 (delta 1), reused 0 (delta 0)
>     Unpacking objects: 100% (3/3), done.
>     From /tmp/test/./a
>        684eca7..d47c24c  master     -> origin/master  <<<< LOOK LOOK LOOK
>     Updating 684eca7..d47c24c
>     error: Your local changes to the following files would be overwritten
>     by merge:
>        quuz
>     Please, commit your changes or stash them before you can merge.
>     Aborting

> I think you're partly confused by the fact that what Mercurial calls
> pull is what git calls fetch, and what git calls pull has no
> equivalent in core Mercurial AFAIK (pull -u only updates on a fast
> forward).

No, I'm not confused on this point.  There is hg fetch (deprecated) which
does hg pull followed (possibly) by hg merge, then hg update, more or
less.  I've never used it.

>  > Part of the problem is that the git-merge man page doesn't say that
>  > it messes with the working tree

> What else would it do?  Merge tools have changed the working tree from
> time immemorial.

That's poor, Stephen.  It might well merge in the repository without
touching the working tree.  The fact is, the documentation doesn't say
this - it doesn't even say where the two sources for its merge come from,
or where it puts the result.

> What's different from traditional 3-way merge tools (that aren't part
> of a VCS) is that git *also* creates a commit with more than one
> parent (which is what is meant by joining development histories).

Do development histories have 40-byte hashes?  :-)

> I find it a PITA that Mercurial doesn't, but rather requires a separate
> merge operation and then an explicit commit.

>  > By contrast, hg merge is documented concisely and adequately as
>  > "merge another revision into working directory".

> Everybody hates git's documentation.  I thought you were complaining
> about bugs in the program?

The documentation is part of the program.  Whether bugs are in the doc or
the prog, it costs just as much wasted time and energy.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > And have my repository clogged up with meaningless arbitrary commits with
 > commit messages like "Just before resync with savannah, 2015-03-31
 > 22-58"?

I see nothing arbitrary about:

2015-03-31  Alan Mackenzie  <acm@muc.de>

	Development of foobar complete, all tests pass, documentation done.

	* foobar.el:  New file.

2015-04-01  Alan Mackenzie  <acm@muc.de>

	Integration of foobar to trunk complete, all tests pass.

        * foobar.el (foo, bar, baz):
	Refactor: use pcase, now that it has decent docs.

IMHO, these are specific, well-defined milestones that merit commits.
YMMV, but IME these last-minute adjustments to others' changes involve
far more than their share of defects, so having a next-to-last commit
in the known, comfortable pre-pull context and then one last commit
for integration is likely to do far more than its share of bug
localization when bisecting.

 > Then I'd have the hassle of somehow ensuring these silly commits
 > wouldn't find their way back to savannah.

There are plenty of options for this.

 > > It is indeed a bad idea to do a lot of work without committing and
 > > then merging.
 > 
 > Why?

See the general theorem.

 > > But that's a trivial deduction from the general theorem: it is a bad
 > > idea to do a lot of work without committing.
 > 
 > Why?

Because the only advantage to *not* committing is avoiding the two
minutes it takes to ask how to accomplish the task of "somehow
ensuring these silly commits wouldn't find their way back to
savannah", and learning how to type "git pull --rebase".  That would
mean you have at least two copies of all current work (one in the
working tree and one in .git/objects), and can easily back up to
another host with "git push".

Of course, you and Richard want git (and in his case vc.el) to default
to supporting your workflows, but that's not going to happen, at least
for git.  git is a very flexible tool for supporting a variety of
workflows, and not only are the workflows that involve "commit early
and often" already popular, they're gaining.

That's because a commit is just a way of delegating a pile of
record-keeping to the VCS.  In particular, it identifies a state of
development that you or others might want to replicate.  In CVS and
other centralized VCSes, a check-in (to the public repository, using
Richard's felicitous terminology) is the only way to commit, which
makes it a very heavyweight operation indeed.  Even if you have a very
good connection to the server, it's still socially heavy because the
whole project shares it thereafter.

In DVCS, check-in is not the only way to commit: just committing and
waiting to push at an appropriate time is available.  This means that
the social weight of a check-in is no longer an issue.  You can commit
on any whim, and git's whole design is to make whimsical commits as
cheap as possible.  Part of that is the much derided staging area as
well as other aspects of caching the blobs and trees, but part of that
is "git reset --soft" and the DAG editing capabilities it provides.
You can throw away commits while keeping the changes using interactive
rebasing, or do the commits on a branch and merge, or any combination
that makes sense to you.

When I have achieved a state that deserves publication, I want to save
it in a reliable way that doesn't involve me remembering not to touch
that workspace, etc.  Maybe you don't want to do that, but I assure
you the cost of learning to use an appropriate workflow is far lower
than the cost of reproducing even a score of lines that disappeared
due to a silly typo or a tool whose documentation was unclear.

 > These two "why?"s are not rhetorical questions.

Yes, they are.  You (and Richard) don't want to know the answers
because acknowledging them would very likely induce changes in your
workflows, and everybody else already does know the answers.

 > No, I'm not confused on [the different usage of merge, fetch, and
 > pull in git and hg].

Well, the language you use makes it very difficult to determine
whether you are or aren't.  For example, when you write "merge", it's
hard to tell whether you are referring to a particular VCS's designed
semantics, to the goal you want to achieve in the workspace, or to the
particular command provided by a given VCS.  I suspect, but can't say
for sure for lack of verbal cues, that you actually switch back and
forth from one sentence to the next.

 > > What else would it do?  Merge tools have changed the working tree
 > > from time immemorial.
 > 
 > That's poor, Stephen.  [...]  The fact is, the documentation
 > doesn't say this

I'm sorry, but that point is moot.  Emacs chose git despite the
well-known deficiencies of its documentation, primarily because there
are a lot of Emacs workers who like git and know it fairly well.  One
now needs to use git to work on Emacs efficiently.  So suck it up and
use the wetware that has accumulated around you.

 > > What's different from traditional 3-way merge tools (that aren't
 > > part of a VCS) is that git *also* creates a commit with more than
 > > one parent (which is what is meant by joining development
 > > histories).
 > 
 > Do development histories have 40-byte hashes?  :-)

Of course they do.  Each commit implies a whole development history
through the parents attribute, just as each cons implies a whole list
through the cdr attribute.

 > The documentation is part of the program.  Whether bugs are in the
 > doc or the prog, it costs just as much wasted time and energy.

Only because you're unwilling to ask for help.  Asking for help from
Emacs developers is a very cheap and effective substitute for good
docs, and surely you have sufficient standing in the community to
warrant attention to your questions.  Of course you probably want to
choose the advice of someone like Eli rather than somebody like
Andreas, but both would undoubtedly answer your questions.

Regards,

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Wed, Apr 01, 2015 at 10:25:31AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > And have my repository clogged up with meaningless arbitrary commits with
>  > commit messages like "Just before resync with savannah, 2015-03-31
>  > 22-58"?

> I see nothing arbitrary about:

> 2015-03-31  Alan Mackenzie  <acm@muc.de>

> 	Development of foobar complete, all tests pass, documentation done.

> 	* foobar.el:  New file.

> 2015-04-01  Alan Mackenzie  <acm@muc.de>

> 	Integration of foobar to trunk complete, all tests pass.

>         * foobar.el (foo, bar, baz):
> 	Refactor: use pcase, now that it has decent docs.

> IMHO, these are specific, well-defined milestones that merit commits.

Stephen, that is complete sophistry.  I do not constrain my git pulls
exclusively to the times when I'm ready to make a sensible commit.

> YMMV, but IME these last-minute adjustments to others' changes involve
> far more than their share of defects, so having a next-to-last commit
> in the known, comfortable pre-pull context and then one last commit
> for integration is likely to do far more than its share of bug
> localization when bisecting.

>  > Then I'd have the hassle of somehow ensuring these silly commits
>  > wouldn't find their way back to savannah.

> There are plenty of options for this.

Of course there are.  I want to avoid the hassle of them; the hassle of
having to write down coherently one or more of these options; the hassle
of having to remember each time to do one of them; the hassle of having
to look up my notes each time.

>  > > But that's a trivial deduction from the general theorem: it is a bad
>  > > idea to do a lot of work without committing.

>  > Why?

> Because the only advantage to *not* committing is avoiding the two
> minutes it takes to ask how to accomplish the task of "somehow
> ensuring these silly commits wouldn't find their way back to
> savannah", and learning how to type "git pull --rebase".  That would
> mean you have at least two copies of all current work (one in the
> working tree and one in .git/objects), and can easily back up to
> another host with "git push".

That's a disappointing answer, largely negative.  I was hoping for some
new insight into the advantages of frequent committing.

> Of course, you and Richard want git (and in his case vc.el) to default
> to supporting your workflows, but that's not going to happen, at least
> for git.  git is a very flexible tool for supporting a variety of
> workflows, and not only are the workflows that involve "commit early
> and often" already popular, they're gaining.

Git should support how ever often a developper wants to commit, whether
every 5 minutes or just once per fix.

> That's because a commit is just a way of delegating a pile of
> record-keeping to the VCS.  In particular, it identifies a state of
> development that you or others might want to replicate.

A commit is a commitment.  It is an affirmation, possibly public, of the
value of the new code, to its integrity, it is a declared willingness to
stand up and defend the thing committed to.  I do not commit my dirty
linen, which is what people seem to be advocating I should do.

> In CVS and other centralized VCSes, a check-in (to the public
> repository, using Richard's felicitous terminology) is the only way to
> commit, which makes it a very heavyweight operation indeed.  Even if
> you have a very good connection to the server, it's still socially
> heavy because the whole project shares it thereafter.

> In DVCS, check-in is not the only way to commit: just committing and
> waiting to push at an appropriate time is available.  This means that
> the social weight of a check-in is no longer an issue.

CVS's commit is equivalent to git's push, not its commit.  The social
weight of git push is the same as cvs commit.

> You can commit on any whim, and git's whole design is to make whimsical
> commits as cheap as possible.  Part of that is the much derided staging
> area as well as other aspects of caching the blobs and trees, but part
> of that is "git reset --soft" and the DAG editing capabilities it
> provides.  You can throw away commits while keeping the changes using
> interactive rebasing, or do the commits on a branch and merge, or any
> combination that makes sense to you.

The only combination that makes sense to me is that which involves the
least risk and the least time and effort wasted in ploughing through
git's inadequate documentation.  I don't want to spend several hours
learning how to "throw away commits while keeping the changes using
interactive rebasing", or even in learning what that all really means.  I
am one of these seemingly rare people who are not fascinated by the
innards of git, and simply want an appropriate tool for communicating
changes from and to savannah.  I know I'm not the only one.  I think you
have trouble accepting this position.

> When I have achieved a state that deserves publication, I want to save
> it in a reliable way that doesn't involve me remembering not to touch
> that workspace, etc.  Maybe you don't want to do that, but I assure
> you the cost of learning to use an appropriate workflow is far lower
> than the cost of reproducing even a score of lines that disappeared
> due to a silly typo or a tool whose documentation was unclear.

Personally, I don't have any trouble with not touching finished changes.

>  > These two "why?"s are not rhetorical questions.

> Yes, they are.  You (and Richard) don't want to know the answers
> because acknowledging them would very likely induce changes in your
> workflows, and everybody else already does know the answers.

The answer you gave above essentially just asserted it was a good thing
to have a copies (in the repository) of what one is working on.  This is
perilously close to begging the question.

It seems the real answer is "everybody" commits often, so it must be good
thing to do.  I've never found that sort of reasoning persuasive.

>  > No, I'm not confused on [the different usage of merge, fetch, and
>  > pull in git and hg].

> Well, the language you use makes it very difficult to determine
> whether you are or aren't.  For example, when you write "merge", it's
> hard to tell whether you are referring to a particular VCS's designed
> semantics, to the goal you want to achieve in the workspace, or to the
> particular command provided by a given VCS.  I suspect, but can't say
> for sure for lack of verbal cues, that you actually switch back and
> forth from one sentence to the next.

Sorry, I'll try to be more definite in the future.

>  > > What else would it do?  Merge tools have changed the working tree
>  > > from time immemorial.

>  > That's poor, Stephen.  [...]  The fact is, the documentation
>  > doesn't say this

> I'm sorry, but that point is moot.  Emacs chose git despite the
> well-known deficiencies of its documentation, primarily because there
> are a lot of Emacs workers who like git and know it fairly well.  One
> now needs to use git to work on Emacs efficiently.  So suck it up and
> use the wetware that has accumulated around you.

Yes.

>  > > What's different from traditional 3-way merge tools (that aren't
>  > > part of a VCS) is that git *also* creates a commit with more than
>  > > one parent (which is what is meant by joining development
>  > > histories).

>  > Do development histories have 40-byte hashes?  :-)

> Of course they do.  Each commit implies a whole development history
> through the parents attribute, just as each cons implies a whole list
> through the cdr attribute.

>  > The documentation is part of the program.  Whether bugs are in the
>  > doc or the prog, it costs just as much wasted time and energy.

> Only because you're unwilling to ask for help.  Asking for help from
> Emacs developers is a very cheap and effective substitute for good
> docs, and surely you have sufficient standing in the community to
> warrant attention to your questions.  Of course you probably want to
> choose the advice of someone like Eli rather than somebody like
> Andreas, but both would undoubtedly answer your questions.

I have asked for git help in the past, and got answers varying in quality
from the deliberately infuriating to just right.  But doing this takes up
other people's time, so I don't like doing it too often.  Perhaps I'm
just too used to finding the answers to simple questions in
documentation.

> Regards,

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Michael Albinus]

Alan Mackenzie <acm@muc.de> writes:

> The only combination that makes sense to me is that which involves the
> least risk and the least time and effort wasted in ploughing through
> git's inadequate documentation.  I don't want to spend several hours
> learning how to "throw away commits while keeping the changes using
> interactive rebasing", or even in learning what that all really means.  I
> am one of these seemingly rare people who are not fascinated by the
> innards of git, and simply want an appropriate tool for communicating
> changes from and to savannah.  I know I'm not the only one.

+1. Finally, that's what vc.el should be good for at least.

Best regards, Michael.

Re: VC mode and git

[Ricardo Wurmus]

Alan Mackenzie writes:

>> That's because a commit is just a way of delegating a pile of
>> record-keeping to the VCS.  In particular, it identifies a state of
>> development that you or others might want to replicate.
>
> A commit is a commitment.  It is an affirmation, possibly public, of the
> value of the new code, to its integrity, it is a declared willingness to
> stand up and defend the thing committed to.  I do not commit my dirty
> linen, which is what people seem to be advocating I should do.

[...]

>> You can commit on any whim, and git's whole design is to make whimsical
>> commits as cheap as possible.  Part of that is the much derided staging
>> area as well as other aspects of caching the blobs and trees, but part
>> of that is "git reset --soft" and the DAG editing capabilities it
>> provides.  You can throw away commits while keeping the changes using
>> interactive rebasing, or do the commits on a branch and merge, or any
>> combination that makes sense to you.
>
> The only combination that makes sense to me is that which involves the
> least risk and the least time and effort wasted in ploughing through
> git's inadequate documentation.  I don't want to spend several hours
> learning how to "throw away commits while keeping the changes using
> interactive rebasing", or even in learning what that all really means.  I
> am one of these seemingly rare people who are not fascinated by the
> innards of git, and simply want an appropriate tool for communicating
> changes from and to savannah.  I know I'm not the only one.  I think you
> have trouble accepting this position.

I'm not "fascinated by the innards of git" and I don't find the man
pages very useful, but creating commits often and interactively rebasing
them before publishing (i.e. "git push") lies at the core of my
workflow, and I would not do it if it wasn't easy and convenient.

Your concept of a commit as "an affirmation [...] of the value of the
new code" does not need to apply to local, "whimsical", cheap commits.
Before publishing you can *easily* squash, delete, edit, rename, move
commits with interactive rebase.  You can defer the decision when
something is ready for publication without having to forgo commits (I
think of them as "quicksave" in games).

Committing often and rebasing for publication are both cheap operations
with little mental overhead.  It would be insanity for me to keep a
dirty working directory with potentially valuable changes uncommitted.

~~ Ricardo

Re: VC mode and git

[Alan Mackenzie]

Hello, Ricardo.

On Wed, Apr 01, 2015 at 09:50:46PM +0200, Ricardo Wurmus wrote:

> Alan Mackenzie writes:

> > The only combination that makes sense to me is that which involves the
> > least risk and the least time and effort wasted in ploughing through
> > git's inadequate documentation.  I don't want to spend several hours
> > learning how to "throw away commits while keeping the changes using
> > interactive rebasing", or even in learning what that all really means.  I
> > am one of these seemingly rare people who are not fascinated by the
> > innards of git, and simply want an appropriate tool for communicating
> > changes from and to savannah.  I know I'm not the only one.  I think you
> > have trouble accepting this position.

> I'm not "fascinated by the innards of git" and I don't find the man
> pages very useful, but creating commits often and interactively rebasing
> them before publishing (i.e. "git push") lies at the core of my
> workflow, and I would not do it if it wasn't easy and convenient.

Is having to invent a meaningful commit message for each and every commit
not inconvenient?

> Your concept of a commit as "an affirmation [...] of the value of the
> new code" does not need to apply to local, "whimsical", cheap commits.
> Before publishing you can *easily* squash, delete, edit, rename, move
> commits with interactive rebase.  You can defer the decision when
> something is ready for publication without having to forgo commits (I
> think of them as "quicksave" in games).

> Committing often and rebasing for publication are both cheap operations
> with little mental overhead.  It would be insanity for me to keep a
> dirty working directory with potentially valuable changes uncommitted.

Why "insane"?  Do you have your repository in a "more secure" place?  For
me, my repository is on the same RAID pair of disks as my working
directory.  So committing things in my working directory doesn't make
them any more secure.  I don't do it because it would be extra work,
however little.  As you intimate above, these extra commits would need to
be dealt with by squashing, deleting, editing, renaming, interactive
rebasing, or whatever.

I honestly don't understand why people advocate frequent committing.

> ~~ Ricardo

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Daniel Colascione]

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

On 04/01/2015 03:34 PM, Alan Mackenzie wrote:
> Hello, Ricardo.
> 
> On Wed, Apr 01, 2015 at 09:50:46PM +0200, Ricardo Wurmus wrote:
> 
>> Alan Mackenzie writes:
> 
>>> The only combination that makes sense to me is that which involves the
>>> least risk and the least time and effort wasted in ploughing through
>>> git's inadequate documentation.  I don't want to spend several hours
>>> learning how to "throw away commits while keeping the changes using
>>> interactive rebasing", or even in learning what that all really means.  I
>>> am one of these seemingly rare people who are not fascinated by the
>>> innards of git, and simply want an appropriate tool for communicating
>>> changes from and to savannah.  I know I'm not the only one.  I think you
>>> have trouble accepting this position.
> 
>> I'm not "fascinated by the innards of git" and I don't find the man
>> pages very useful, but creating commits often and interactively rebasing
>> them before publishing (i.e. "git push") lies at the core of my
>> workflow, and I would not do it if it wasn't easy and convenient.
> 
> Is having to invent a meaningful commit message for each and every commit
> not inconvenient?

Half of mine are "asdf". Of course I provide meaningful messages for
commits I push, but local ones? Nah.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 1 Apr 2015 22:34:32 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, emacs-devel@gnu.org
> 
> Is having to invent a meaningful commit message for each and every commit
> not inconvenient?

Not if your commits follow some logical steps of the development.
Then a short log message like "Introduced feature A" or "Fixed B that
was caused by C" are actually quite natural, and tell the story of
your development steps.

> I honestly don't understand why people advocate frequent committing.

Frequent commits allow you to record the development phases, and allow
later to easily find when some code was introduced and why.

Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Stephen, that is complete sophistry.

Will you stop the name calling?

 > Git should support how ever often a developper wants to commit,
 > whether every 5 minutes or just once per fix.

It does.  It just doesn't support your workflow by default, so you
have to learn more than a few bare commands that DWIM.

 > A commit is a commitment.

No, it is nothing of the kind.  A check-in (push) is a commitment.
You can *choose* to only make commits to the VCS that you are willing
to commit to in some normative sense.  But that doesn't make a commit
a commitment in principle, only by the accident of your preferences.

 > It is an affirmation, possibly public, of the value of the new
 > code, to its integrity, it is a declared willingness to stand up
 > and defend the thing committed to.  I do not commit my dirty linen,
 > which is what people seem to be advocating I should do.

Do you save your "dirty linen"?  If you don't, I bet your Emacs does.

 > [I] simply want an appropriate tool for communicating changes from
 > and to savannah.  I know I'm not the only one.  I think you have
 > trouble accepting this position.

I have no trouble accepting that position.  I'm simply unwilling to
exert any effort on your behalf, because I like git the way it is.
OTOH, my acceptance does you no good, because Emacs uses git.  That
is:

 > It seems the real answer is "everybody" commits often, so it must
 > be good thing to do.  I've never found that sort of reasoning
 > persuasive.

No, the real answer is that "everybody" commits often, so there is no
willingness to change git to serve the "nobody" who doesn't.  You can
throw all the tantrums you want, but unless you rewrite git and/or vc
yourself, it won't get done.  Of course you'd have to learn a hell of
a lot about git to be able to do so.

 > I have asked for git help in the past, and got answers varying in
 > quality from the deliberately infuriating to just right.  But doing
 > this takes up other people's time, so I don't like doing it too
 > often.  Perhaps I'm just too used to finding the answers to simple
 > questions in documentation.

The questions you are asking are *not* simple, because your
requirements are misaligned with those of the git developers.

Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Thu, Apr 02, 2015 at 06:11:59AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > Stephen, that is complete sophistry.

> Will you stop the name calling?

OK.  Will you stop using rhetorical tricks to throw my arguments and
questions off track?

>  > Git should support how ever often a developper wants to commit,
>  > whether every 5 minutes or just once per fix.

> It does.  It just doesn't support your workflow by default, so you
> have to learn more than a few bare commands that DWIM.

[ .... ]

> Do you save your "dirty linen"?  If you don't, I bet your Emacs does.

Yes and yes.

>  > [I] simply want an appropriate tool for communicating changes from
>  > and to savannah.  I know I'm not the only one.  I think you have
>  > trouble accepting this position.

> I have no trouble accepting that position.  I'm simply unwilling to
> exert any effort on your behalf, because I like git the way it is.
> OTOH, my acceptance does you no good, because Emacs uses git.  That
> is:

>  > It seems the real answer is "everybody" commits often, so it must
>  > be good thing to do.  I've never found that sort of reasoning
>  > persuasive.

> No, the real answer is that "everybody" commits often, so there is no
> willingness to change git to serve the "nobody" who doesn't.

You've done it again.  The question was "why do people advocate frequent
committing?".  You've snipped the question from the record and then
supplied a non-answer to it.  Please stop doing things like this.

The topic of changing git was never up for discussion, and it's
irritating to have to deal with the insinuation I had mooted this.

As for why people commit often, it seems they do it because they do it,
and "everybody else" does.  I was hoping we could move beyond that.  It
seems we can't.

> You can throw all the tantrums you want, but unless you rewrite git
> and/or vc yourself, it won't get done.  Of course you'd have to learn a
> hell of a lot about git to be able to do so.

Who's name calling now?  ;-)

>  > I have asked for git help in the past, and got answers varying in
>  > quality from the deliberately infuriating to just right.  But doing
>  > this takes up other people's time, so I don't like doing it too
>  > often.  Perhaps I'm just too used to finding the answers to simple
>  > questions in documentation.

> The questions you are asking are *not* simple, because your
> requirements are misaligned with those of the git developers.

Wanting to know what git merge uses for its sources, and where it writes
its results would seem a simple and obvious enough thing to want to know.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[chad]

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


> On 01 Apr 2015, at 15:05, Alan Mackenzie <acm@muc.de> wrote:
> 
>>> It seems the real answer is "everybody" commits often, so it must
>>> be good thing to do.  I've never found that sort of reasoning
>>> persuasive.

Frequent commits allow people the freedom to move up, down, and
around the various versions of a dynamic codebase thats also being
worked on by many other people. The various tools for navigating
the DAG help quite a lot, but such things are generally too obscure
for new git users to grok, so they sit waiting for a future when
Im ready that sometimes never arrives. The practice also meshes
nicely with (both responding to and encouraging) a style of programming
that emphasizes and rewards frequent experiments and (especially
popular lately) test-driven exploration in actual code.

If you arent already used to working this way, then there is a hill
to climb before it becomes comfortable. This naturally implies a
tradeoff - some people will hate climbing the hill more, while
others will be excited to try something new with the hope of improving
their workflow, programming ability, etc. (As an aside: This last
group is, I claim, very important to Emacs, because its a major
source of new Emacs users - they grow up on simple editors and IDEs,
and then hear that theres rich rewards to be gained if only they
can manage to climb the cliffs of Emacs mastery.)

I dont want to put words into anyones mouth, but I think that there
are people on this list who are trying to help others *understand*
git that want to convey something like this idea:

	There are solid advantages to this part of git’s typical
	usage pattern that are considered features not bugs, and
	will not be changed (by git) because of these advantages.

Whether those features are advantageous to any one person is a
tradeoff. The discussion continues (IMHO) because *some* of the
people who have made a *personal* choice are making claims about
*general* choices, and those claims directly contradict the choices
of many reasonable, knowledgable people.  It certainly doesnt help
that so many of these claims are *statements* that take the form “I 
don’t see why anyone would ever want FOO.”

I hope that helps,
~Chad

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

Re: VC mode and git

[Thien-Thi Nguyen]

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

() "Stephen J. Turnbull" <stephen@xemacs.org>
() Thu, 02 Apr 2015 06:11:59 +0900

    > A commit is a commitment.

   No, it is nothing of the kind.

Better to say "git commit" is a commitment to yourself, only,
and thus as light or heavy as you yourself [mt]ake it.

When the commitment is light, that is an invitation (for the
conscientious) to reflect and clean up, later.  Lazy weight.
Extreme lightness is a sketch, playful and exploratory, perhaps
to be enhanced, perhaps to be discarded.  This is attractive to
people in the same way that *scratch* is attractive to hackers.

The danger of [mt]aking light of commitment is that of being
unconscientious, failing to reflect and clean up.  Then, when
heaviness arrives (in the form of "git push"), what is shared is
not settled and foundational, but ajumble and ankle-breaking.

So, in the end, the difference between heavy and light amounts
only to timing (for the conscientious, which i hope we all are
or strive to be).

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: VC mode and git

[Stephen J. Turnbull]

Thien-Thi Nguyen writes:
 > () "Stephen J. Turnbull" <stephen@xemacs.org>
 > () Thu, 02 Apr 2015 06:11:59 +0900
 > 
 >     > A commit is a commitment.
 > 
 >    No, it is nothing of the kind.
 > 
 > Better to say "git commit" is a commitment to yourself, only,

I'm sorry, but realistically "git reset" means that it isn't even
that.  Or you can "uncommit yourself" wholesale with "git branch -d".  
You don't have to use those commands, but that is your *choice*:

 > and thus as light or heavy as you yourself [mt]ake it.

Uh, that's what I did say, and you cut.

 > So, in the end, the difference between heavy and light amounts only
 > to timing (for the conscientious, which i hope we all are or strive
 > to be).

No, that's not the only difference.  IMO, if you are conscientious you
will commit early and often, because that provides a richer history
and more bisection points for future maintainers.  I don't disagree
with Eli that the commits should be meaningful to human beings[1], but as
long as tests as of that commit pass with each commit, every commit is
"meaningful" to bisection!

Footnotes: 
[1]  So there really is an absolute lower limit to the granularity of
commits that should be pushed.  But I suspect it's lower than
Richard's preference, and a lot lower than Alan's.  N.B. I'm not
arguing with their preferences here, just comparing them to the
smallest granularity that might be useful to a long-term project.

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 1 Apr 2015 12:32:41 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Andreas Schwab <schwab@suse.de>, Harald Hanche-Olsen <hanche@math.ntnu.no>,
> 	rms@gnu.org, emacs-devel@gnu.org
> 
> I do not constrain my git pulls exclusively to the times when I'm
> ready to make a sensible commit.

May I ask why do you pull (a.k.a. "merge from master") at all while
working on a feature?

Also, are we talking about you working on a feature branch, or about
working directly on master?

Generally, work that takes more than, say, an hour or two, and is
expected to involve a non-trivial amount of changes, is better done on
a separate branch, which you then merge onto master when you are done.
While working on such a branch, it makes little sense to merge from
master, because that just brings unrelated changes that could
potentially disrupt your development.  Instead, wait until you are
finished with your changes, and then merge.  If you do that, then the
potential conflicts due to pull/merge from master simply cannot
happen.

IOW, while working on a feature branch, you commit when you have
finished some well-defined part of the job, preferably something that
can be, and have been, unit-tested.  You then commit something that
you know has been tested and was proved to work.  Commit log messages
in this arrangement describe your advance.  Here's an example: the
first 10 commits from one of my past feature branches (produced by
"git log --oneline"):

  a12d75c Added initial version of biditest.el and Unicode data file it needs.
  2f3daa5 Optimize memory footprint of the bidi level stack.
  a7fed5a Added BidiBrackets.txt and related Unicode properties to unidqata-gen.el.
  2fca7ae Fixed problems revealed by -Wall.
  23dbf47 Updated bidi_resolve_weak.  Removed next_en_* members from stack.
  991b257 Updated pushing and popping the bidi stack, and sos calculations. Added the necessary members to bidi_stack.
  5d84f5d Fix find_first_strong_char and implement Unicode 8.0 isolate corrections.
  d9abb28 Finished coding of explicit directional format characters.
  8ccc6fa Remove bidi_ignore_explicit_marks_for_paragraph_level.
  4f6bc3c Started working on implementing UBA v6.3.

If, OTOH, you are working directly on master, it makes no sense IMO to
make intermediate commits, except in some rare situations (like you
are off-line for some reason), because if you feel the need to do
that, it's a clear sign that you should have done this on a branch.
So assuming you DTRT and only do short one-off jobs in master, you can
either commit right before you pull from upstream, or do the opposite:
pull, then commit.  (Both alternatives can run into conflicts, but
that's inevitable.)  Then you push, and that's it.

> >  > Then I'd have the hassle of somehow ensuring these silly commits
> >  > wouldn't find their way back to savannah.
> 
> > There are plenty of options for this.
> 
> Of course there are.  I want to avoid the hassle of them; the hassle of
> having to write down coherently one or more of these options; the hassle
> of having to remember each time to do one of them; the hassle of having
> to look up my notes each time.

I see no reasons for making "silly commits".  IMO, a commit should
have a good reason, and "I need to pull" is not one of them.

> >  > > But that's a trivial deduction from the general theorem: it is a bad
> >  > > idea to do a lot of work without committing.
> 
> >  > Why?
> 
> > Because the only advantage to *not* committing is avoiding the two
> > minutes it takes to ask how to accomplish the task of "somehow
> > ensuring these silly commits wouldn't find their way back to
> > savannah", and learning how to type "git pull --rebase".  That would
> > mean you have at least two copies of all current work (one in the
> > working tree and one in .git/objects), and can easily back up to
> > another host with "git push".
> 
> That's a disappointing answer, largely negative.  I was hoping for some
> new insight into the advantages of frequent committing.

I gave some above and in my other messages.

Basically, I disagree with what Stephen says above: a commit should
generally be a more-or-less complete unit of work, preferably
something that can be tested.  At least as a rule.

That said, as Stephen points out, the tools allow you to commit at any
time for a very small price: you need to come up with one line
describing the changes in the commit.  So if for some reason you need
to make a break in your work, and would like to record what you've
accomplished, feel free to commit.  (Once again, this is much better
done on a feature branch than on master.)  I don't feel ashamed to
have all my intermediate commits with their logs on the project's DAG
after the merge; if anything, this forces me to think for a few
seconds before I write the log messages.  (People who prefer rebasing
will probably disagree.)

> > Of course, you and Richard want git (and in his case vc.el) to default
> > to supporting your workflows, but that's not going to happen, at least
> > for git.  git is a very flexible tool for supporting a variety of
> > workflows, and not only are the workflows that involve "commit early
> > and often" already popular, they're gaining.
> 
> Git should support how ever often a developper wants to commit, whether
> every 5 minutes or just once per fix.

It does.

> > That's because a commit is just a way of delegating a pile of
> > record-keeping to the VCS.  In particular, it identifies a state of
> > development that you or others might want to replicate.
> 
> A commit is a commitment.  It is an affirmation, possibly public, of the
> value of the new code, to its integrity, it is a declared willingness to
> stand up and defend the thing committed to.  I do not commit my dirty
> linen, which is what people seem to be advocating I should do.

That's fine; I do that, too.  But still work on a non-trivial feature
or fix involves numerous steps and phases, which are usually coded and
unit-tested separately.  Committing after every such step is IMO good
practice, and supports your methodology, I think.

I don't quite understand the "dirty linen" part.  When you have
developed and tested a part of a feature, it might leave Emacs with
known bugs elsewhere, since your work is incomplete.  But if part of
that work is complete and tested, where's the "dirty linen" here? what
is there to be ashamed of?

> > In CVS and other centralized VCSes, a check-in (to the public
> > repository, using Richard's felicitous terminology) is the only way to
> > commit, which makes it a very heavyweight operation indeed.  Even if
> > you have a very good connection to the server, it's still socially
> > heavy because the whole project shares it thereafter.
> 
> > In DVCS, check-in is not the only way to commit: just committing and
> > waiting to push at an appropriate time is available.  This means that
> > the social weight of a check-in is no longer an issue.
> 
> CVS's commit is equivalent to git's push, not its commit.  The social
> weight of git push is the same as cvs commit.

Right, but we are not talking about pushing, do we?  We are talking
about _local_ commits that are not pushed to a public repository,
until after you are done with the feature and have merged it to
master.

> > You can commit on any whim, and git's whole design is to make whimsical
> > commits as cheap as possible.  Part of that is the much derided staging
> > area as well as other aspects of caching the blobs and trees, but part
> > of that is "git reset --soft" and the DAG editing capabilities it
> > provides.  You can throw away commits while keeping the changes using
> > interactive rebasing, or do the commits on a branch and merge, or any
> > combination that makes sense to you.
> 
> The only combination that makes sense to me is that which involves the
> least risk and the least time and effort wasted in ploughing through
> git's inadequate documentation.  I don't want to spend several hours
> learning how to "throw away commits while keeping the changes using
> interactive rebasing", or even in learning what that all really means.  I
> am one of these seemingly rare people who are not fascinated by the
> innards of git, and simply want an appropriate tool for communicating
> changes from and to savannah.  I know I'm not the only one.  I think you
> have trouble accepting this position.

That's okay; people are generally divided into two camps: those who
want to clean up their local commit mess before they make it public,
and those who don't make a mess to begin with, at least not a mess
they will feel ashamed about.  You seem to belong to the second group
(so do I); there's nothing wrong about that.  It just means you won't
use the tools mentioned by Stephen too much.  (You will still need
some of them to fix stupid errors done on master, like forgetting to
commit a file, or committing a change you didn't want to, if you catch
them before pushing.)  But it still makes sense to make local commits
on a feature branch once some unit of your work is completed.

> It seems the real answer is "everybody" commits often, so it must be good
> thing to do.  I've never found that sort of reasoning persuasive.

No, that's not the real answer.  It could be the popular answer, but
there are good reasons to do that; I've mentioned some.

Re: VC mode and git

[Daniel Colascione]

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

On 04/02/2015 07:52 AM, Eli Zaretskii wrote:
>> Date: Wed, 1 Apr 2015 12:32:41 +0000
>> From: Alan Mackenzie <acm@muc.de>
>> Cc: Andreas Schwab <schwab@suse.de>, Harald Hanche-Olsen <hanche@math.ntnu.no>,
>> 	rms@gnu.org, emacs-devel@gnu.org
>>
>> I do not constrain my git pulls exclusively to the times when I'm
>> ready to make a sensible commit.
> 
> May I ask why do you pull (a.k.a. "merge from master") at all while
> working on a feature?
> 
> Also, are we talking about you working on a feature branch, or about
> working directly on master?
> 
> Generally, work that takes more than, say, an hour or two, and is
> expected to involve a non-trivial amount of changes, is better done on
> a separate branch, which you then merge onto master when you are done.
> While working on such a branch, it makes little sense to merge from
> master, because that just brings unrelated changes that could
> potentially disrupt your development.  Instead, wait until you are
> finished with your changes, and then merge.  If you do that, then the
> potential conflicts due to pull/merge from master simply cannot
> happen.

When I develope a major new feature, it's usually because I'm scratching
some personal itch. I want to take advantage of whatever the feature
provides while I develop it. I also want to use the latest bugfixes and
unrelated features from Emacs trunk. Regularly rebasing my feature work
on top of trunk is the best way to accomplish both goals.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Steinar Bang]

>>>>> Daniel Colascione <dancol@dancol.org>:

> When I develope a major new feature, it's usually because I'm
> scratching some personal itch. I want to take advantage of whatever
> the feature provides while I develop it. I also want to use the latest
> bugfixes and unrelated features from Emacs trunk. Regularly rebasing
> my feature work on top of trunk is the best way to accomplish both
> goals.

Why do you rebase from master instead of merge from master?

Re: VC mode and git

[Eli Zaretskii]

> Date: Thu, 02 Apr 2015 14:32:32 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: schwab@suse.de, stephen@xemacs.org, hanche@math.ntnu.no, rms@gnu.org, 
>  emacs-devel@gnu.org
> 
> When I develope a major new feature, it's usually because I'm scratching
> some personal itch. I want to take advantage of whatever the feature
> provides while I develop it. I also want to use the latest bugfixes and
> unrelated features from Emacs trunk. Regularly rebasing my feature work
> on top of trunk is the best way to accomplish both goals.

I prefer to let more people use the features I develop, so I generally
try to merge to master as soon as possible.  Then the issue with
merges from master and rebasing is solved automatically.

Even if I wanted to use the feature only by myself for a while, I'd
probably start a new branch, separate from development, which would be
a mirror of master with my changes applied.

Anyway, all this just means is our development methodologies differ;
nothing wrong with that.  I described mine because I presume it should
be easier on people whose Git proficiency is just starting to be
built.

Re: VC mode and git

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stephen.
>
> On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote:
>> Alan Mackenzie writes:

[...]

>>  > Part of the problem is that the git-merge man page doesn't say that
>>  > it messes with the working tree
>
>> What else would it do?  Merge tools have changed the working tree from
>> time immemorial.
>
> That's poor, Stephen.  It might well merge in the repository without
> touching the working tree.  The fact is, the documentation doesn't say
> this - it doesn't even say where the two sources for its merge come from,
> or where it puts the result.

That's pure insinuation. Git documentation could be far from ideal, but
it has most of information there. Here is quote from Git manual page on
merge for you. It mentions what merge does to working tree 4 times, and
tells you exactly where it puts the two sources of conflicting merges:

[QUOTE=git help merge]

TRUE MERGE
       Except in a fast-forward merge (see above), the branches to be merged
       must be tied together by a merge commit that has both of them as its
       parents.

       A merged version reconciling the changes from all branches to be merged
       is committed, and your HEAD, index, and working tree are updated to it.
       It is possible to have modifications in the working tree as long as
       they do not overlap; the update will preserve them.

       When it is not obvious how to reconcile the changes, the following
       happens:

        1. The HEAD pointer stays the same.

        2. The MERGE_HEAD ref is set to point to the other branch head.

        3. Paths that merged cleanly are updated both in the index file and in
           your working tree.

        4. For conflicting paths, the index file records up to three versions:
           stage 1 stores the version from the common ancestor, stage 2 from
           HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
           git ls-files -u). The working tree files contain the result of the
           "merge" program; i.e. 3-way merge results with familiar conflict
           markers <<< === >>>.

        5. No other changes are made. In particular, the local modifications
           you had before you started merge will stay the same and the index
           entries for them stay as they were, i.e. matching HEAD.

       If you tried a merge which resulted in complex conflicts and want to
       start over, you can recover with git merge --abort.

[/QUOTE]

P.S. You sound like pure Git hater most of times. Haters will hate.
No matter what.

-- Sergey.

Re: VC mode and git

[Alan Mackenzie]

Hello, Sergey.

On Wed, Apr 01, 2015 at 12:28:25PM +0300, Sergey Organov wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >>  > Part of the problem is that the git-merge man page doesn't say that
> >>  > it messes with the working tree

> >> What else would it do?  Merge tools have changed the working tree from
> >> time immemorial.

> > That's poor, Stephen.  It might well merge in the repository without
> > touching the working tree.  The fact is, the documentation doesn't say
> > this - it doesn't even say where the two sources for its merge come from,
> > or where it puts the result.

> That's pure insinuation. Git documentation could be far from ideal, but
> it has most of information there. Here is quote from Git manual page on
> merge for you. It mentions what merge does to working tree 4 times, and
> tells you exactly where it puts the two sources of conflicting merges:

Exaggeration rather than insinuation, I think you mean.  The git
documentation is very bad.  The information may be there, but if it is
buried deep down in the small print, it is not useful.  We're not talking
about arcane details here, we're talking about the basic functionality -
what git merge actually does - what does it merge and where does it put
the result?

It's worth saying that the excerpt you quote below is at approximately
line 170 inside the man page.  If this is typical of git man pages, then
it would seem I have to read, say, ~200 lines of each of 20 or 30 man
pages to find the basic functionality of each command.

> [QUOTE=git help merge]

> TRUE MERGE
>        Except in a fast-forward merge (see above), the branches to be merged
>        must be tied together by a merge commit that has both of them as its
>        parents.

>        A merged version reconciling the changes from all branches to be merged
>        is committed, and your HEAD, index, and working tree are updated to it.
>        It is possible to have modifications in the working tree as long as
>        they do not overlap; the update will preserve them.

>        When it is not obvious how to reconcile the changes, the following
>        happens:

>         1. The HEAD pointer stays the same.

>         2. The MERGE_HEAD ref is set to point to the other branch head.

>         3. Paths that merged cleanly are updated both in the index file and in
>            your working tree.

>         4. For conflicting paths, the index file records up to three versions:
>            stage 1 stores the version from the common ancestor, stage 2 from
>            HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
>            git ls-files -u). The working tree files contain the result of the
>            "merge" program; i.e. 3-way merge results with familiar conflict
>            markers <<< === >>>.

>         5. No other changes are made. In particular, the local modifications
>            you had before you started merge will stay the same and the index
>            entries for them stay as they were, i.e. matching HEAD.

>        If you tried a merge which resulted in complex conflicts and want to
>        start over, you can recover with git merge --abort.

> [/QUOTE]

> P.S. You sound like pure Git hater most of times. Haters will hate.
> No matter what.

That's an uncalled for ad hominem.  I could equally well call you a git
lover, somebody who will love git to the end, deliberately remaining
oblivious to its many problems.  I do not hate, full stop.

I dislike git strongly because it has cost me and continues to cost me an
inordinate amount of time and effort to learn and use.  The vagueness and
general badness of its documentation is a large part of this.

> -- Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> Exaggeration rather than insinuation, I think you mean.  The git
> documentation is very bad.

Manpages are not tutorials.  There are a lot of good tutorials
available.  Just use them.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Wed, 01 Apr 2015 12:39:39 +0200
> Cc: Sergey Organov <sorganov@gmail.com>, emacs-devel@gnu.org
> 
> Manpages are not tutorials.  There are a lot of good tutorials
> available.  Just use them.

There's a large gap between where the tutorials leave off and the man
pages pick up.  I found nothing to fill that gap, in terms of
background information regarding what is going on.  There are a lot of
specific questions answered on StackOverflow and such likes, but they
provide cookbook-style solutions, which is very good for solving
specific problems, but not if one wants to understand what's going on
better.  So once you are past the basic stuff, you have nowhere else
to go to learn more, except from your own experience.

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> So once you are past the basic stuff, you have nowhere else to go to
> learn more, except from your own experience.

This is true for any complex software, including Emacs.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: acm@muc.de,  sorganov@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 01 Apr 2015 16:51:49 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So once you are past the basic stuff, you have nowhere else to go to
> > learn more, except from your own experience.
> 
> This is true for any complex software, including Emacs.

No, Emacs's manuals go much deeper than just the basics.

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: acm@muc.de,  sorganov@gmail.com,  emacs-devel@gnu.org
>> Date: Wed, 01 Apr 2015 16:51:49 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So once you are past the basic stuff, you have nowhere else to go to
>> > learn more, except from your own experience.
>> 
>> This is true for any complex software, including Emacs.
>
> No, Emacs's manuals go much deeper than just the basics.

But it is just as hard to find it if you don't know what to search for.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: acm@muc.de,  sorganov@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 01 Apr 2015 17:39:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Cc: acm@muc.de,  sorganov@gmail.com,  emacs-devel@gnu.org
> >> Date: Wed, 01 Apr 2015 16:51:49 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > So once you are past the basic stuff, you have nowhere else to go to
> >> > learn more, except from your own experience.
> >> 
> >> This is true for any complex software, including Emacs.
> >
> > No, Emacs's manuals go much deeper than just the basics.
> 
> But it is just as hard to find it if you don't know what to search for.

No, because the Emacs manuals have indices.

Re: VC mode and git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > No, Emacs's manuals go much deeper than just the basics.
>> 
>> But it is just as hard to find it if you don't know what to search for.
>
> No, because the Emacs manuals have indices.

Indices on Emacs manuals are a very unproductive way of finding
information.

Just my personal experience.

Re: VC mode and git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 01 Apr 2015 18:09:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > No, Emacs's manuals go much deeper than just the basics.
> >> 
> >> But it is just as hard to find it if you don't know what to search for.
> >
> > No, because the Emacs manuals have indices.
> 
> Indices on Emacs manuals are a very unproductive way of finding
> information.
> 
> Just my personal experience.

My personal experience is just the opposite, FWIW.

RE: VC mode and git

[Drew Adams]

> > Indices on Emacs manuals are a very unproductive way of finding
> > information. Just my personal experience.
> 
> My personal experience is just the opposite, FWIW.

Same here.

But it helps quite a bit to be able to use substring/regexp
completion matching.  (I use Icicles.)

It seems to be the case that many people nowadays are not used
to using indexes in general (e.g. books).  In many cases, users
are forced to make do with only search and no useful indexes,
for online help.  Given that (lamentable) state, it is no wonder
that some do not see the point (advantage) of indexes.  Dommage.

Re: VC mode and git

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> > Indices on Emacs manuals are a very unproductive way of finding
>> > information. Just my personal experience.
>> 
>> My personal experience is just the opposite, FWIW.
>
> Same here.
>
> But it helps quite a bit to be able to use substring/regexp
> completion matching.  (I use Icicles.)
>
> It seems to be the case that many people nowadays are not used
> to using indexes in general (e.g. books).  In many cases, users
> are forced to make do with only search and no useful indexes,
> for online help.  Given that (lamentable) state, it is no wonder
> that some do not see the point (advantage) of indexes.  Dommage.

Indices on the Emacs manual are good when you need to know where a
feature is explained and you know the terminology, as is the case of the
indices of most technical books I know. When you don't know the
terminology and just have a vague idea about how the topic you are
interested on *might* be named, you are lost. Modern search engines are
much better because, among other things, they build on the accumulated
experience of the user community, not only on what someone anticipated.

Re: VC mode and git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 01 Apr 2015 19:09:52 +0200
> 
> Indices on the Emacs manual are good when you need to know where a
> feature is explained and you know the terminology, as is the case of the
> indices of most technical books I know. When you don't know the
> terminology and just have a vague idea about how the topic you are
> interested on *might* be named, you are lost.

That's not how indices are written in the Emacs manuals: they do try
to cater to the situations where the reader knows only approximately
what she is looking for.  (They also index the exact terminology, of
course.)

So whenever you fail to find some subject description by feeding the
'i' command with a phrase you think is pertinent, please make a bug
report, because it ought to work, and we actively strive to make it
work.

RE: VC mode and git

[Drew Adams]

> Indices on the Emacs manual are good when you need to know where a
> feature is explained and you know the terminology, as is the case of the
> indices of most technical books I know. When you don't know the
> terminology and just have a vague idea about how the topic you are
> interested on *might* be named, you are lost. Modern search engines are
> much better because, among other things, they build on the accumulated
> experience of the user community, not only on what someone anticipated.

That's a fair point.  Both judgment by the producer of the doc and
smarts by an indexing (aka search) engine based on user experiences are
useful.

If you try to find something using the index in an Emacs manual, and
you don't find it using the terminology that you are used to, please
consider reporting it as an enhancement.  Eli, in particular, is very
good about adding index entries that correspond to user searches that
might not have been foreseen.

Re: VC mode and git

[Jose E. Marchesi]

    > > Indices on Emacs manuals are a very unproductive way of finding
    > > information. Just my personal experience.
    > 
    > My personal experience is just the opposite, FWIW.
    
    Same here.

Same here.  I find the concept index particularly useful.

Re: VC mode and git

[Harald Hanche-Olsen]

> Same here.  I find the concept index particularly useful.

There is “git help glossary”, which isn't quite the same, but goes some 
distance to serve the same need.

– Harald

Re: VC mode and git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Manpages are not tutorials.  There are a lot of good tutorials
>> available.  Just use them.
>
> There's a large gap between where the tutorials leave off and the man
> pages pick up.  I found nothing to fill that gap, in terms of
> background information regarding what is going on.  There are a lot of
> specific questions answered on StackOverflow and such likes, but they
> provide cookbook-style solutions, which is very good for solving
> specific problems, but not if one wants to understand what's going on
> better.

Please note that Alan mentioned several times that he is not interested
on the "what's going on" part of Git (which IMO is a reasonable stance,
but I do not understand why he insists on ignoring the advice about not
using the man pages for learning how to use Git and read instead some of
the multiple tutorials and introductions available on the 'net.)

> So once you are past the basic stuff, you have nowhere else
> to go to learn more, except from your own experience.

IIRC there are several technical articles about the innards of Git.

Re: VC mode and git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 01 Apr 2015 16:56:06 +0200
> 
> > There's a large gap between where the tutorials leave off and the man
> > pages pick up.  I found nothing to fill that gap, in terms of
> > background information regarding what is going on.  There are a lot of
> > specific questions answered on StackOverflow and such likes, but they
> > provide cookbook-style solutions, which is very good for solving
> > specific problems, but not if one wants to understand what's going on
> > better.
> 
> Please note that Alan mentioned several times that he is not interested
> on the "what's going on" part of Git

He also said he wanted to know what merge does, and that is what _I_
meant by "what's going on".

> IIRC there are several technical articles about the innards of Git.

That's not what is being sought here, see above.

Re: VC mode and git

[Alan Mackenzie]

Hello, Óscar.

On Wed, Apr 01, 2015 at 04:56:06PM +0200, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Manpages are not tutorials.  There are a lot of good tutorials
> >> available.  Just use them.

> > There's a large gap between where the tutorials leave off and the man
> > pages pick up.  I found nothing to fill that gap, in terms of
> > background information regarding what is going on.  There are a lot of
> > specific questions answered on StackOverflow and such likes, but they
> > provide cookbook-style solutions, which is very good for solving
> > specific problems, but not if one wants to understand what's going on
> > better.

> Please note that Alan mentioned several times that he is not interested
> on the "what's going on" part of Git (which IMO is a reasonable stance,
> but I do not understand why he insists on ignoring the advice about not
> using the man pages for learning how to use Git and read instead some of
> the multiple tutorials and introductions available on the 'net.)

These tutorials all deal with the basics.  I've read (parts of) a few
of them.  Their information density is very low - such is the nature of
tutorials.  If I have to skim over yet another exposition of how
wonderful it is that VCSs can work with branches, and so on, I think
I'll scream.

I think there's been just one concrete tutorial suggested to me, and
that was <http://git-scm.com/book/en/v2/>.  I'm sure it's an excellent
book, but it's several hundred pages long.

What I need is an information density which is typical of man pages (or
of the Emacs manuals).  I am frustrated and angered that the git man
pages don't have this information density - they suffer from vagueness
amongst other things - but they're all that there is.

> > So once you are past the basic stuff, you have nowhere else
> > to go to learn more, except from your own experience.

> IIRC there are several technical articles about the innards of Git.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

>> From: Andreas Schwab <schwab@suse.de>

>> Manpages are not tutorials.  There are a lot of good tutorials
>> available.  Just use them.

> There's a large gap between where the tutorials leave off and the man
> pages pick up.  I found nothing to fill that gap, in terms of
> background information regarding what is going on.

The "Pro Git" book filled that gap for me.  

Only when I actually started following the branching and merging
examples in the branches chapter, did things start to make sense to me.

Re: VC mode and git

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Sergey.
>
> On Wed, Apr 01, 2015 at 12:28:25PM +0300, Sergey Organov wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> >>  > Part of the problem is that the git-merge man page doesn't say that
>> >>  > it messes with the working tree
>
>> >> What else would it do?  Merge tools have changed the working tree from
>> >> time immemorial.
>
>> > That's poor, Stephen.  It might well merge in the repository without
>> > touching the working tree.  The fact is, the documentation doesn't say
>> > this - it doesn't even say where the two sources for its merge come from,
>> > or where it puts the result.
>
>> That's pure insinuation. Git documentation could be far from ideal, but
>> it has most of information there. Here is quote from Git manual page on
>> merge for you. It mentions what merge does to working tree 4 times, and
>> tells you exactly where it puts the two sources of conflicting merges:
>
> Exaggeration rather than insinuation, I think you mean.

I said what I meant: insinuation.

> The git documentation is very bad. The information may be there, but
> if it is buried deep down in the small print, it is not useful. We're
> not talking about arcane details here, we're talking about the basic
> functionality - what git merge actually does - what does it merge and
> where does it put the result?

If you are not interested in details, the manual page explains what
merge does and where it puts result in the first sentence of the
description:

"Incorporates changes from the named commits (since the time their
histories diverged from the current branch) into the current branch."

>> > this - it doesn't even say where the two sources for its merge come from,
>> > or where it puts the result.

Oh, really?

>> > Part of the problem is that the git-merge man page doesn't say that
>> > it messes with the working tree

Oh, really? Anybody who doesn't actively avoid to understand anything
"git" will easily infer that the working tree should be updated
accordingly, as "the current" is those branch that working tree
reflects, by definition.

Haters will hate, anyway.

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Wed, 01 Apr 2015 16:03:26 +0300
> Cc: emacs-devel@gnu.org
> 
> > Exaggeration rather than insinuation, I think you mean.
> 
> I said what I meant: insinuation.

I think you were wrong.

> If you are not interested in details, the manual page explains what
> merge does and where it puts result in the first sentence of the
> description:
> 
> "Incorporates changes from the named commits (since the time their
> histories diverged from the current branch) into the current branch."

Good luck understanding this when learning what merge does in Git!
Starting from the "branch" thingy, which, as you will read everywhere
is just a pointer to the HEAD commit.  So what does it mean to
"incorporate changes in the current branch", if the branch is just a
pointer?

And then there's "histories diverged" part, of course, that is never
explained.

And finally, even if you succeed in negotiating these obstacles,
there's still the important question: what does it mean to
"incorporate in the branch"? what does it change, and in what order?

Of course, if you already know how merge works in Git, have merged
your own branches several times, and had your share of mistakes until
you finally got it -- then this text will speak volumes to you.  But
that's not what Alan complained about.

> >> > Part of the problem is that the git-merge man page doesn't say that
> >> > it messes with the working tree
> 
> Oh, really? Anybody who doesn't actively avoid to understand anything
> "git" will easily infer that the working tree should be updated
> accordingly, as "the current" is those branch that working tree
> reflects, by definition.

Oh, really?  You mean merge doesn't work, or is a no-op, in a "bare"
repository, where there's no tree?

Give up!  Git's documentation "needs work" (TM).  It's futile to try
to refute that.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Wed, 01 Apr 2015 16:03:26 +0300
>> Cc: emacs-devel@gnu.org
>> 
>> > Exaggeration rather than insinuation, I think you mean.
>> 
>> I said what I meant: insinuation.
>
> I think you were wrong.
>
>> If you are not interested in details, the manual page explains what
>> merge does and where it puts result in the first sentence of the
>> description:
>> 
>> "Incorporates changes from the named commits (since the time their
>> histories diverged from the current branch) into the current branch."
>
> Good luck understanding this when learning what merge does in Git!
> Starting from the "branch" thingy, which, as you will read everywhere
> is just a pointer to the HEAD commit.  So what does it mean to
> "incorporate changes in the current branch", if the branch is just a
> pointer?

Yes, a pointer that moves to point to new commit automatically every
time you commit on the branch. Incorporating changes means the same
thing every time: commit. What's new or unusual about it?

> And then there's "histories diverged" part, of course, that is never
> explained.

Yeah it's total mystery to everybody. If one is so novice that she has
no idea about "history diverged" thingy, she should really start from
some basic tutorial, not from reading "git merge" manual page.

> And finally, even if you succeed in negotiating these obstacles,
> there's still the important question: what does it mean to
> "incorporate in the branch"? what does it change, and in what order?

Basically, it means exactly what it says: your changes from divergence
point to the named commit will now be there in the current branch.

The details are explained later in the same manual page, as they depend
on different modes of operation.

> Of course, if you already know how merge works in Git, have merged
> your own branches several times, and had your share of mistakes until
> you finally got it -- then this text will speak volumes to you.  But
> that's not what Alan complained about.

In this particular case he said utter lie about particular git manual
page. It's useless to deny that. That was the only reason I had to
intervene.

>> >> > Part of the problem is that the git-merge man page doesn't say that
>> >> > it messes with the working tree
>> 
>> Oh, really? Anybody who doesn't actively avoid to understand anything
>> "git" will easily infer that the working tree should be updated
>> accordingly, as "the current" is those branch that working tree
>> reflects, by definition.
>
> Oh, really?  You mean merge doesn't work, or is a no-op, in a "bare"
> repository, where there's no tree?

[(BARE:master)]$ git merge v3.6
fatal: This operation must be run in a work tree
[(BARE:master)]$

But it's even irrelevant. One needs to have work tree to care about
changes to work tree, that excludes bare repositories from discussion.

> Give up!  Git's documentation "needs work" (TM).  It's futile to try
> to refute that.

Nobody refutes it. Any documentation needs work (TM). Git's needs work.
It does not mean that spreading misinformation about its current state
is acceptable.

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Wed, 01 Apr 2015 18:52:20 +0300
> 
> >> "Incorporates changes from the named commits (since the time their
> >> histories diverged from the current branch) into the current branch."
> >
> > Good luck understanding this when learning what merge does in Git!
> > Starting from the "branch" thingy, which, as you will read everywhere
> > is just a pointer to the HEAD commit.  So what does it mean to
> > "incorporate changes in the current branch", if the branch is just a
> > pointer?
> 
> Yes, a pointer that moves to point to new commit automatically every
> time you commit on the branch. Incorporating changes means the same
> thing every time: commit. What's new or unusual about it?

A merge does much more than just commit.  At least AFAIU.

> > And then there's "histories diverged" part, of course, that is never
> > explained.
> 
> Yeah it's total mystery to everybody. If one is so novice that she has
> no idea about "history diverged" thingy, she should really start from
> some basic tutorial, not from reading "git merge" manual page.

Please don't underestimate the difficulty of reading highly technical
text full of unexplained terminology.

> In this particular case he said utter lie

Whoa!  Slow down, nobody lies here.

> > Give up!  Git's documentation "needs work" (TM).  It's futile to try
> > to refute that.
> 
> Nobody refutes it. Any documentation needs work (TM). Git's needs work.
> It does not mean that spreading misinformation about its current state
> is acceptable.

Saying that documentation is inadequate isn't spreading
misinformation.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Wed, 01 Apr 2015 18:52:20 +0300
>> 
>> >> "Incorporates changes from the named commits (since the time their
>> >> histories diverged from the current branch) into the current branch."
>> >
>> > Good luck understanding this when learning what merge does in Git!
>> > Starting from the "branch" thingy, which, as you will read everywhere
>> > is just a pointer to the HEAD commit.  So what does it mean to
>> > "incorporate changes in the current branch", if the branch is just a
>> > pointer?
>> 
>> Yes, a pointer that moves to point to new commit automatically every
>> time you commit on the branch. Incorporating changes means the same
>> thing every time: commit. What's new or unusual about it?
>
> A merge does much more than just commit.  At least AFAIU.

Dunno what you have in mind. After true merge operation is finished, the
only result of it is single commit appended to your current branch. Git
/is/ that simple. All the possible complexity is in the stage of content
preparation for this commit.

[...]

>> In this particular case he said utter lie
>
> Whoa!  Slow down, nobody lies here.

I didn't mean that he intentionally lied, sorry if it sounded like that.
What he said is not true though. Misinformation.

>
>> > Give up!  Git's documentation "needs work" (TM).  It's futile to try
>> > to refute that.
>> 
>> Nobody refutes it. Any documentation needs work (TM). Git's needs work.
>> It does not mean that spreading misinformation about its current state
>> is acceptable.
>
> Saying that documentation is inadequate isn't spreading
> misinformation.

Please re-read what I complained about. Here is what Alan said about git
merge manual page:

"... it doesn't even say where the two sources for its merge come from,
or where it puts the result."

"Part of the problem is that the git-merge man page doesn't say that it
messes with the working tree."

I'm sorry, but it /is/ plain misinformation, as anybody can readily see
himself by RTM.

Don't spread misinformation, please.

-- Sergey.

Re: VC mode and git

[Harald Hanche-Olsen]

Sergey Organov wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
>> A merge does much more than just commit.  At least AFAIU.
>
> Dunno what you have in mind. After true merge operation is finished, the
> only result of it is single commit appended to your current branch. Git
> /is/ that simple. All the possible complexity is in the stage of content
> preparation for this commit.

Yes, but that complexity can be considerable. Isn't it reasonable to 
assume that that is what Eli had in mind?

– Harald

Re: VC mode and git

[Sergey Organov]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> Sergey Organov wrote:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>> A merge does much more than just commit.  At least AFAIU.
>>
>> Dunno what you have in mind. After true merge operation is finished, the
>> only result of it is single commit appended to your current branch. Git
>> /is/ that simple. All the possible complexity is in the stage of content
>> preparation for this commit.
>
> Yes, but that complexity can be considerable. Isn't it reasonable to
> assume that that is what Eli had in mind?

I prefer not to assume if I can ask.

We seem to discuss git, not complexity of content merge algorithms.

Maybe Eli has some ideas about something else git does besides
committing resulting changes, how do I know?

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Thu, 02 Apr 2015 15:27:18 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Sergey Organov <sorganov@gmail.com>
> >> Date: Wed, 01 Apr 2015 18:52:20 +0300
> >> 
> >> >> "Incorporates changes from the named commits (since the time their
> >> >> histories diverged from the current branch) into the current branch."
> >> >
> >> > Good luck understanding this when learning what merge does in Git!
> >> > Starting from the "branch" thingy, which, as you will read everywhere
> >> > is just a pointer to the HEAD commit.  So what does it mean to
> >> > "incorporate changes in the current branch", if the branch is just a
> >> > pointer?
> >> 
> >> Yes, a pointer that moves to point to new commit automatically every
> >> time you commit on the branch. Incorporating changes means the same
> >> thing every time: commit. What's new or unusual about it?
> >
> > A merge does much more than just commit.  At least AFAIU.
> 
> Dunno what you have in mind.

The changes to meta-data that reflect the changes in the history DAG.

> > Saying that documentation is inadequate isn't spreading
> > misinformation.
> 
> Please re-read what I complained about. Here is what Alan said about git
> merge manual page:
> 
> "... it doesn't even say where the two sources for its merge come from,
> or where it puts the result."
> 
> "Part of the problem is that the git-merge man page doesn't say that it
> messes with the working tree."

I understood that as meaning the information was not clear enough.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Thu, 02 Apr 2015 15:27:18 +0300
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> From: Sergey Organov <sorganov@gmail.com>
>> >> Date: Wed, 01 Apr 2015 18:52:20 +0300
>> >> 
>> >> >> "Incorporates changes from the named commits (since the time their
>> >> >> histories diverged from the current branch) into the current branch."
>> >> >
>> >> > Good luck understanding this when learning what merge does in Git!
>> >> > Starting from the "branch" thingy, which, as you will read everywhere
>> >> > is just a pointer to the HEAD commit.  So what does it mean to
>> >> > "incorporate changes in the current branch", if the branch is just a
>> >> > pointer?
>> >> 
>> >> Yes, a pointer that moves to point to new commit automatically every
>> >> time you commit on the branch. Incorporating changes means the same
>> >> thing every time: commit. What's new or unusual about it?
>> >
>> > A merge does much more than just commit.  At least AFAIU.
>> 
>> Dunno what you have in mind.
>
> The changes to meta-data that reflect the changes in the history DAG.

No meta-data outside of the commit, AFAIK.

Each commit has zero or more pointers to parents, usually 1. Merge
commit is commit that has more pointers to parents than 1 (usually 2).
That's all about the meta-data. Simple, eh?

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Thu, 02 Apr 2015 20:02:02 +0300
> 
> >> > A merge does much more than just commit.  At least AFAIU.
> >> 
> >> Dunno what you have in mind.
> >
> > The changes to meta-data that reflect the changes in the history DAG.
> 
> No meta-data outside of the commit, AFAIK.
> 
> Each commit has zero or more pointers to parents, usually 1. Merge
> commit is commit that has more pointers to parents than 1 (usually 2).
> That's all about the meta-data. Simple, eh?

And that meta-data needs to be brought in as part of the merge, in
addition to changes to the tree.

You can call all of this a "commit", but then you probably mean
"commit object", a different beast.  Using confusing shorts in this
discussion doesn't help understanding.

Re: VC mode and git

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> And that meta-data needs to be brought in as part of the merge, in
> addition to changes to the tree.

Just like a commit with a single parent, or any commit.

Andreas.

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

Re: VC mode and git

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Sergey Organov <sorganov@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 02 Apr 2015 20:28:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And that meta-data needs to be brought in as part of the merge, in
> > addition to changes to the tree.
> 
> Just like a commit with a single parent, or any commit.

I never said otherwise.  This is not about differences (or lack
thereof) between a "normal" commit and a merge-commit.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Thu, 02 Apr 2015 20:02:02 +0300
>> 
>> >> > A merge does much more than just commit.  At least AFAIU.
>> >> 
>> >> Dunno what you have in mind.
>> >
>> > The changes to meta-data that reflect the changes in the history DAG.
>> 
>> No meta-data outside of the commit, AFAIK.
>> 
>> Each commit has zero or more pointers to parents, usually 1. Merge
>> commit is commit that has more pointers to parents than 1 (usually 2).
>> That's all about the meta-data. Simple, eh?
>
> And that meta-data needs to be brought in as part of the merge, in
> addition to changes to the tree.
>
> You can call all of this a "commit", but then you probably mean
> "commit object", a different beast.  Using confusing shorts in this
> discussion doesn't help understanding.

OK, let me try to be more precise then.

No matter if you perform commit operation or merge operation, similar
DAG meta-information is stored into the commit object by Git: the list
of references to the ancestors of this commit object.

If you did not mean that storing 2 references instead of 1 into the
commit object is doing "much more than just commit", then what did you
mean? What changes to what meta-data? Reflecting what changes in the
history DAG?

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Thu, 02 Apr 2015 23:50:03 +0300
> 
> If you did not mean that storing 2 references instead of 1 into the
> commit object is doing "much more than just commit", then what did you
> mean?

The Git glossary says:

  commit 
    As a noun: A single point in the Git history; the entire history of
    a project is represented as a set of interrelated commits.

  merge 
     As a verb: To bring the contents of another branch (possibly from
     an external repository) into the current branch. [...]  Merging
     is performed by an automatic process that identifies changes made
     since the branches diverged, and then applies all those changes
     together. [...]

     As a noun: [...] a successful merge results in the creation of a
     new commit representing the result of the merge, and having as
     parents the tips of the merged branches.

Alan was interested in what the merge does, which is outlined in the
"merge as a verb" part above.  That description clearly says that a
merge _results_ in a commit, but it is _not_ "just a commit",
especially if you, like Alan, are interested in what happens _during_
the merge operation.

I hope this clarifies what I meant.  In plain words, when people who
know little about Git ask what does a merge do, and you want to be
helpful, don't say confusingly paradoxical things, even if they are
90% correct, because all that will do is confuse them even more.  (My
advice, feel free to disregard.)

Re: VC mode and git

[Sergey Organov]

Eli, here is how our conversation went so far (emphasizes are mine):

You [trying to show how bad Git documentation is]:

     So what does it mean to "incorporate changes in the current
     branch", if the branch is just a pointer?

Me:  Incorporating changes means the same thing every time: commit.
     What's new or unusual about it?

You: A merge does much more than just commit.  At least AFAIU.

Me:  Dunno what you have in mind. After true merge operation is
     finished, the only result of it is single commit appended to your
     current branch. Git /is/ that simple. *All the possible complexity
     is in the stage of content preparation for this commit.*

You: [as the answer to "Dunno what you have in mind"]:

     The changes to meta-data that reflect the changes in the history
     DAG.

Me:  No meta-data outside of the commit, AFAIK. [then explaining the
     only 2 references of meta-data stored in commit]

You: That meta-data needs to be brought in as part of the merge, *in
     addition to changes to the tree*.

Me:  What did you mean? What changes to what meta-data? Reflecting what
     changes in the history DAG?

And now I got your recent answer that doesn't even mention either "DAG"
or "meta-data", but rather suddenly unveils the fact that 'git merge'
computes *changes to the tree* before committing the result. I'm sorry,
but I have to give-up at this point.

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Fri, 03 Apr 2015 17:43:36 +0300
> 
> And now I got your recent answer that doesn't even mention either "DAG"
> or "meta-data", but rather suddenly unveils the fact that 'git merge'
> computes *changes to the tree* before committing the result. I'm sorry,
> but I have to give-up at this point.

To reiterate what I think should already be clear from the previous
messages: merging brings changes from another branch, identifies the
subset of changes made since the branches diverged, and then applies
those changes, finally creating a merge-commit.  (I didn't invent
that, it's a more-or-less direct citation from the Git glossary man
page.)

So yes, it's more than "just a commit".  Its result is a special kind
of a commit, but the process of merging does more than just that.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Sergey Organov <sorganov@gmail.com>

 > > Each commit has zero or more pointers to parents, usually 1. Merge
 > > commit is commit that has more pointers to parents than 1 (usually 2).
 > > That's all about the meta-data. Simple, eh?
 > 
 > And that meta-data needs to be brought in as part of the merge, in
 > addition to changes to the tree.

No.  That's an important difference between git and other DVCSes.
"git merge" does a 3-way merge in a tree that corresponds to a
previously committed state, and sets up some (hidden) metadata that
help automate the following multi-parent commit.  Optionally it will
initiate that commit.

The meta-data must already be present in the repo pointed to by the
workspace, brought in by a fetch.  Because it's a very common
operation, especially in synchronizing mirror repos, git pull will
automatically fetch and merge.  Perhaps that what you think about it.

 > You can call all of this a "commit", but then you probably mean
 > "commit object", a different beast.  Using confusing shorts in this
 > discussion doesn't help understanding.

In discussing git, claiming that "commit" is anything other than a
verb that means "to create a commit object" is what confuses
understanding.  You will confuse those who are familiar with git and
give incorrect ideas to those who aren't.  If you have a different
concept of what a commit "should be", you need to explain that, and
what sequence of git operations correspond to that concept.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Sergey Organov <sorganov@gmail.com>,
>     emacs-devel@gnu.org
> Date: Fri, 03 Apr 2015 07:40:40 +0900
> 
> Eli Zaretskii writes:
>  > > From: Sergey Organov <sorganov@gmail.com>
> 
>  > > Each commit has zero or more pointers to parents, usually 1. Merge
>  > > commit is commit that has more pointers to parents than 1 (usually 2).
>  > > That's all about the meta-data. Simple, eh?
>  > 
>  > And that meta-data needs to be brought in as part of the merge, in
>  > addition to changes to the tree.
> 
> No.  That's an important difference between git and other DVCSes.
> "git merge" does a 3-way merge in a tree that corresponds to a
> previously committed state, and sets up some (hidden) metadata that
> help automate the following multi-parent commit.  Optionally it will
> initiate that commit.
> 
> The meta-data must already be present in the repo pointed to by the
> workspace, brought in by a fetch.  Because it's a very common
> operation, especially in synchronizing mirror repos, git pull will
> automatically fetch and merge.  Perhaps that what you think about it.

I know all of the above, and I don't see where it contradicts what I
wrote.

The original issue was a claim that a merge (as an operation) is "just
a commit", and I said it's more than that.

>  > You can call all of this a "commit", but then you probably mean
>  > "commit object", a different beast.  Using confusing shorts in this
>  > discussion doesn't help understanding.
> 
> In discussing git, claiming that "commit" is anything other than a
> verb that means "to create a commit object" is what confuses
> understanding.  You will confuse those who are familiar with git and
> give incorrect ideas to those who aren't.  If you have a different
> concept of what a commit "should be", you need to explain that, and
> what sequence of git operations correspond to that concept.

My terminology follows the Git glossary man page, which I think
doesn't agree with the above, at least not 100%.  E.g., "commit",
neither as a noun nor as a verb, is not described there as "creating a
commit object".

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Sergey Organov <sorganov@gmail.com>,
 > >     emacs-devel@gnu.org
 > > Date: Fri, 03 Apr 2015 07:40:40 +0900
 > > 
 > > Eli Zaretskii writes:
 > >  > > From: Sergey Organov <sorganov@gmail.com>
 > > 
 > >  > > Each commit has zero or more pointers to parents, usually 1. Merge
 > >  > > commit is commit that has more pointers to parents than 1 (usually 2).
 > >  > > That's all about the meta-data. Simple, eh?
 > >  > 
 > >  > And that meta-data needs to be brought in as part of the merge, in
 > >  > addition to changes to the tree.
 > > 
 > > No.  That's an important difference between git and other DVCSes.
 > > "git merge" does a 3-way merge in a tree that corresponds to a
 > > previously committed state, and sets up some (hidden) metadata that
 > > help automate the following multi-parent commit.  Optionally it will
 > > initiate that commit.
 > > 
 > > The meta-data must already be present in the repo pointed to by the
 > > workspace, brought in by a fetch.  Because it's a very common
 > > operation, especially in synchronizing mirror repos, git pull will
 > > automatically fetch and merge.  Perhaps that what you think about it.
 > 
 > I know all of the above, and I don't see where it contradicts what I
 > wrote.

You wrote "the meta-data needs to be brought in".  That's simply
false; when git merge is invoked, the meta data must already be
present or you will get an "unknown commit" error.  You're trying to
argue that a merge (and similarly for commit) is something more than
it is.  It isn't in git, although it is in bzr and hg, and it's
something rather different again from either in Darcs.  This is just
going to lead to more confusion on the part of those who think git
"should" be something different than it is.
 
 > The original issue was a claim that a merge (as an operation) is "just
 > a commit", and I said it's more than that.

Sergey (at least as quoted above) wrote "merge commit", so technically
it *is* just a commit.

But in any case, your "more than that" so far is pure hand-waving, not
supported by the actual semantics of "git merge," "git commit," or the
commit object.  This is more your list than mine, I'm happy to use your
terminology.  But I refuse to accept "it's more than that" as a
definition.

 > My terminology follows the Git glossary man page, which I think
 > doesn't agree with the above, at least not 100%.  E.g., "commit",
 > neither as a noun nor as a verb, is not described there as "creating a
 > commit object".

Are you looking at the same glossary entry I am?  It says (and I quote
in full so there can be no confusion):

       commit

           As a noun: A single point in the Git history; the entire
           history of a project is represented as a set of
           interrelated commits. The word "commit" is often used by
           Git in the same places other revision control systems use
           the words "revision" or "version". Also used as a short
           hand for commit object.

           As a verb: The action of storing a new snapshot of the
           project's state in the Git history, by creating a new
           commit representing the current state of the index and
           advancing HEAD to point at the new commit.

The "verb" describes exactly "creating a commit object", using the
shorthand of "commit" for "commit object" described in the noun
section.  The additional semantics you pull in are simply not there at
all, except in a reference to "same places other VCSes" use different
words that is so vague it makes me cringe.

Note that you can't even claim that there's a need to collect meta
data for the tree; that's *already* in the index in principle (ie, if
you use "git add <file>; git commit" instead of the shorthand "git
commit <file>").

You can quibble a bit, for example, you can claim that "git commit
<file>" is more fundamental than I claim above.  But I don't see much
room for anything more than "you may need to create a tree object a
well as a commit object."  If you want to claim there are additional
semantics, I see no alternative except that you define them
explicitly, as I requested above.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Fri, 03 Apr 2015 17:00:42 +0900
> 
> You wrote "the meta-data needs to be brought in".  That's simply
> false; when git merge is invoked, the meta data must already be
> present or you will get an "unknown commit" error.

Irrelevant: we are not talking about the invocation of "git merge".
See the glossary, under "merge" for what it includes.

> You're trying to argue that a merge (and similarly for commit) is
> something more than it is.

See the glossary: a (successful) merge _results_ in a commit, but
that's not what it _is_.  (Should I quote Lewis Carrol's immortal
piece about the difference between the name of a thing and the thing
itself?)

>  > The original issue was a claim that a merge (as an operation) is "just
>  > a commit", and I said it's more than that.
> 
> Sergey (at least as quoted above) wrote "merge commit", so technically
> it *is* just a commit.

Alan was interested in what the merge does, so talking about a "merge
commit" is changing subjects.

I'm saying that trying to explain to newbies what a merge does by
being "technically correct" is not helpful.  I don't even understand
all this attitude: do we want Git newbies to become more proficient in
using Git, or do we want to just humiliate them by pointing out how
little they know?  If the former, why do we insist on being
"technically correct" instead of explaining things in a way they could
be understood?

> But in any case, your "more than that" so far is pure hand-waving, not
> supported by the actual semantics of "git merge," "git commit," or the
> commit object.  This is more your list than mine, I'm happy to use your
> terminology.  But I refuse to accept "it's more than that" as a
> definition.

Complain to the writers of the Git glossary, then.  I just read what
they say there.

>  > My terminology follows the Git glossary man page, which I think
>  > doesn't agree with the above, at least not 100%.  E.g., "commit",
>  > neither as a noun nor as a verb, is not described there as "creating a
>  > commit object".
> 
> Are you looking at the same glossary entry I am?  It says (and I quote
> in full so there can be no confusion):
> 
>        commit
> 
>            As a noun: A single point in the Git history; the entire
>            history of a project is represented as a set of
>            interrelated commits. The word "commit" is often used by
>            Git in the same places other revision control systems use
>            the words "revision" or "version". Also used as a short
>            hand for commit object.
> 
>            As a verb: The action of storing a new snapshot of the
>            project's state in the Git history, by creating a new
>            commit representing the current state of the index and
>            advancing HEAD to point at the new commit.
> 
> The "verb" describes exactly "creating a commit object"

No, it is described as "the action of storing a new snapshot of the
project's state in the Git history by creating a commit object and
advancing HEAD to point at the new commit".  By selectively omitting
the parts of this description, you make it sound like I said
something incorrect, which is false.

> using the shorthand of "commit" for "commit object" described in the
> noun section.

I already said that using shorthands in this discussion only increases
confusion, and is not helpful to newbies who strive to understand a
complex subject.

> Note that you can't even claim that there's a need to collect meta
> data for the tree; that's *already* in the index in principle (ie, if
> you use "git add <file>; git commit" instead of the shorthand "git
> commit <file>").

READ THE GLOSSARY UNDER "MERGE"!!  It clearly says that the merge
action _includes_ bringing that data.

> You can quibble a bit, for example, you can claim that "git commit
> <file>" is more fundamental than I claim above.  But I don't see much
> room for anything more than "you may need to create a tree object a
> well as a commit object."  If you want to claim there are additional
> semantics, I see no alternative except that you define them
> explicitly, as I requested above.

I'm just following the glossary, no more, no less.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > See the glossary: a (successful) merge _results_ in a commit, but
 > that's not what it _is_.  (Should I quote Lewis Carrol's immortal
 > piece about the difference between the name of a thing and the thing
 > itself?)

No.  You should say what you mean, instead of telling others that
they're wrong and saying anything *but* what you mean.  "What you have
ment throughout" was well-expressed in your reply to Sergey when you
mentioned the branch-tracing operation which gives the commit that
contains the tree for the "base version" of a three-way merge.

 > I'm saying that trying to explain to newbies what a merge does by
 > being "technically correct" is not helpful.

Being technically *incorrect* is even less helpful.  Your answer to
Alan (indirectly via Sergey) that a merge (1) identifies a base
commit, (2) uses that and the trees of the two branch heads (usually)
to perform a 3-way merge, (3) collects the metadata (specifically, the
new tree and the parents), (4) assembles that into a commit which is
stored in the tree, and (5) advances HEAD of the current branch to
that commit is indeed useful, but from Alan's point of view you still
missed a crucial point, which is that git operates on *commits*, and
not directly on the workspace.  It is *convenient* to use the
workspace for the work (since you're going to check out the merged
tree there in the end), and that is the (technical) reason you need to
be committed up before merging.

 > I don't even understand all this attitude: do we want Git newbies
 > to become more proficient in using Git,

No, we want to support their efforts to become more productive using
git.  If they want to become proficient, I don't think there's any
problem.  But Alan and Richard have expressed a rather strong desire
to learn *nothing* about git, yet insist on workflows that are
infeasible if they remain ignorant of the details and options of git.
They can't have both; the first task is to make that clear, so that
they can make their own choice as to whether to become proficient in
git, or to adopt a workflow that is less than optimal according to
their opinions.

 > or do we want to just humiliate them by pointing out how little
 > they know?

That was uncalled for.

 > If the former, why do we insist on being "technically correct"
 > instead of explaining things in a way they could be understood?

Because it's entirely unclear to me what they are asking.  Richard
is incapable of describing what he actually did, yet bridles at any
suggestion that his actions were involved in messing things up
(despite repeated admissions that he forgot this or that).  Alan is
similar.  They profess ignorance of git but assert that it is a
"screw" and poorly designed.

 > No, it is described as "the action of storing a new snapshot of the
 > project's state in the Git history by creating a commit object and
 > advancing HEAD to point at the new commit".  By selectively omitting
 > the parts of this description, you make it sound like I said
 > something incorrect, which is false.

OK, you are correct, it is more than creating a commit object.  It
also includes advancing HEAD.  How does that level of nitpicking
advance the cause of explaining to Alan what a commit is?

 > > using the shorthand of "commit" for "commit object" described in the
 > > noun section.
 > 
 > I already said that using shorthands in this discussion only increases
 > confusion, and is not helpful to newbies who strive to understand a
 > complex subject.

"Complain to the writers of the Git glossary, then.  I just read what
they say there."

 > > Note that you can't even claim that there's a need to collect meta
 > > data for the tree; that's *already* in the index in principle (ie, if
 > > you use "git add <file>; git commit" instead of the shorthand "git
 > > commit <file>").
 > 
 > READ THE GLOSSARY UNDER "MERGE"!!

Why?  Here I was discussing "commit", which you also claim
(pedantically correct) is more than simply creating a commit object.

However, I did read it a couple of times, and with the exception of
your post to Sergey, I have no clue what you're talking about.

 > It clearly says that the merge action _includes_ bringing that
 > data.

Ah, with "merge", we have an English problem.  "Bring" and the other
words you have used to describe the *computation* of the merged tree
are inappropriate.  They correspond semantically to *fetch*.

 > I'm just following the glossary, no more, no less.

Quite inaccurately, IMO, and while it doesn't matter who's "correct",
that *difference* matters, because when you refer to the glossary
without precise description of what you mean *in your own words*, I
understand something different from what you intend, and communication
fails.

You're perfectly capable of expressing yourself operationally; your
post to Sergey was beautiful, concise and accurate, and after reading
that I quite understood what you have been getting at the whole time.
I wish you would write more posts like that.  Your shouting about
"READ!  READ!" on the other hand, is totally useless.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sat, 04 Apr 2015 02:31:29 +0900
> 
> Eli Zaretskii writes:
> 
>  > I'm saying that trying to explain to newbies what a merge does by
>  > being "technically correct" is not helpful.
> 
> Being technically *incorrect* is even less helpful.

Teaching people new things often requires to start without rigor,
because otherwise you risk losing your audience.  Being "technically
correct", but confusing instead of explanatory is not helpful.

>  > I don't even understand all this attitude: do we want Git newbies
>  > to become more proficient in using Git,
> 
> No, we want to support their efforts to become more productive using
> git.

Take it from a bystander: that's not how many messages in this thread
sound.

> If they want to become proficient, I don't think there's any
> problem.  But Alan and Richard have expressed a rather strong desire
> to learn *nothing* about git

They didn't say that, please re-read their messages with open eyes.

What they did say is (a) they don't like investing an inordinate
amount of time and effort into studying Git, and (b) they would like
to keep their previous workflows as much as possible.

So if we want to help them become proficient, we need to go with them
and educate them while trying to honor these 2 desires.  Any other way
is bound to trigger bad feelings, and eventually fail our attempts to
help them become more proficient.

> yet insist on workflows that are infeasible if they remain ignorant
> of the details and options of git.

They are not infeasible.  They need only minor adaptations, see
GitQuickStartForEmacsDevs.  Those adaptations do not require any
details and options of git, just one new command.

> They can't have both; the first task is to make that clear, so that
> they can make their own choice as to whether to become proficient in
> git, or to adopt a workflow that is less than optimal according to
> their opinions.

That's one approach to teaching Git.  I think it's not a very
efficient one, at least in this case.  I think less radical approaches
might score better.

>  > If the former, why do we insist on being "technically correct"
>  > instead of explaining things in a way they could be understood?
> 
> Because it's entirely unclear to me what they are asking.

If you don't understand what they are asking, may I suggest that you
wait with your answers until you do, or ask someone else?

> Richard is incapable of describing what he actually did, yet bridles
> at any suggestion that his actions were involved in messing things
> up (despite repeated admissions that he forgot this or that).

What he did became clear, even to me, after he showed the information
we requested.

> They profess ignorance of git but assert that it is a "screw" and
> poorly designed.

People tend to become angry with a tool that seems to get in the way.
It's understandable.  If you want to help them, the last thing you
should do is become angry back, or somehow feel insulted on behalf of
the tool.  I make that mistake at times, and it never helps.

>  > No, it is described as "the action of storing a new snapshot of the
>  > project's state in the Git history by creating a commit object and
>  > advancing HEAD to point at the new commit".  By selectively omitting
>  > the parts of this description, you make it sound like I said
>  > something incorrect, which is false.
> 
> OK, you are correct, it is more than creating a commit object.  It
> also includes advancing HEAD.  How does that level of nitpicking
> advance the cause of explaining to Alan what a commit is?

It's for Alan to say if it's more helpful than saying that a merge is
"just a commit".  AFAIU, he explicitly expressed a desire to
understand what happens during a merge.  I think the above does help,
but that's me.

>  > > using the shorthand of "commit" for "commit object" described in the
>  > > noun section.
>  > 
>  > I already said that using shorthands in this discussion only increases
>  > confusion, and is not helpful to newbies who strive to understand a
>  > complex subject.
> 
> "Complain to the writers of the Git glossary, then.  I just read what
> they say there."

They stated a fact.  They didn't tell when to use that shorthand.

> You're perfectly capable of expressing yourself operationally; your
> post to Sergey was beautiful, concise and accurate, and after reading
> that I quite understood what you have been getting at the whole time.
> I wish you would write more posts like that.

Thanks, I'm trying.

> Your shouting about "READ!  READ!" on the other hand, is totally
> useless.

OK, I will try to avoid that.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

> It's for Alan to say if it's more helpful than saying that a merge is
> "just a commit".

You are putting words into (my?) mouth. Nobody ever said that merge, the
operation, is just a commit, AFAIR. If you indeed meant me, that's what
I said:

     After true merge operation is finished, the only result of it is
     single commit appended to your current branch. Git /is/ that
     simple. All the possible complexity is in the stage of content
     preparation for this commit.

I fail to see how this could be taken as saying that merge is just a
commit. What I wanted to tell /you/, not /Alan/, is that there is no any
hidden meta-information or other mysteries involved.

-- Sergey.

Re: VC mode and git

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Sat, 04 Apr 2015 00:40:58 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's for Alan to say if it's more helpful than saying that a merge is
> > "just a commit".
> 
> You are putting words into (my?) mouth. Nobody ever said that merge, the
> operation, is just a commit, AFAIR. If you indeed meant me, that's what
> I said:
> 
>      After true merge operation is finished, the only result of it is
>      single commit appended to your current branch. Git /is/ that
>      simple. All the possible complexity is in the stage of content
>      preparation for this commit.
> 
> I fail to see how this could be taken as saying that merge is just a
> commit. What I wanted to tell /you/, not /Alan/, is that there is no any
> hidden meta-information or other mysteries involved.

It was a long sub-thread, so I can understand how you could forget
what started it.  Let me remind you:

You:

> >> "Incorporates changes from the named commits (since the time their
> >> histories diverged from the current branch) into the current branch."

Me:

> > Good luck understanding this when learning what merge does in Git!
> > Starting from the "branch" thingy, which, as you will read everywhere
> > is just a pointer to the HEAD commit.  So what does it mean to
> > "incorporate changes in the current branch", if the branch is just a
> > pointer?

You:

> Yes, a pointer that moves to point to new commit automatically every
> time you commit on the branch. Incorporating changes means the same
> thing every time: commit. What's new or unusual about it?

Which I interpreted as you saying that a merge "means" ("is") "just a
commit", like every other commit.  That simplification seemed
unhelpful to me, because it ducks the real question of what happens
_during_ the merge, thus failing to answer that question, and instead
tells something like "what you are asking about has a very simple
answer", with the sub-text of "it's clear to everyone else".  Not
helpful, since the original question is left unanswered, and the OP is
now left to wonder what is it that he's missing that is clear to
everyone else.  IOW, you effectively answered a question of a newbie
with a riddle he is challenged to solve in order to prove that he is
as a smart as everybody else.  Does this strike you as a good
educational tactics in this case?

The fact that you replied to my messages is irrelevant, because this
is a public list with everyone reading it.  Discussion of a question
someone asked should certainly keep that someone in mind as being a
participant, albeit passive, in the discussion.  IOW, you are still
answering his question, even if replying to someone else.

Re: VC mode and git

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Sat, 04 Apr 2015 00:40:58 +0300
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > It's for Alan to say if it's more helpful than saying that a merge is
>> > "just a commit".
>> 
>> You are putting words into (my?) mouth. Nobody ever said that merge, the
>> operation, is just a commit, AFAIR. If you indeed meant me, that's what
>> I said:
>> 
>>      After true merge operation is finished, the only result of it is
>>      single commit appended to your current branch. Git /is/ that
>>      simple. All the possible complexity is in the stage of content
>>      preparation for this commit.
>> 
>> I fail to see how this could be taken as saying that merge is just a
>> commit. What I wanted to tell /you/, not /Alan/, is that there is no any
>> hidden meta-information or other mysteries involved.
>
> It was a long sub-thread, so I can understand how you could forget
> what started it.  Let me remind you:

I didn't forget it. Thanks for reminding anyway.

>
> You:
>
>> >> "Incorporates changes from the named commits (since the time their
>> >> histories diverged from the current branch) into the current branch."
>
> Me:
>
>> > Good luck understanding this when learning what merge does in Git!
>> > Starting from the "branch" thingy, which, as you will read everywhere
>> > is just a pointer to the HEAD commit.  So what does it mean to
>> > "incorporate changes in the current branch", if the branch is just a
>> > pointer?
>
> You:
>
>> Yes, a pointer that moves to point to new commit automatically every
>> time you commit on the branch. Incorporating changes means the same
>> thing every time: commit. What's new or unusual about it?
>
> Which I interpreted as you saying that a merge "means" ("is") "just a
> commit", like every other commit.

I tried to answer to the essence of your question to the best of my
knowledge of Git, just to later receive a blame in being only 90%
precise and in confusing people by saying that "merge is just commit",
that I never said.

I see I made a mistake trying to explain "git merge" manual to you,
thinking that I can do it better than the manual itself. I can't.

-- Sergey.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Teaching people new things often requires to start without rigor,
 > because otherwise you risk losing your audience.  Being
 > "technically correct", but confusing instead of explanatory is not
 > helpful.

Eli, you can't have it both ways.  When I use the shorthand common in
the git community and defined in the glossary, you excoriate me for
lack of rigor (in different but equivalent words).

 > >  > I don't even understand all this attitude: do we want Git newbies
 > >  > to become more proficient in using Git,
 > > 
 > > No, we want to support their efforts to become more productive using
 > > git.
 > 
 > Take it from a bystander: that's not how many messages in this thread
 > sound.

I agree.  You are quite correct that my phrasing was ambiguous; what I
meant by "we want to" is "in an ideal world this channel should be
focusing on ..., and avoiding flammable terminology".

 > > If they want to become proficient, I don't think there's any
 > > problem.  But Alan and Richard have expressed a rather strong desire
 > > to learn *nothing* about git
 > 
 > They didn't say that, please re-read their messages with open eyes.

OK, "nothing" is an unwarranted exaggeration.

 > What they did say is (a) they don't like investing an inordinate
 > amount of time and effort into studying Git, and (b) they would like
 > to keep their previous workflows as much as possible.

 > So if we want to help them become proficient, we need to go with them
 > and educate them while trying to honor these 2 desires.

My opinion that is that given what Richard and Alan apparently
consider to be "inordinate effort", we are unlikely to get to a point
where they know enough to make an informed decision.  Richard has yet
to say anything about git that doesn't involve exaggeration and
unnecessary pejoratives, and he's already gotten impatient enough to
force the issue by installing changes himself.

 > > yet insist on workflows that are infeasible if they remain ignorant
 > > of the details and options of git.
 > 
 > They are not infeasible.  They need only minor adaptations, see
 > GitQuickStartForEmacsDevs.  Those adaptations do not require any
 > details and options of git, just one new command.

If you say so.  I'll be interested to see what Richard installs.  I
wouldn't be surprised if it obviously fails to solve a few of the
several issues he has reported.

 > >  > If the former, why do we insist on being "technically correct"
 > >  > instead of explaining things in a way they could be understood?
 > > 
 > > Because it's entirely unclear to me what they are asking.
 > 
 > If you don't understand what they are asking, may I suggest that you
 > wait with your answers until you do, or ask someone else?

OK, I'll do that.  I've wasted far too much time on this thread.

 > > Richard is incapable of describing what he actually did, yet bridles
 > > at any suggestion that his actions were involved in messing things
 > > up (despite repeated admissions that he forgot this or that).
 > 
 > What he did became clear, even to me, after he showed the information
 > we requested.

It did?  It's not clear to me.  I still haven't seen an explanation of
how he ended up with a ton of modified files that he didn't touch, or
how he's going to get past that safely.  Nobody has mentioned him
doing a diff against a public reference commit that *should* be where
he started, in order to confirm that when he pushes he can succeed
(preferably without making the DAG too ugly, as well).

 > > "Complain to the writers of the Git glossary, then.  I just read what
 > > they say there."
 > 
 > They stated a fact.  They didn't tell when to use that shorthand.

You're missing the point.  *They used it themselves, and to interpret
what they wrote correctly, you need to admit that.*

 > > I wish you would write more posts like that.
 > 
 > Thanks, I'm trying.

You're welcome.  I hope you know there was absolutely zero sarcasm in
the compliment.  There is no question in my mind that you have been
the most level-headed contributor to this thread, although I disagree
(even now) with some of the positions you've taken.

Re: VC mode and git

[Steinar Bang]

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

> It did?  It's not clear to me.  I still haven't seen an explanation of
> how he ended up with a ton of modified files that he didn't touch,

He uses vc-dir.el which doesn't clearly distinguish between staged and
unstaged files, so it's quite possible that all but one of those files
(ChangeLog) are staged and ready to go, once he does a
 git commit

(I'm guessing here, but...)

> or how he's going to get past that safely.

I can't guarantee that he will get past that safely, but fixing the
conflict markers in ChangeLog, then
 git commit
 git push
(and probably)
 git pull
 git push

might get him there (if conflict in ChangeLog was all there was, the
"git commit" command will complain if there are more conflicted files).

> Nobody has mentioned him doing a diff against a public reference
> commit that *should* be where he started, in order to confirm that
> when he pushes he can succeed

Personally I never do that unless something fails, but then I mostly
work on feature branches when I work with others, so it's
 git checkout master
 git pull --ff-only
 git merge my-feature-branch
 git push

If the merge gets too messy or the push fails I can always go back to
the pre-merge conditons and start again (after doing the necessary
investigation).

> (preferably without making the DAG too ugly, as well).

The merge command is more robust than rebasing, so the emacs maintainers
have stated that they don't care about the ugliness of the DAG (which I
personally think is a wise decision).

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sat, 04 Apr 2015 07:41:53 +0900
> 
> Eli Zaretskii writes:
> 
>  > Teaching people new things often requires to start without rigor,
>  > because otherwise you risk losing your audience.  Being
>  > "technically correct", but confusing instead of explanatory is not
>  > helpful.
> 
> Eli, you can't have it both ways.  When I use the shorthand common in
> the git community and defined in the glossary, you excoriate me for
> lack of rigor (in different but equivalent words).

It's a judgment call.  In this case, I think using a shorthand only
confuses things, since "commit" and "commit object" are really very
different beasts.  By "lack of rigor" I meant omitting details of
secondary importance to the issue at hand; confusion between 2
entities is IMO not one of them, at least not in this case.

>  > What they did say is (a) they don't like investing an inordinate
>  > amount of time and effort into studying Git, and (b) they would like
>  > to keep their previous workflows as much as possible.
> 
>  > So if we want to help them become proficient, we need to go with them
>  > and educate them while trying to honor these 2 desires.
> 
> My opinion that is that given what Richard and Alan apparently
> consider to be "inordinate effort", we are unlikely to get to a point
> where they know enough to make an informed decision.

Could be.  In which case they will stop at the level of a "cookbook
user", who memorizes commands without deep understanding of their real
effect, and instead relies on some simplified mental models.  Not
ideal, I agree, but not bad, either.  And then it's just a
possibility; there's still hope they will move ahead at some point.

>  > What he did became clear, even to me, after he showed the information
>  > we requested.
> 
> It did?  It's not clear to me.  I still haven't seen an explanation of
> how he ended up with a ton of modified files that he didn't touch, or
> how he's going to get past that safely.

We've been through that: those are files from the merge already in the
index, ready to be committed when the conflicts are resolved.

>  > > I wish you would write more posts like that.
>  > 
>  > Thanks, I'm trying.
> 
> You're welcome.  I hope you know there was absolutely zero sarcasm in
> the compliment.

Nope, taken at face value.

> There is no question in my mind that you have been the most
> level-headed contributor to this thread, although I disagree (even
> now) with some of the positions you've taken.

Disagreements are expected, due to different perspectives and the fact
that I don't know about Git as much as you do.  But at least I
gathered enough stuff in this thread to fix GitQuickStartForEmacsDevs,
to which I'd appreciate comments from everyone who has a moment to
spare.

Re: VC mode and git

[martin rudalics]

 > I gathered enough stuff in this thread to fix GitQuickStartForEmacsDevs,
 > to which I'd appreciate comments from everyone who has a moment to
 > spare.

Thanks.  Please consider the following:

(1) Say that a pull is a fetch plus a merge and what these do.

(2) Distinguish the two ways a merge can fail: The one where git refuses
     to merge because it would overwrite changes and the second one where
     it detects conflicts.  And how to deal with them.

(3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
     People will find them in the manuals and tutorials and we should at
     least tell them why the method we propose here is sufficient or
     better.

martin

Re: VC mode and git

[Eli Zaretskii]

> Date: Sat, 04 Apr 2015 10:30:13 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: sorganov@gmail.com, emacs-devel@gnu.org
> 
>  > I gathered enough stuff in this thread to fix GitQuickStartForEmacsDevs,
>  > to which I'd appreciate comments from everyone who has a moment to
>  > spare.
> 
> Thanks.  Please consider the following:

Thank you for your comments.

> (1) Say that a pull is a fetch plus a merge and what these do.

Why would that matter for people who just want to copy their mental
models from CVS to Git with minimal changes?

Every VCS does some kind of a fetch and a merge when it pulls.  Git
and AFAIK also Mercurial are unique in that they let the user invoke
each of these separately.  But IMO that only matters if we then
explain how to use these separate steps to the user's benefit, and I
don't see how doing so is possible, let alone necessary, within a
CVS-like workflow.

Maybe I'm missing something, so please elaborate why you thought this
to be beneficial.

> (2) Distinguish the two ways a merge can fail: The one where git refuses
>      to merge because it would overwrite changes and the second one where
>      it detects conflicts.  And how to deal with them.

I think the way to deal with both is the same, and that's what the
instructions describe.  Again, maybe I'm mistaken, but then please
show an example where the instructions would fail in one of those
cases.

The intent is to try to preserve the CVS mental models, so the
description generally follows what one would do with conflicts created
by "cvs update", the only changes being those that are strictly
necessary with Git.

> (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
>      People will find them in the manuals and tutorials and we should at
>      least tell them why the method we propose here is sufficient or
>      better.

The fact that these are mentioned in the manuals is not a good
guidance for mentioning them, since the manuals mention a lot more
than just these two.

Stashing was not mentioned there to begin with; it isn't even
mentioned in the more advanced GitForEmacsDevs page, nor was its bzr
equivalent ever mentioned in the instructions we wrote for Bazaar.
CVS has no equivalent for stashing.  So I'm not sure why you think it
should be mentioned.  Perhaps the reason is that you yourself use it a
lot.  Once again, please elaborate.

Rebasing is a tricky issue.  Richard asked (off-line) for an
explanation of what it is, so the notion itself is not immediately
clear to everyone, and would need to be explained.  Next, we decided
not to recommend rebasing (because we merge from the release branch,
and generally prefer merge-based workflows), so if we want the readers
of those instructions to use rebase, we must describe it as a marginal
feature for rare situations.  Is it worth that, and if so, why?

It is possible that both of these issues could be explained in a
separate section near the end of the page, as some additional stuff
worth learning.  But then (a) we should think carefully how we would
like to categorize them, and (b) there's a real danger people won't
read something that has no direct bearing on the otherwise
cookbook-like approach of the instructions.

Those are my thoughts, feel free to point out where I'm wrong.

Thanks.

Re: VC mode and git

[martin rudalics]

 >> (1) Say that a pull is a fetch plus a merge and what these do.
 >
 > Why would that matter for people who just want to copy their mental
 > models from CVS to Git with minimal changes?

According to this thread there are people who recommend to never pull
but always do fetch and merge instead.  We should say whether they are
right.  And we probably should tell what happened after git pull with
the following


error: Your local changes to the following files would be overwritten by merge:
...
Please, commit your changes or stash them before you can merge.
Aborting


AFAICT this signlas a succeeding fetch and a failing merge.

 > Every VCS does some kind of a fetch and a merge when it pulls.  Git
 > and AFAIK also Mercurial are unique in that they let the user invoke
 > each of these separately.  But IMO that only matters if we then
 > explain how to use these separate steps to the user's benefit, and I
 > don't see how doing so is possible, let alone necessary, within a
 > CVS-like workflow.

IIUC git's pull is not atomic.  When the merge fails with a message like
the above I have no idea in what state my copy of a repository is in.
Well, I wouldn't know even without that message ...

 > Maybe I'm missing something, so please elaborate why you thought this
 > to be beneficial.
 >
 >> (2) Distinguish the two ways a merge can fail: The one where git refuses
 >>       to merge because it would overwrite changes and the second one where
 >>       it detects conflicts.  And how to deal with them.
 >
 > I think the way to deal with both is the same,

In the one case I get the message cited above.  In the other case I get
conflicts and git asks me to resolve them.

 > and that's what the
 > instructions describe.  Again, maybe I'm mistaken, but then please
 > show an example where the instructions would fail in one of those
 > cases.
 >
 > The intent is to try to preserve the CVS mental models, so the
 > description generally follows what one would do with conflicts created
 > by "cvs update", the only changes being those that are strictly
 > necessary with Git.

Now suppose that, in reaction to the message above I do

git commit -a
git pull

and now am told to resolve my conflicts.  I do that via smerge-mode,
save the file(s) which had the conflict(s) and do

git commit

as recommended.  I tried that just now with a conflict in Changelog.
After this git told me that


On branch master
Your branch and 'origin/master' have diverged,
and have 2 and 74 different commits each, respectively.
   (use "git pull" to merge the remote branch into yours)

All conflicts fixed but you are still merging.
   (use "git commit" to conclude merge)


and, after the recommended git pull


CONFLICT (content): Merge conflict in lisp/ChangeLog
Automatic merge failed; fix conflicts and then commit the result.


just that I did not find any conflicts at this stage.  So I practically
ended up in an infinite loop which I was able to break only via a hard
reset.  I suppose this is similar if not identic to Richard's original
problem which is apparently very easily reproducible here.

 >> (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
 >>       People will find them in the manuals and tutorials and we should at
 >>       least tell them why the method we propose here is sufficient or
 >>       better.
 >
 > The fact that these are mentioned in the manuals is not a good
 > guidance for mentioning them, since the manuals mention a lot more
 > than just these two.
 >
 > Stashing was not mentioned there to begin with; it isn't even
 > mentioned in the more advanced GitForEmacsDevs page, nor was its bzr
 > equivalent ever mentioned in the instructions we wrote for Bazaar.
 > CVS has no equivalent for stashing.  So I'm not sure why you think it
 > should be mentioned.  Perhaps the reason is that you yourself use it a
 > lot.  Once again, please elaborate.

Stashing is offered in the first git message cited above.  If it's bad
we should tell people why.  OTOH I never had a problem with stashing and
in particular it never got me into the loop I mentioned later.

 > Rebasing is a tricky issue.  Richard asked (off-line) for an
 > explanation of what it is, so the notion itself is not immediately
 > clear to everyone, and would need to be explained.  Next, we decided
 > not to recommend rebasing (because we merge from the release branch,
 > and generally prefer merge-based workflows), so if we want the readers
 > of those instructions to use rebase, we must describe it as a marginal
 > feature for rare situations.  Is it worth that, and if so, why?

I never used rebasing and can't tell whether it's of any use.  But it is
propsed in GitForEmacsDevs and it's very confusing if we have two texts
with a similar purpose proposing different things.

 > It is possible that both of these issues could be explained in a
 > separate section near the end of the page, as some additional stuff
 > worth learning.  But then (a) we should think carefully how we would
 > like to categorize them, and (b) there's a real danger people won't
 > read something that has no direct bearing on the otherwise
 > cookbook-like approach of the instructions.

If the cookbook instructions are fail-safe there's no problem.  I'm
afraid they aren't.

 > Those are my thoughts, feel free to point out where I'm wrong.
 >
 > Thanks.

Thank you for working on this.  I'm afraid it's no real fun.

martin

Re: VC mode and git

[Eli Zaretskii]

> Date: Sat, 04 Apr 2015 17:59:45 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen@xemacs.org, sorganov@gmail.com, emacs-devel@gnu.org
> 
>  >> (1) Say that a pull is a fetch plus a merge and what these do.
>  >
>  > Why would that matter for people who just want to copy their mental
>  > models from CVS to Git with minimal changes?
> 
> According to this thread there are people who recommend to never pull
> but always do fetch and merge instead.  We should say whether they are
> right.

I don't think such a discussion belongs to that page.  Those are
cookbook style instructions, so discussing things not directly
referenced in the instructions should be avoided.

> And we probably should tell what happened after git pull with
> the following
> 
> error: Your local changes to the following files would be overwritten by merge:
> ...
> Please, commit your changes or stash them before you can merge.
> Aborting
> 
> 
> AFAICT this signlas a succeeding fetch and a failing merge.

Yes, and I already added that, please take another look.

>  > Every VCS does some kind of a fetch and a merge when it pulls.  Git
>  > and AFAIK also Mercurial are unique in that they let the user invoke
>  > each of these separately.  But IMO that only matters if we then
>  > explain how to use these separate steps to the user's benefit, and I
>  > don't see how doing so is possible, let alone necessary, within a
>  > CVS-like workflow.
> 
> IIUC git's pull is not atomic.  When the merge fails with a message like
> the above I have no idea in what state my copy of a repository is in.

I tried to explain that in the latest changes.

>  >> (2) Distinguish the two ways a merge can fail: The one where git refuses
>  >>       to merge because it would overwrite changes and the second one where
>  >>       it detects conflicts.  And how to deal with them.
>  >
>  > I think the way to deal with both is the same,
> 
> In the one case I get the message cited above.  In the other case I get
> conflicts and git asks me to resolve them.

Right, so they are both described now.

>  > The intent is to try to preserve the CVS mental models, so the
>  > description generally follows what one would do with conflicts created
>  > by "cvs update", the only changes being those that are strictly
>  > necessary with Git.
> 
> Now suppose that, in reaction to the message above I do
> 
> git commit -a
> git pull
> 
> and now am told to resolve my conflicts.  I do that via smerge-mode,
> save the file(s) which had the conflict(s) and do
> 
> git commit
> 
> as recommended.  I tried that just now with a conflict in Changelog.
> After this git told me that
> 
> 
> On branch master
> Your branch and 'origin/master' have diverged,
> and have 2 and 74 different commits each, respectively.
>    (use "git pull" to merge the remote branch into yours)
> 
> All conflicts fixed but you are still merging.
>    (use "git commit" to conclude merge)
> 
> 
> and, after the recommended git pull
> 
> 
> CONFLICT (content): Merge conflict in lisp/ChangeLog
> Automatic merge failed; fix conflicts and then commit the result.
> 
> 
> just that I did not find any conflicts at this stage.  So I practically
> ended up in an infinite loop which I was able to break only via a hard
> reset.

I don't see this infinite loop (I tried with 2 local repositories
instead).  After the second commit, a pull says "already up-to-date".
Not sure why the difference.

>  >> (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
>  >>       People will find them in the manuals and tutorials and we should at
>  >>       least tell them why the method we propose here is sufficient or
>  >>       better.
>  >
>  > The fact that these are mentioned in the manuals is not a good
>  > guidance for mentioning them, since the manuals mention a lot more
>  > than just these two.
>  >
>  > Stashing was not mentioned there to begin with; it isn't even
>  > mentioned in the more advanced GitForEmacsDevs page, nor was its bzr
>  > equivalent ever mentioned in the instructions we wrote for Bazaar.
>  > CVS has no equivalent for stashing.  So I'm not sure why you think it
>  > should be mentioned.  Perhaps the reason is that you yourself use it a
>  > lot.  Once again, please elaborate.
> 
> Stashing is offered in the first git message cited above.  If it's bad
> we should tell people why.  OTOH I never had a problem with stashing and
> in particular it never got me into the loop I mentioned later.

I'd like to avoid additional commands, if possible.  So I describe how
to solve the conflicts by committing local changes in the files that
prevented the merge.

>  > Rebasing is a tricky issue.  Richard asked (off-line) for an
>  > explanation of what it is, so the notion itself is not immediately
>  > clear to everyone, and would need to be explained.  Next, we decided
>  > not to recommend rebasing (because we merge from the release branch,
>  > and generally prefer merge-based workflows), so if we want the readers
>  > of those instructions to use rebase, we must describe it as a marginal
>  > feature for rare situations.  Is it worth that, and if so, why?
> 
> I never used rebasing and can't tell whether it's of any use.  But it is
> propsed in GitForEmacsDevs and it's very confusing if we have two texts
> with a similar purpose proposing different things.

I think we should remove rebasing from that page as well.  It is there
because we originally thought "pull --rebase" was a good idea.  That
was before we understood the damage it could cause in an otherwise
merge-based workflow, including what gitmerge.el does when it merges
from the release branch.

> Thank you for working on this.  I'm afraid it's no real fun.

I don't play with Git for fun.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > And we probably should tell what happened after git pull with
 > > the following
 > > 
 > > error: Your local changes to the following files would be
 > > overwritten by merge:
 > > ...
 > > Please, commit your changes or stash them before you can merge.
 > > Aborting
 > > 
 > > 
 > > AFAICT this signlas a succeeding fetch and a failing merge.
 > 
 > Yes, and I already added that, please take another look.

I looked at the current version.  If the uncommitted files were
inadvertant (typical beginner mistake), your advice to commit, pull
again, and fix the conflicts is appropriate.  But this doesn't work
for Richard, who deliberately leaves some changes uncommitted.

I see two ways to deal with this.  Ignore Richard (and Alan, at least)
for the purpose of GitQuickStartForEmacsDevs, and preface the
paragraph below "Conflicts in uncommitted changes" that starts "To fix
this" with "If you accidentally forgot to commit these changes, you
can fix this ...".  Alternatively, recommend stash-pull-stashpop,
but Alan at least objects to the extra commands.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: martin rudalics <rudalics@gmx.at>,
>     sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 05 Apr 2015 07:58:05 +0900
> 
> I looked at the current version.

Thanks.

> If the uncommitted files were inadvertant (typical beginner
> mistake), your advice to commit, pull again, and fix the conflicts
> is appropriate.  But this doesn't work for Richard, who deliberately
> leaves some changes uncommitted.

Why doesn't it work?  Because changes he didn't want to commit just
yet will end up committed?  I think this is a small price to pay for
avoiding to learn about stashing, and for having what is mostly the
same workflow he and others had with CVS.

Richard, is this aspect going to be a problem for you?

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > If the uncommitted files were inadvertant (typical beginner
 > > mistake), your advice to commit, pull again, and fix the conflicts
 > > is appropriate.  But this doesn't work for Richard, who deliberately
 > > leaves some changes uncommitted.
 > 
 > Why doesn't it work?  Because changes he didn't want to commit just
 > yet will end up committed?  I think this is a small price to pay for
 > avoiding to learn about stashing, and for having what is mostly the
 > same workflow he and others had with CVS.

Richard will speak for himself about the size of the price, but I
suspect he doesn't need to pay it at all in the current case (see my
other post, specifically about "git commit --include" -- and now you
have a hint as to why manipulating the "index" is useful[1]).

He will need to do something else in the case that he runs into the
"will overwrite your changes" message.  However, since he seems
comfortable with the "don't touch ChangeLogs until after you pull"
workflow, I'm guessing the probability that he'll run into something
really ugly is unlikely.

True, this time he actually committed "offline" twice because of
missing pushes which could cause issues (maybe those commits are the
missing logs?), but if he finds a good way to automate those, he
should be in pretty good shape.

Footnotes: 
[1]  Unfortunately it still doesn't help with the "atomic check-in"
issue but perhaps that can be solved to Richard's satisfaction with
the proposed post-commit hook.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Richard Stallman <rms@gnu.org>,
>     rudalics@gmx.at,
>     sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 05 Apr 2015 17:44:49 +0900
> 
> Eli Zaretskii writes:
> 
>  > > If the uncommitted files were inadvertant (typical beginner
>  > > mistake), your advice to commit, pull again, and fix the conflicts
>  > > is appropriate.  But this doesn't work for Richard, who deliberately
>  > > leaves some changes uncommitted.
>  > 
>  > Why doesn't it work?  Because changes he didn't want to commit just
>  > yet will end up committed?  I think this is a small price to pay for
>  > avoiding to learn about stashing, and for having what is mostly the
>  > same workflow he and others had with CVS.
> 
> Richard will speak for himself about the size of the price, but I
> suspect he doesn't need to pay it at all in the current case (see my
> other post, specifically about "git commit --include"

Maybe I'm missing something, but I don't understand how --include
could have helped in this case.  The man page says:

  --include 
    Before making a commit out of staged contents so far, stage the
    contents of paths given on the command line as well.

So AFAIU "git commit --include FILE" is equivalent to these two
commands:

   git add FILE
   git commit

If this is true, then this will commit both the file with conflicting
uncommitted changes and the rest of the stuff fetched from upstream.
So how is it different from what I described on the Wiki?  The result
is the same: the changes that were left uncommitted because they are
"not ready" will end up committed.  My procedure is IMO better in that
it doesn't require any non-default switches to commands.

> He will need to do something else in the case that he runs into the
> "will overwrite your changes" message.

But that's exactly the situation I thought we were discussing:
uncommitted changes that conflict with changes upstream.  So now I'm
confused about the use case you referred to above.

> However, since he seems comfortable with the "don't touch ChangeLogs
> until after you pull" workflow, I'm guessing the probability that
> he'll run into something really ugly is unlikely.

Agreed, and that's why I think stash could be avoided.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Richard will speak for himself about the size of the price, but I
 > > suspect he doesn't need to pay it at all in the current case (see my
 > > other post, specifically about "git commit --include"
 > 
 > Maybe I'm missing something, but I don't understand how --include
 > could have helped in this case.

Well, as you wrote elsewhere, if he's using VC there's a save-hook (in
smerge-mode?) that automatically adds the file whose conflicts are
fixed, and --include is a no-op.

 > So AFAIU "git commit --include FILE" is equivalent to these two
 > commands:
 > 
 >    git add FILE
 >    git commit

Yes.  That's how I understand the man page, too, and it corresponds to
the experiments I did.

 > If this is true, then this will commit both the file with conflicting
 > uncommitted changes and the rest of the stuff fetched from
 > upstream.

True.

 > So how is it different from what I described on the Wiki?  The result
 > is the same: the changes that were left uncommitted because they are
 > "not ready" will end up committed.  My procedure is IMO better in that
 > it doesn't require any non-default switches to commands.

Probably it isn't any different.  It's just that I was unclear on what
was going to be committed.

In fact, as long as the developer restricts himself to committing
merged files (including but not limited to those with resolved
conflicts) it's possible it's exacty what Richard wants: leave the
files containing changes needing further testing uncommitted.  But:

 > > He will need to do something else in the case that he runs into the
 > > "will overwrite your changes" message.
 > 
 > But that's exactly the situation I thought we were discussing:
 > uncommitted changes that conflict with changes upstream.  So now I'm
 > confused about the use case you referred to above.

But I'm trying to look at this from Richard's point of view int he
current situation.  As far as I can tell that's not the case in
Richard's current workspace, except for lisp/ChangeLog, and that's
already a special case in his workflow since he didn't write it up
until after he did the pull (but did do the code changes before the
pull).  It's also a special case in Emacs, since the ChangeLog update
actually belongs to the merge in some sense.

 > > However, since he seems comfortable with the "don't touch
 > > ChangeLogs until after you pull" workflow, I'm guessing the
 > > probability that he'll run into something really ugly is
 > > unlikely.
 > 
 > Agreed, and that's why I think stash could be avoided.

Unfortunately, there's the case that hasn't been mentioned explicitly,
which is where he has a code change that touches multiple files, some
of which are conflicted and some of which are not.  The conflicted
files have to be committed to keep git happy unless you do some
"advanced" stuff, such as stash.  I don't think you really want
Richard's changes mixed with merge changes.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rudalics@gmx.at,
>     sorganov@gmail.com,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Mon, 06 Apr 2015 03:45:32 +0900
> 
> Unfortunately, there's the case that hasn't been mentioned explicitly,
> which is where he has a code change that touches multiple files, some
> of which are conflicted and some of which are not.  The conflicted
> files have to be committed to keep git happy unless you do some
> "advanced" stuff, such as stash.  I don't think you really want
> Richard's changes mixed with merge changes.

Yes, in that case all the uncommitted changes belonging to the same
changeset as the conflicted changes will have to be committed as well.

Re: VC mode and git

[martin rudalics]

A few further comments on the last version of GitQuickStartForEmacsDevs:

   Optionally, before doing a commit, you can do git status and git diff to
   view the changes which will be committed by git commit -a (with no
   filename arguments).

Couldn't we formulate this in a slightly more appealing way?  Somehow in
the sense of "in order to avoid commiting things you probably do not
want to commit" do a 'git status' which will tell you which files are
affected by the commit or 'git diff' which will give you the details.


   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.

And here I would try to tell that the outputs of plain 'git diff' and
'git status' are different from their outputs before the commit.  When I
noticed that for the first time I was confused.


   To re-do the commit from scratch, use git reset HEAD^, then fix
   whatever needs fixing, and commit again.

Maybe we should reassure readers here that their changes are not lost
when they do that.


   error: Your local changes to the following files would be overwritten by merge:
          file1
   Please, commit your changes or stash them before you can merge.
   Aborting

   To fix this, commit the offending files with

Please tell readers here that git does not even try to check whether
their changes would conflict with changes in the upstream repository.
Otherwise, the cited section will confuse readers who expect conflicts
exclusively due to the earlier ...

   This merge could fail due to conflicts between your changes and
   changes by others in the same portions of the same files.

... in particular the "in the same portions" part.  At least I was
initially stupefied by this when it happened the first time.


   In addition, saving any file whose conflicts were completely resolved
   (i.e., no conflict markers remain in it) invokes the git add command
   on that file, which prepares the file for merging and committing.

Are we really 100% sure that 'git add' gets executed with all reasonable
user customizations?  Shouldn't we tell here how our reader can check
whether the 'git add' was really performed?


    (It is recommended to do a git status before a commit without
    filename arguments to check for inadvertent changes that would be
    committed.)

Doesn't this come now a bit late in the text given you latest changes?

martin

Re: VC mode and git

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 16:58:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
> A few further comments on the last version of GitQuickStartForEmacsDevs:

Thanks.

>    Optionally, before doing a commit, you can do git status and git diff to
>    view the changes which will be committed by git commit -a (with no
>    filename arguments).
> 
> Couldn't we formulate this in a slightly more appealing way?

I tried to do that, please take another look.

>    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.
> 
> And here I would try to tell that the outputs of plain 'git diff' and
> 'git status' are different from their outputs before the commit.

In the new version, "git diff" is no longer mentioned, and "git
status" was never mentioned before, so do you still think we need to
say something about that?

>    To re-do the commit from scratch, use git reset HEAD^, then fix
>    whatever needs fixing, and commit again.
> 
> Maybe we should reassure readers here that their changes are not lost
> when they do that.

Done.

>    error: Your local changes to the following files would be overwritten by merge:
>           file1
>    Please, commit your changes or stash them before you can merge.
>    Aborting
> 
>    To fix this, commit the offending files with
> 
> Please tell readers here that git does not even try to check whether
> their changes would conflict with changes in the upstream repository.
> Otherwise, the cited section will confuse readers who expect conflicts
> exclusively due to the earlier ...
> 
>    This merge could fail due to conflicts between your changes and
>    changes by others in the same portions of the same files.
> 
> ... in particular the "in the same portions" part.  At least I was
> initially stupefied by this when it happened the first time.

But the full text says this:

  This merge could fail due to conflicts between your changes and
  changes by others in the same portions of the same files. The
  conflicts could be in changes you have already committed locally, or
  in uncommitted changes.

The second sentence refers to uncommitted changes.  Is it really
important to tell that in this case Git will not even start a merge?
How will that help the reader/user when they are in this situation?

>    In addition, saving any file whose conflicts were completely resolved
>    (i.e., no conflict markers remain in it) invokes the git add command
>    on that file, which prepares the file for merging and committing.
> 
> Are we really 100% sure that 'git add' gets executed with all reasonable
> user customizations?

As long as they didn't remove the Git back-end from the list, yes.

> Shouldn't we tell here how our reader can check whether the 'git
> add' was really performed?

Sounds excessive to me.

>     (It is recommended to do a git status before a commit without
>     filename arguments to check for inadvertent changes that would be
>     committed.)
> 
> Doesn't this come now a bit late in the text given you latest changes?

Deleted.

Thanks.

Re: VC mode and git

[martin rudalics]

 >>     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.
 >>
 >> And here I would try to tell that the outputs of plain 'git diff' and
 >> 'git status' are different from their outputs before the commit.
 >
 > In the new version, "git diff" is no longer mentioned,

Hmm...  I still see

   We recommend invoking git status and git diff to view the changes
   which will be committed, before invoking git commit -a.

 > and "git
 > status" was never mentioned before, so do you still think we need to
 > say something about that?

Maybe it's only me.  git adopts a principle epitomized by, for example,

    Typically you would want comparison with the latest commit, so if you
    do not give <commit>, it defaults to HEAD.

which is completely unintuitive IMO.  Why should the output of two "git
diff"s differ just because I committed something in between?

 > But the full text says this:
 >
 >    This merge could fail due to conflicts between your changes and
 >    changes by others in the same portions of the same files. The
 >    conflicts could be in changes you have already committed locally, or
 >    in uncommitted changes.
 >
 > The second sentence refers to uncommitted changes.  Is it really
 > important to tell that in this case Git will not even start a merge?
 > How will that help the reader/user when they are in this situation?

Agreed.  One nitpick still:

   Now you have conflicts due to local committed changes, described below.

I would say

   Now you may have conflicts due to local committed changes, described below.

instead.

 >> Are we really 100% sure that 'git add' gets executed with all reasonable
 >> user customizations?
 >
 > As long as they didn't remove the Git back-end from the list, yes.

It wasn't entirely clear for me but I take your word for it.

Thanks again for taking care of this, martin

Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 08 Apr 2015 09:05:05 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 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. If you only
>  >>     have one local commit you want to push, just git show is enough.
>  >>
>  >> And here I would try to tell that the outputs of plain 'git diff' and
>  >> 'git status' are different from their outputs before the commit.
>  >
>  > In the new version, "git diff" is no longer mentioned,
> 
> Hmm...  I still see
> 
>    We recommend invoking git status and git diff to view the changes
>    which will be committed, before invoking git commit -a.

Yes, but in that place it's TRT.  This is only suggested before the
commit, with the explicit purpose of showing what's changed and what
will be committed, so why do we have to explain how the output after
the commit is going to be different?

>  > and "git
>  > status" was never mentioned before, so do you still think we need to
>  > say something about that?
> 
> Maybe it's only me.  git adopts a principle epitomized by, for example,
> 
>     Typically you would want comparison with the latest commit, so if you
>     do not give <commit>, it defaults to HEAD.
> 
> which is completely unintuitive IMO.  Why should the output of two "git
> diff"s differ just because I committed something in between?

We no longer suggest using diff except _before_ a commit, precisely
because of this issue.

>  > But the full text says this:
>  >
>  >    This merge could fail due to conflicts between your changes and
>  >    changes by others in the same portions of the same files. The
>  >    conflicts could be in changes you have already committed locally, or
>  >    in uncommitted changes.
>  >
>  > The second sentence refers to uncommitted changes.  Is it really
>  > important to tell that in this case Git will not even start a merge?
>  > How will that help the reader/user when they are in this situation?
> 
> Agreed.  One nitpick still:
> 
>    Now you have conflicts due to local committed changes, described below.
> 
> I would say
> 
>    Now you may have conflicts due to local committed changes, described below.
> 
> instead.

Done.

Re: VC mode and git

[Steinar Bang]

>>>>> martin rudalics <rudalics@gmx.at>:

> error: Your local changes to the following files would be overwritten by merge:
> ...
> Please, commit your changes or stash them before you can merge.
> Aborting


> AFAICT this signlas a succeeding fetch and a failing merge.

Not exactly, it signals a succeding fetch, and no merge done

> IIUC git's pull is not atomic.  When the merge fails with a message like
> the above I have no idea in what state my copy of a repository is in.

It is in the same state it was as before you did the pull.

> Well, I wouldn't know even without that message ...
[snip!]
> In the one case I get the message cited above.  In the other case I get
> conflicts and git asks me to resolve them.

Now, _if_ you have modified uncommitted changes, _and_ get conflicts,
then things get slightly worse.

The conflicts will not be in any of your locally modified files, because
those haven't been touched by the merge (if they were, the merge
wouldn't have started).

> Now suppose that, in reaction to the message above I do

> git commit -a
> git pull

> and now am told to resolve my conflicts.  I do that via smerge-mode,
> save the file(s) which had the conflict(s) and do

> git commit

> as recommended.  I tried that just now with a conflict in Changelog.
> After this git told me that

> On branch master
> Your branch and 'origin/master' have diverged,
> and have 2 and 74 different commits each, respectively.
>   (use "git pull" to merge the remote branch into yours)

> All conflicts fixed but you are still merging.
>   (use "git commit" to conclude merge)

This message means your merge wasn't completed.  What did
 git commit
say?  Were there more files than the ChangeLog that needed merging?

Didn't smerge-mode automatically stage the conflict-fixed file for
commit?  (didn't you remove all conflict markers?)

> and, after the recommended git pull

> CONFLICT (content): Merge conflict in lisp/ChangeLog
> Automatic merge failed; fix conflicts and then commit the result.

> just that I did not find any conflicts at this stage.

You mean no conflict markers in the ChangeLog?  Did you try diffing
ChangeLog against orgin/master to see if there were changes and if they
looked sensible?

Did you try staging ChangeLog manually for commit?
 git add ChangeLog

> So I practically ended up in an infinite loop which I was able to
> break only via a hard reset.  I suppose this is similar if not identic
> to Richard's original problem which is apparently very easily
> reproducible here.

A hard reset sounded a bit drastic.

Did you have changes in the ChangeLog that were yours? Or was the
conflict purely caused by git?

> Stashing is offered in the first git message cited above.  If it's bad
> we should tell people why.  OTOH I never had a problem with stashing
> and in particular it never got me into the loop I mentioned later.

The reason to stay away from stash from this workflow, is that it is yet
another concept to relate to.

The fact that "git stash pop" can result in a conflict that needs to be
resolved and seemingly needs to be committed (it doesn't), is a
complicating factor for a simple CVS-like workflow.

Re: VC mode and git

[Stephen J. Turnbull]

Steinar Bang writes:

 > > IIUC git's pull is not atomic.  When the merge fails with a message like
 > > the above I have no idea in what state my copy of a repository is in.
 > 
 > It is in the same state it was as before you did the pull.

No, in the repo origin/master has been updated.  It's true that master
has not been updated and the working tree is untouched.  Of course
this difference is probably not apparent to most users.

Re: VC mode and git

[Steinar Bang]

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

> Steinar Bang writes:
>> > IIUC git's pull is not atomic.  When the merge fails with a message like
>> > the above I have no idea in what state my copy of a repository is in.
>> 
>> It is in the same state it was as before you did the pull.

> No, in the repo origin/master has been updated.

You're right.  Sorry, I didn't read the statement closely enough.

> It's true that master has not been updated and the working tree is
> untouched.

Yes, that's what I meant.

> Of course this difference is probably not apparent to most users.

The important thing is that updating origin/master from upstream is an
absolutely safe thing to do, wrt. to the local changes (nothing is
overwritten, nothing is conflicted, no changes are lost).

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > (1) Say that a pull is a fetch plus a merge and what these do.
 > 
 > Why would that matter for people who just want to copy their mental
 > models from CVS to Git with minimal changes?

I'm with Eli on this one; there's no need to explain, and people who
encounter different workflows elsewhere are welcome to ask here.

 > > (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
 > >      People will find them in the manuals and tutorials and we should at
 > >      least tell them why the method we propose here is sufficient or
 > >      better.
 > 
 > The fact that these are mentioned in the manuals is not a good
 > guidance for mentioning them, since the manuals mention a lot more
 > than just these two.

I'm with Eli on this.  Richard is a special case because of his need
for long intervals between pulls, and his preference for leaving
changes uncommitted for long intervals as well.  I'm not really sure
what to recommend for people who like to work that way.  So stash
isn't a real need in the base workflow IMO, but I'm not all that sure.

Rebase is documented with warnings almost everywhere.  Nobody should
be surprised it's not in the base workflow.  I am quite sure there's
no need to mention it here.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > It did?  It's not clear to me.  I still haven't seen an explanation of
 > > how he ended up with a ton of modified files that he didn't touch, or
 > > how he's going to get past that safely.
 > 
 > We've been through that: those are files from the merge already in the
 > index, ready to be committed when the conflicts are resolved.

I've been through that too, I tried to reproduce and failed.  My
understanding was that Richard had edited and had uncommitted changes
*before* "the" pull.  Both in theory and by experiment, there should
be no merge in the index.  The merge doesn't even get started if
conflicts are expected and there are uncommitted changes.  The reflog
also didn't show any pull since the commits Richard did make.

So your hypothesis is something like

1. Richard cloned the repo.
2. He did the edit-commit cycle three times (according to reflog).
3. At some point, he did a couple of branch switches (according to
   reflog; result was a no-op).
3. He pulled (when fully committed), and got a conflict in
   lisp/Changelog during the merge phase (so no reflog entry).
4. He hasn't edited since (except maybe the ChangeLog)
5. Maybe he has pulled since, but that would have no visible changes
   (there would be a fetch to origin/master, but no merge at all).

?

In that case, yes, commit-pull[-fix-commit]?-push should do the
trick.  I would recommend a diff (or diffstat) against origin/master
to make sure he recognizes all the changes as his own before pushing.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 05 Apr 2015 07:01:05 +0900
> 
> Eli Zaretskii writes:
> 
>  > > It did?  It's not clear to me.  I still haven't seen an explanation of
>  > > how he ended up with a ton of modified files that he didn't touch, or
>  > > how he's going to get past that safely.
>  > 
>  > We've been through that: those are files from the merge already in the
>  > index, ready to be committed when the conflicts are resolved.
> 
> I've been through that too, I tried to reproduce and failed.  My
> understanding was that Richard had edited and had uncommitted changes
> *before* "the" pull.

I'm not sure this is what happened; I think he had _committed_ changes
that conflicted.

Let's reiterate what Richard described in his original message:

    I committed some changes using C-x v v in vc-dir.
    Something went wrong with lisp/ChangeLog.

    It appears that my change log entries went into an old version of that
    file; I don't know why this happened, since I wrote them today after
    doing 'git pull'.

    After this, I did 'git pull' again, and it said there was a merge
    conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
    the file.  It said, "fix conflicts and then commit the result."

    I edited lisp/ChangeLog and tried to commit it with C-x v v.
    That gave me the error message

      fatal: cannot do a partial commit during a merge.

    I am now stuck.  I don't know what a "merge" is; it is certainly
    nothing I asked to do.

Note the "merge conflict" part and the error message Richard cites:
"fix conflicts and then commit the result."  This is a message
displayed by Git when you have a conflict in _committed_ changes, and
the merge fails half-way through.  Error messages about conflicts in
uncommitted changes are different

The second error message, viz.:

  fatal: cannot do a partial commit during a merge.

is because "C-x v v" invokes "git commit --only lisp/ChangeLog", which
AFAIR always fails in this situation, for the reason hinted by the
error message.

The result of "git status -s" is consistent with the hypothesis that
the only problem during pull was conflicting changes in
lisp/ChangeLog.  The uncommitted changes, if there were present,
didn't generate conflicts, and so were silently kept by the merge.

> So your hypothesis is something like
> 
> 1. Richard cloned the repo.
> 2. He did the edit-commit cycle three times (according to reflog).
> 3. At some point, he did a couple of branch switches (according to
>    reflog; result was a no-op).
> 3. He pulled (when fully committed), and got a conflict in
>    lisp/Changelog during the merge phase (so no reflog entry).
> 4. He hasn't edited since (except maybe the ChangeLog)
> 5. Maybe he has pulled since, but that would have no visible changes
>    (there would be a fetch to origin/master, but no merge at all).
> 
> ?

Yes, something like that.  In fact, I think the root cause of the
original problem was that "C-x v v", which tried to commit a single
file in the middle of a merge.  Instead, the correct action is either
'v' from vc-dir or "git commit" from the shell prompt.

It would be good if "C-x v v" tried to support this situation better.
I hope Eric Raymond is reading this.

> In that case, yes, commit-pull[-fix-commit]?-push should do the
> trick.  I would recommend a diff (or diffstat) against origin/master
> to make sure he recognizes all the changes as his own before pushing.

Yes, I agree. "git diff origin/master" is a good idea.

Re: VC mode and git

[Stephen J. Turnbull]

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

 > > I've been through that too, I tried to reproduce and failed.  My
 > > understanding was that Richard had edited and had uncommitted changes
 > > *before* "the" pull.
 > 
 > I'm not sure this is what happened; I think he had _committed_ changes
 > that conflicted.

No, I am sure that at some point he pulled when fully committed, from
trying the experiments.

 > Let's reiterate what Richard described in his original message:

Thank you for the courtesy.

 >     I committed some changes using C-x v v in vc-dir.
 >     Something went wrong with lisp/ChangeLog.
 > 
 >     It appears that my change log entries went into an old version of that
 >     file; I don't know why this happened, since I wrote them today after
 >     doing 'git pull'.

OK, so I interpreted this as

1. Hack the "some changes" mentioned above.
2. Git pull successfully, implying the files changed in Richard's
   workspace but (I assume) not committed did not conflict.
3. Edit ChangeLog and C-x v v to commit, successfully.

   But some log messages were missing.  (This makes no sense to me,
   unless somehow he did not see messages that said that the merge was
   not performed.  Is it possible that vc displays messages from
   stdout but not stderr or something like that?  I'm grasping at
   straws, I know -- but Richard is a good bug reporter, and yet what
   he reports doesn't make sense.)

 >     After this, I did 'git pull' again, and it said there was a merge
 >     conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
 >     the file.  It said, "fix conflicts and then commit the result."

If the previous pull succeeded, does this mean that he lost a race in
a handful of minutes?  And lost "a lot" of text?  Weird.

 >     I edited lisp/ChangeLog and tried to commit it with C-x v v.
 >     That gave me the error message
 > 
 >       fatal: cannot do a partial commit during a merge.

Confirmation that there were uncommitted files throughout.  But wait!
the plot thickens:

 >     I am now stuck.  I don't know what a "merge" is; it is certainly
 >     nothing I asked to do.
 > 
 > Note the "merge conflict" part and the error message Richard cites:
 > "fix conflicts and then commit the result."  This is a message
 > displayed by Git when you have a conflict in _committed_ changes, and
 > the merge fails half-way through.  Error messages about conflicts in
 > uncommitted changes are different
 > 
 > The second error message, viz.:
 > 
 >   fatal: cannot do a partial commit during a merge.
 > 
 > is because "C-x v v" invokes "git commit --only lisp/ChangeLog", which
 > AFAIR always fails in this situation, for the reason hinted by the
 > error message.

Aha!  But "git commit --include lisp/ChangeLog" DTRTs in this case,
committing the staged changes from the files successfully merged as
well as the new changes from the files where conflicts were resolved.
(Tested in a toy repo.)

In other words, *Emacs* screwed Richard, not git.  git, with a little
scripting (either in the shell or in vc.el) may very well be quite
capable of supporting Richard's (and Alan's!) preferred "leave the
changes still being tested uncommitted" workflow.

 > Yes, something like that.  In fact, I think the root cause of the
 > original problem was that "C-x v v", which tried to commit a single
 > file in the middle of a merge.  Instead, the correct action is either
 > 'v' from vc-dir or "git commit" from the shell prompt.

I don't think "git commit" will actually work.  "git commit" alone
will either commit only the unconflicted staged files (I think this
unlikely) or will refuse to commit because it remembers that ChangeLog
was conflicted (more likely).  You need to "git add lisp/ChangeLog",
or you use --include on the command line (note that in this situation
"git commit lisp/ChangeLog" and "git commit --only lisp/ChangeLog" are
equivalent according to the manual).

Perhaps v in vc-dir might do the right thing, but I suspect it suffers
from the same issue as "git commit" with no file arguments.

 > It would be good if "C-x v v" tried to support this situation
 > better.

Definitely.  Unfortunately it's late and I can't guess whether
"--include" is generally appropriate, or whether there's a more
frequent case where "--only" is appropriate, and "--only" should get
precedence.  I hope Eric knows.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 05 Apr 2015 17:31:53 +0900
> 
>  >     I committed some changes using C-x v v in vc-dir.
>  >     Something went wrong with lisp/ChangeLog.
>  > 
>  >     It appears that my change log entries went into an old version of that
>  >     file; I don't know why this happened, since I wrote them today after
>  >     doing 'git pull'.
> 
> OK, so I interpreted this as
> 
> 1. Hack the "some changes" mentioned above.
> 2. Git pull successfully, implying the files changed in Richard's
>    workspace but (I assume) not committed did not conflict.
> 3. Edit ChangeLog and C-x v v to commit, successfully.
> 
>    But some log messages were missing.

Which ones?  I'm afraid I'm not following you in this part.

>  >     After this, I did 'git pull' again, and it said there was a merge
>  >     conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
>  >     the file.  It said, "fix conflicts and then commit the result."
> 
> If the previous pull succeeded, does this mean that he lost a race in
> a handful of minutes?  And lost "a lot" of text?  Weird.

One possibility is a merge from emacs-24, which can potentially bring
quite a few commits from the release branch, and is done by a program,
so it can be very fast.  Look at the long list of the modified files
that are staged, which the pull succeeded to merge -- they do suggest
a lot of changes were fetched.

>  > The second error message, viz.:
>  > 
>  >   fatal: cannot do a partial commit during a merge.
>  > 
>  > is because "C-x v v" invokes "git commit --only lisp/ChangeLog", which
>  > AFAIR always fails in this situation, for the reason hinted by the
>  > error message.
> 
> Aha!  But "git commit --include lisp/ChangeLog" DTRTs in this case,
> committing the staged changes from the files successfully merged as
> well as the new changes from the files where conflicts were resolved.
> (Tested in a toy repo.)
> 
> In other words, *Emacs* screwed Richard, not git.

Yes, basically.  More accurately, too rudimentary support in VC for
Git and the "popular" problems that need to be resolved with it.

>  > Yes, something like that.  In fact, I think the root cause of the
>  > original problem was that "C-x v v", which tried to commit a single
>  > file in the middle of a merge.  Instead, the correct action is either
>  > 'v' from vc-dir or "git commit" from the shell prompt.
> 
> I don't think "git commit" will actually work.  "git commit" alone
> will either commit only the unconflicted staged files (I think this
> unlikely) or will refuse to commit because it remembers that ChangeLog
> was conflicted (more likely).  You need to "git add lisp/ChangeLog",

Saving a file after resolving all of its conflicts automatically runs
"git add" for that file in Emacs's VC, so it is already staged.

So yes, "git commit" should have worked.

Re: VC mode and git

[Stephen J. Turnbull]

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

 > > OK, so I interpreted this as [...]
 > > 
 > > 3. Edit ChangeLog and C-x v v to commit, successfully.
 > > 
 > >    But some log messages were missing.
 > 
 > Which ones?  I'm afraid I'm not following you in this part.

Richard wrote:

 > >  >     Something went wrong with lisp/ChangeLog.
 > >  > 
 > >  >     It appears that my change log entries went into an old
 > >  >     version of that file; I don't know why this happened,
 > >  >     since I wrote them today after doing 'git pull'.

From "old version", I assume he recognized that because logs were
missing from the file.

 > > If the previous pull succeeded, does this mean that he lost a
 > > race in a handful of minutes?  And lost "a lot" of text?  Weird.
 > 
 > One possibility is a merge from emacs-24, which can potentially bring
 > quite a few commits from the release branch, and is done by a program,
 > so it can be very fast.  Look at the long list of the modified files
 > that are staged, which the pull succeeded to merge -- they do suggest
 > a lot of changes were fetched.

You think Richard pulled from emacs-24?  We'd have to ask him, but I
would think he would have reported that if he had done it.  Otherwise
I don't understand what you're talking about.

 > > In other words, *Emacs* screwed Richard, not git.
 > 
 > Yes, basically.  More accurately, too rudimentary support in VC for
 > Git and the "popular" problems that need to be resolved with it.

Certainly.  And I'll grant that Glenn hammered on the issue of proper
support for Emacs-for-git workflows for months while the transition
was in progress.

 > Saving a file after resolving all of its conflicts automatically
 > runs "git add" for that file in Emacs's VC, so it is already
 > staged.
 > 
 > So yes, "git commit" should have worked.

OK.  If vc does that, I don't understand the intended workflow in vc,
then.  Maybe it's just adapted to what ESR does.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Mon, 06 Apr 2015 02:36:37 +0900
> 
>  > > If the previous pull succeeded, does this mean that he lost a
>  > > race in a handful of minutes?  And lost "a lot" of text?  Weird.
>  > 
>  > One possibility is a merge from emacs-24, which can potentially bring
>  > quite a few commits from the release branch, and is done by a program,
>  > so it can be very fast.  Look at the long list of the modified files
>  > that are staged, which the pull succeeded to merge -- they do suggest
>  > a lot of changes were fetched.
> 
> You think Richard pulled from emacs-24?

No, I think someone else merged from emacs-24 onto master, and pushed
the result between Richard's 2 pulls.

>  > Saving a file after resolving all of its conflicts automatically
>  > runs "git add" for that file in Emacs's VC, so it is already
>  > staged.
>  > 
>  > So yes, "git commit" should have worked.
> 
> OK.  If vc does that, I don't understand the intended workflow in vc,
> then.  Maybe it's just adapted to what ESR does.

I think VC's support of the intended workflow "needs work" (TM).

Re: VC mode and git

[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 some log messages were missing.  (This makes no sense to me,
     > unless somehow he did not see messages that said that the merge was
     > not performed.  Is it possible that vc displays messages from
     > stdout but not stderr or something like that?  I'm grasping at
     > straws, I know -- but Richard is a good bug reporter, and yet what
     > he reports doesn't make sense.)

I typed 'git pull' in a terminal.  Since that tends to spew lots of
output, I probably did not look at the output.  I did not realize
there was any chance it might fail!  I expected the possibility of
conflicts, but I expected to find out about them and fix them.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 13:42:04 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, sorganov@gmail.com, emacs-devel@gnu.org
> 
> I typed 'git pull' in a terminal.  Since that tends to spew lots of
> output, I probably did not look at the output.  I did not realize
> there was any chance it might fail!  I expected the possibility of
> conflicts, but I expected to find out about them and fix them.

That "failure" is just a different expression of conflicts, that's
all.  the underlying issues are the same, it's just that CVS was less
verbose than Git in this case, and you are used to what CVS did, but
not yet used to how Git reacts to such conflicts.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> Yes, something like that.  In fact, I think the root cause of the
> original problem was that "C-x v v", which tried to commit a single
> file in the middle of a merge.  Instead, the correct action is either
> 'v' from vc-dir or "git commit" from the shell prompt.
>
> It would be good if "C-x v v" tried to support this situation better.
> I hope Eric Raymond is reading this.

You need to detect the fact that a merge is underway. Is the existence 
of .git/MERGE_HEAD a reliable indicator of this?

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 11:55:24 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, sorganov@gmail.com, 
>  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Yes, something like that.  In fact, I think the root cause of the
> > original problem was that "C-x v v", which tried to commit a single
> > file in the middle of a merge.  Instead, the correct action is either
> > 'v' from vc-dir or "git commit" from the shell prompt.
> >
> > It would be good if "C-x v v" tried to support this situation better.
> > I hope Eric Raymond is reading this.
> 
> You need to detect the fact that a merge is underway. Is the existence 
> of .git/MERGE_HEAD a reliable indicator of this?

I think so, but I hope some Git expert will answer that.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> Note the "merge conflict" part and the error message Richard cites:
> "fix conflicts and then commit the result."  This is a message
> displayed by Git when you have a conflict in _committed_ changes, and
> the merge fails half-way through.  Error messages about conflicts in
> uncommitted changes are different

Indeed. But then the lack of any files marked U in the output of “git 
status -s” is puzzling. Instead, there is just lisp/ChangeLog, marked 
MM. Perhaps that is a side effect of something else he did.

– Harald

Re: VC mode and git

[Harald Hanche-Olsen]

Stephen J. Turnbull wrote:
> Eli Zaretskii writes:
>
>   >  What he did became clear, even to me, after he showed the information
>   >  we requested.
>
> It did?  It's not clear to me.  I still haven't seen an explanation of
> how he ended up with a ton of modified files that he didn't touch, or
> how he's going to get past that safely.

Then you must have been missing some messages. Short summary of such an 
explanation: They are the result of an incomplete merge operation, and 
all come from origin/master at the time of his pull. This may not be the 
*correct* explanation, but it is a *possible* explanation.

> Nobody has mentioned him
> doing a diff against a public reference commit that *should* be where
> he started, in order to confirm that when he pushes he can succeed
> (preferably without making the DAG too ugly, as well).

I have mentioned this. It is true that on this list, if not in the world 
at large, I am a nobody, but you don't have to rub it in.

– Harald

Re: VC mode and git

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:
 > Stephen J. Turnbull wrote:
 > > Eli Zaretskii writes:
 > >
 > >   >  What he did became clear, even to me, after he showed the information
 > >   >  we requested.
 > >
 > > It did?  It's not clear to me.  I still haven't seen an explanation of
 > > how he ended up with a ton of modified files that he didn't touch, or
 > > how he's going to get past that safely.
 > 
 > Then you must have been missing some messages. Short summary of such an 
 > explanation: They are the result of an incomplete merge operation, and 
 > all come from origin/master at the time of his pull. This may not be the 
 > *correct* explanation, but it is a *possible* explanation.

Yes, and I've posted three times mentioning those posts (by Eli as
well as you) and explaining the I have tried to reproduce this in a
toy repo and have been unable to.  It's no longer a possible
explanation that he pulled and these were left over *as far as I can
tell*.  I worry that it may matter in getting his repo fixed up
properly.

 > > Nobody has mentioned him doing a diff against a public reference
 > > commit that *should* be where he started, in order to confirm
 > > that when he pushes he can succeed (preferably without making the
 > > DAG too ugly, as well).
 > 
 > I have mentioned this.

You have my apologies then.  Make that "very few have mentioned this,
and not recently."  When I said nobody, I was mostly referring to the
recent spate of posts saying "fix, commit, pull, push should do it."

 > It is true that on this list, if not in the world at large, I am a
 > nobody, but you don't have to rub it in.

I assure you I have been taking your posts seriously.

Re: VC mode and git

[Lele Gaifax]

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

> Harald Hanche-Olsen writes:
>  > Short summary of such an 
>  > explanation: They are the result of an incomplete merge operation, and 
>  > all come from origin/master at the time of his pull. This may not be the 
>  > *correct* explanation, but it is a *possible* explanation.
>
> Yes, and I've posted three times mentioning those posts (by Eli as
> well as you) and explaining the I have tried to reproduce this in a
> toy repo and have been unable to.  It's no longer a possible
> explanation that he pulled and these were left over *as far as I can
> tell*.  I worry that it may matter in getting his repo fixed up
> properly.

AFAICT, the following simple script replicates a similar case, with the same
outcome:

    RD=/tmp/rd_$$

    mkdir -p $RD

    git init $RD/remote
    cd $RD/remote
    for f in a b c
    do
        echo $f > $f
        git add $f
    done
    git commit -m "Bootstrap"

    cd $RD
    git clone remote local

    cd local
    echo "local tweak" >> a
    git add a
    git commit -m "Local tweak"

    cd $RD/remote
    for f in a b c
    do
        echo $f >> $f
        git add $f
    done
    git commit -m "Second pass"

    cd $RD/local
    git pull
    git status --short

Running it, you end with the following state in the "local" repository:

    UU a
    M  b
    M  c

where you see that the "a" file is "dirty" and contains conflict markers:

    $ cat a
    a
    <<<<<<< HEAD
    local tweak
    =======
    a
    >>>>>>> d2f149d20ecc0e259331d82497e0388828d940ad

My 2 cents,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: VC mode and git

[Stephen J. Turnbull]

Lele Gaifax writes:

 > AFAICT, the following simple script replicates a similar case, with
 > the same outcome:

That script does the pull with no uncommitted changes, but my
understanding was that Richard likes to leave changes uncommitted, and
that was the case here.

Re: VC mode and git

[Lele Gaifax]

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

> Lele Gaifax writes:
>
>  > AFAICT, the following simple script replicates a similar case, with
>  > the same outcome:
>
> That script does the pull with no uncommitted changes, but my
> understanding was that Richard likes to leave changes uncommitted, and
> that was the case here.

I disagree with that understanding, for two reasons:

a) Richard started this thread[*] being surprised that under git a "commit" is
   a different thing than a "push", when realized he changed some entries in
   an old version of some ChangeLog; as Richard also stated that he usually
   touches the ChangeLog only when he is satisfied by the changes, I assume
   that he committed those as well (it does not make any difference if using a
   single commit with the changelog notes, or in different commits)

b) the "git status -s" he sent shows that his ChangeLog file was "modified on
   both sides", and that can happen only when there were commits on both sides
   that touched the file in question

Both reasons match with the scenario I scripted.

Happy Easter,
ciao, lele.

[*] Really "git is screwed", started a couple of days before this one
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: VC mode and git

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

  > That script does the pull with no uncommitted changes, but my
  > understanding was that Richard likes to leave changes uncommitted, and
  > that was the case here.

On this occasion there were no changes I wanted to leave uncommitted,
and I think I had committed all of them before doing the pull that
messed things up.

I raised the issue of changes not to be installed because in
general I might have some.  I have had some in the past.  But I think
that was not a factor _this time_.

I tried to verify this by investigating what changes I stashed last
week.  But I could not tell the answer, because 'git stash show' gave
me the output below.

Now I am concerned that when I pull again, it will reinstall all of this.
Anyway, I can't see what my own changes were.

======================================================================
WARNING: terminal is not fully functional
-  (press RETURN)
 .gitattributes                            |    3 +
 CONTRIBUTE                                |   20 +
 ChangeLog                                 |   89 +-
 README.xwidget                            |    2 -
 admin/ChangeLog                           |    9 +
 admin/MAINTAINERS                         |    5 +
 admin/admin.el                            |    2 +-
 admin/authors.el                          |    2 +
 admin/notes/repo                          |   21 +
 configure.ac                              |  169 +-
 doc/emacs/ChangeLog                       |   36 +
 doc/emacs/ack.texi                        |    2 +-
 doc/emacs/basic.texi                      |    4 +-
 doc/emacs/buffers.texi                    |    2 +-
 doc/emacs/cmdargs.texi                    |   49 +-
 doc/emacs/custom.texi                     |    7 +-
 doc/emacs/display.texi                    |    4 +-
 doc/emacs/frames.texi                     |    2 +-
 doc/emacs/killing.texi                    |    2 +-
 doc/emacs/mini.texi                       |    2 +-
 doc/emacs/misc.texi                       |    2 +-
 doc/emacs/msdos-xtra.texi                 |    2 +-
 doc/emacs/msdos.texi                      |   39 +-
 doc/emacs/mule.texi                       |   86 +-
 doc/emacs/programs.texi                   |    6 +-
 doc/emacs/text.texi                       |    2 +-
 doc/emacs/trouble.texi                    |   10 +-
 doc/lispintro/emacs-lisp-intro.texi       |    6 +-
 doc/lispref/ChangeLog                     |   71 +
 doc/lispref/commands.texi                 |    6 +-
 doc/lispref/control.texi                  |  118 ++
 doc/lispref/display.texi                  |    7 +-
 doc/lispref/elisp.texi                    |    6 +-
 doc/lispref/frames.texi                   |   55 +-
 doc/lispref/functions.texi                |    4 +-
 doc/lispref/internals.texi                |    2 +-
 doc/lispref/loading.texi                  |    2 +-
 doc/lispref/minibuf.texi                  |    4 +-
 doc/lispref/numbers.texi                  |    2 +-
 doc/lispref/objects.texi                  |   37 +-
 doc/lispref/os.texi                       |    5 +-
 doc/lispref/positions.texi                |   10 +-
 doc/lispref/processes.texi                |   16 +-
 doc/lispref/searching.texi                |   12 +-
 doc/lispref/sequences.texi                |   69 +-
 doc/lispref/streams.texi                  |    2 +-
 doc/lispref/text.texi                     |    4 +-
:
 doc/misc/ChangeLog                        |   64 +
:
 doc/misc/auth.texi                        |   26 +-
:
 doc/misc/calc.texi                        |    2 +-
:
 doc/misc/cc-mode.texi                     |    4 +-
:
 doc/misc/cl.texi                          |   12 +
:
 doc/misc/efaq-w32.texi                    |  425 ++---
:
 doc/misc/efaq.texi                        |   12 +-
:
 doc/misc/eieio.texi                       |    2 +-
:
 doc/misc/erc.texi                         |   14 +-
:
 doc/misc/eshell.texi                      |    2 +-
:
 doc/misc/eww.texi                         |   10 +-
:
 doc/misc/gnus.texi                        |   30 +-
:
 doc/misc/htmlfontify.texi                 |    4 +-
:
 doc/misc/idlwave.texi                     |    4 +-
:
 doc/misc/ido.texi                         |    2 +-
:
 doc/misc/newsticker.texi                  |    2 +-
:
 doc/misc/org.texi                         |    8 +-
:
 doc/misc/pgg.texi                         |    2 +-
:
 doc/misc/reftex.texi                      |   16 +-
:
 doc/misc/texinfo.tex                      |  150 +-
:
 doc/misc/todo-mode.texi                   |    4 +-
:
 doc/misc/tramp.texi                       |   53 +-
:
 doc/misc/trampver.texi                    |    2 +-
:
 doc/misc/vhdl-mode.texi                   |    6 +-
:
 doc/misc/vip.texi                         |    2 +-
:
 doc/misc/viper.texi                       |    2 +-
:
 doc/misc/woman.texi                       |    2 +-
:
 etc/AUTHORS                               | 2947 ++++++++++++++++++-----------
:
 etc/ChangeLog                             |   25 +
:
 etc/GNUS-NEWS                             |    2 +
:
 etc/NEWS                                  |   92 +-
:
 etc/NEWS.24                               |   38 +-
:
 etc/TODO                                  |   15 +
:
 leim/ChangeLog                            |    7 +
:
 leim/Makefile.in                          |    2 +-
:
 lib-src/ChangeLog                         |   62 +
:
 lib-src/Makefile.in                       |    2 +-
:
 lib-src/emacsclient.c                     |   81 +-
:
 lib-src/etags.c                           |    8 +-
:
 lib-src/make-docfile.c                    |   27 +-
:
 lib-src/movemail.c                        |  197 +-
:
 lib/dirent.in.h                           |    2 +
:
 lib/dirfd.c                               |   32 +
:
 lib/fdopendir.c                           |   13 +-
:
 lib/getdtablesize.c                       |   42 +-
:
 lib/getopt.c                              |   52 +-
:
 lib/gnulib.mk                             |   11 +
:
 lib/signal.in.h                           |    8 +-
:
 lib/tempname.c                            |  118 +-
:
 lib/tempname.h                            |   15 +
:
 lisp/ChangeLog                            | 1769 ++++++++++++++++-
:
 lisp/ChangeLog.16                         |    4 +-
:
 lisp/Makefile.in                          |    4 +-
:
 lisp/autorevert.el                        |  154 +-
:
 lisp/battery.el                           |  103 +-
:
 lisp/bindings.el                          |    1 +
:
 lisp/calendar/solar.el                    |   22 +-
:
 lisp/calendar/todo-mode.el                |    7 +-
:
 lisp/cedet/ChangeLog                      |   28 +
:
 lisp/cedet/ede.el                         |   79 +-
:
 lisp/cedet/ede/auto.el                    |   13 +-
:
 lisp/cedet/ede/base.el                    |   35 +-
:
 lisp/cedet/ede/config.el                  |   30 +-
:
 lisp/cedet/ede/cpp-root.el                |   38 +-
:
 lisp/cedet/ede/custom.el                  |   10 +-
:
 lisp/cedet/ede/emacs.el                   |   20 +-
:
 lisp/cedet/ede/files.el                   |   22 +-
:
 lisp/cedet/ede/generic.el                 |   18 +-
:
 lisp/cedet/ede/linux.el                   |   24 +-
:
 lisp/cedet/ede/locate.el                  |   60 +-
:
 lisp/cedet/ede/pconf.el                   |   16 +-
:
 lisp/cedet/ede/pmake.el                   |   60 +-
:
 lisp/cedet/ede/proj-archive.el            |    6 +-
:
 lisp/cedet/ede/proj-aux.el                |    2 +-
:
 lisp/cedet/ede/proj-comp.el               |   22 +-
:
 lisp/cedet/ede/proj-elisp.el              |   50 +-
:
 lisp/cedet/ede/proj-info.el               |   20 +-
:
 lisp/cedet/ede/proj-misc.el               |    6 +-
:
 lisp/cedet/ede/proj-obj.el                |   16 +-
:
 lisp/cedet/ede/proj-prog.el               |   16 +-
:
 lisp/cedet/ede/proj-scheme.el             |    2 +-
:
 lisp/cedet/ede/proj-shared.el             |   12 +-
:
 lisp/cedet/ede/proj.el                    |   60 +-
:
 lisp/cedet/ede/project-am.el              |   84 +-
:
 lisp/cedet/ede/shell.el                   |    4 +-
:
 lisp/cedet/ede/simple.el                  |    4 +-
:
 lisp/cedet/ede/source.el                  |   16 +-
:
 lisp/cedet/ede/speedbar.el                |   20 +-
:
 lisp/cedet/ede/util.el                    |    6 +-
:
 lisp/cedet/semantic/analyze.el            |   32 +-
:
 lisp/cedet/semantic/analyze/refs.el       |    4 +-
:
 lisp/cedet/semantic/bovine/debug.el       |    8 +-
:
 lisp/cedet/semantic/complete.el           |  104 +-
:
 lisp/cedet/semantic/db-ebrowse.el         |   50 +-
:
 lisp/cedet/semantic/db-el.el              |   58 +-
:
 lisp/cedet/semantic/db-file.el            |   34 +-
:
 lisp/cedet/semantic/db-find.el            |   24 +-
:
 lisp/cedet/semantic/db-global.el          |   28 +-
:
 lisp/cedet/semantic/db-javascript.el      |   36 +-
:
 lisp/cedet/semantic/db-ref.el             |   15 +-
:
 lisp/cedet/semantic/db-typecache.el       |   30 +-
:
 lisp/cedet/semantic/db.el                 |   90 +-
:
 lisp/cedet/semantic/debug.el              |   37 +-
:
 lisp/cedet/semantic/decorate/include.el   |    6 +-
:
 lisp/cedet/semantic/doc.el                |    9 +-
:
 lisp/cedet/semantic/ede-grammar.el        |   18 +-
:
 lisp/cedet/semantic/ia-sb.el              |   12 +-
:
 lisp/cedet/semantic/mru-bookmark.el       |   10 +-
:
 lisp/cedet/semantic/scope.el              |   10 +-
:
 lisp/cedet/semantic/symref.el             |   12 +-
:
 lisp/cedet/semantic/symref/cscope.el      |    4 +-
:
 lisp/cedet/semantic/symref/global.el      |    4 +-
:
 lisp/cedet/semantic/symref/grep.el        |    4 +-
:
 lisp/cedet/semantic/symref/idutils.el     |    4 +-
:
 lisp/cedet/srecode/compile.el             |   15 +-
:
 lisp/cedet/srecode/dictionary.el          |   35 +-
:
 lisp/cedet/srecode/document.el            |    2 +-
:
 lisp/cedet/srecode/extract.el             |   24 +-
:
 lisp/cedet/srecode/fields.el              |   43 +-
:
 lisp/cedet/srecode/find.el                |   10 +-
:
 lisp/cedet/srecode/insert.el              |   82 +-
:
 lisp/cedet/srecode/map.el                 |   18 +-
:
 lisp/cedet/srecode/semantic.el            |    2 +-
:
 lisp/cedet/srecode/table.el               |    7 +-
:
 lisp/comint.el                            |   37 +-
:
 lisp/delsel.el                            |   17 +-
:
 lisp/desktop.el                           |   76 +-
:
 lisp/dired.el                             |   15 +-
:
 lisp/doc-view.el                          |   17 +-
:
 lisp/dom.el                               |   10 +
:
 lisp/emacs-lisp/byte-opt.el               |  121 +-
:
 lisp/emacs-lisp/byte-run.el               |   28 +-
:
 lisp/emacs-lisp/bytecomp.el               |   73 +-
:
 lisp/emacs-lisp/cconv.el                  |   31 +-
:
 lisp/emacs-lisp/check-declare.el          |   51 +-
:
 lisp/emacs-lisp/checkdoc.el               |   17 +-
:
 lisp/emacs-lisp/cl-generic.el             |  657 ++++---
:
 lisp/emacs-lisp/cl-indent.el              |   62 +-
:
 lisp/emacs-lisp/cl-lib.el                 |   16 -
:
 lisp/emacs-lisp/cl-macs.el                |  531 +++---
:
 lisp/emacs-lisp/cl-preloaded.el           |  241 ++-
:
 lisp/emacs-lisp/debug.el                  |   14 +-
:
 lisp/emacs-lisp/easy-mmode.el             |   25 +-
:
 lisp/emacs-lisp/edebug.el                 |   71 +-
:
 lisp/emacs-lisp/eieio-base.el             |   39 +-
:
 lisp/emacs-lisp/eieio-compat.el           |   64 +-
:
 lisp/emacs-lisp/eieio-core.el             |  744 +++-----
:
 lisp/emacs-lisp/eieio-custom.el           |  161 +-
:
 lisp/emacs-lisp/eieio-datadebug.el        |   68 +-
:
 lisp/emacs-lisp/eieio-opt.el              |   89 +-
:
 lisp/emacs-lisp/eieio.el                  |  208 +-
:
 lisp/emacs-lisp/generator.el              |  796 ++++++++
:
 lisp/emacs-lisp/gv.el                     |   17 +-
:
 lisp/emacs-lisp/lisp-mode.el              |   63 +-
:
 lisp/emacs-lisp/lisp.el                   |    5 +-
:
 lisp/emacs-lisp/macroexp.el               |   19 +-
:
 lisp/emacs-lisp/package-x.el              |    2 +-
:
 lisp/emacs-lisp/package.el                | 1132 +++++++----
:
 lisp/emacs-lisp/pcase.el                  |   23 +
:
 lisp/emacs-lisp/seq.el                    |   82 +-
:
 lisp/emacs-lisp/smie.el                   |    7 +-
:
 lisp/emacs-parallel/README.org            |  147 --
:
 lisp/emacs-parallel/parallel-remote.el    |   81 -
:
 lisp/emacs-parallel/parallel-xwidget.el   |   59 -
:
 lisp/emacs-parallel/parallel.el           |  310 ---
:
 lisp/emulation/viper-cmd.el               |    4 +-
:
 lisp/emulation/viper-init.el              |    2 +-
:
 lisp/emulation/viper-keym.el              |    8 +-
:
 lisp/erc/ChangeLog                        |   30 +
:
 lisp/erc/erc-spelling.el                  |    3 +-
:
 lisp/erc/erc.el                           |  105 +-
:
 lisp/eshell/em-hist.el                    |    4 +-
:
 lisp/eshell/em-pred.el                    |   14 +-
:
 lisp/eshell/esh-mode.el                   |    7 +
:


 lisp/facemenu.el                          |    2 +-
 lisp/faces.el                             |   20 +-
 lisp/filecache.el                         |    3 +-
:
 lisp/files.el                             |   21 +-
:
 lisp/font-lock.el                         |    8 +-
:
 lisp/frame.el                             |  131 +-
:
 lisp/frameset.el                          |    4 +-
:
 lisp/gnus/ChangeLog                       |  179 +-
:
 lisp/gnus/gnus-art.el                     |   80 +-
:
 lisp/gnus/gnus-int.el                     |    2 +-
:
 lisp/gnus/gnus-msg.el                     |   12 +-
:
 lisp/gnus/gnus-notifications.el           |   21 +-
:
 lisp/gnus/gnus-registry.el                |   45 +-
:
 lisp/gnus/gnus-start.el                   |   34 +-
:
 lisp/gnus/gnus-sum.el                     |    6 +-
:
 lisp/gnus/mail-source.el                  |   15 +-
:
 lisp/gnus/mailcap.el                      |    5 +
:
 lisp/gnus/message.el                      |    7 +-
:
 lisp/gnus/mm-decode.el                    |   25 +-
:
 lisp/gnus/mm-util.el                      |    5 +-
:
 lisp/gnus/mm-view.el                      |    2 +-
:
 lisp/gnus/nnimap.el                       |   74 +-
:
 lisp/gnus/nnir.el                         |  123 +-
:
 lisp/gnus/nnmail.el                       |    2 +-
:
 lisp/gnus/registry.el                     |   55 +-
:
 lisp/gnus/rfc2104.el                      |  124 --
:
 lisp/help-fns.el                          |   35 +-
:
 lisp/help-mode.el                         |   18 +-
:
 lisp/help.el                              |    2 +
:
 lisp/hi-lock.el                           |    7 +-
:
 lisp/ido.el                               |   18 +-
:
 lisp/image-mode.el                        |    6 +
:
 lisp/info-look.el                         |   47 +-
:
 lisp/international/fontset.el             |    1 +
:
 lisp/international/quail.el               |    7 +-
:
 lisp/isearchb.el                          |    6 +-
:
 lisp/json.el                              |    6 +-
:
 lisp/ldefs-boot.el                        |  591 +++---
:
 lisp/leim/quail/hangul.el                 |    4 +-
:
 lisp/mail/rmail.el                        |    4 +-
:
 lisp/mail/rmailmm.el                      |   17 +
:
 lisp/mail/rmailsum.el                     |   17 +-
:
 lisp/menu-bar.el                          |   12 +-
:
 lisp/misearch.el                          |    4 +-
:
 lisp/mouse.el                             |   13 +-
:
 lisp/net/browse-url.el                    |  159 +-
:
 lisp/net/dbus.el                          |    3 +-
:
 lisp/net/eudcb-bbdb.el                    |   24 +-
:
 lisp/net/eudcb-ldap.el                    |   53 +-
:
 lisp/net/eww.el                           |   52 +-
:
 lisp/net/ldap.el                          |   18 +-
:
 lisp/net/network-stream.el                |    6 +-
:
 lisp/net/rfc2104.el                       |  124 ++
:
 lisp/net/sasl-scram-rfc.el                |  163 ++
:
 lisp/net/sasl.el                          |    6 +-
:
 lisp/net/shr.el                           |  844 ++++++---
:
 lisp/net/tramp-adb.el                     |   98 +-
:
 lisp/net/tramp-cache.el                   |    6 +-
:
 lisp/net/tramp-gvfs.el                    |    2 +
:
 lisp/net/tramp-sh.el                      |  316 ++--
:
 lisp/net/tramp-smb.el                     |    6 +
:
 lisp/net/tramp.el                         |   46 +-
:
 lisp/net/trampver.el                      |    4 +-
:
 lisp/newcomment.el                        |   32 +
:
 lisp/obsolete/iswitchb.el                 |    6 +-
:
 lisp/org/ChangeLog                        |    4 +-
:
 lisp/outline.el                           |    7 +-
:
 lisp/play/gamegrid.el                     |   20 +-
:
 lisp/progmodes/cc-engine.el               |   10 +-
:
 lisp/progmodes/cc-mode.el                 |   25 +-
:
 lisp/progmodes/cperl-mode.el              |    6 +-
:
 lisp/progmodes/elisp-mode.el              |    9 +-
:
 lisp/progmodes/f90.el                     |   25 +-
:
 lisp/progmodes/gdb-mi.el                  |   12 +-
:
 lisp/progmodes/gud.el                     |    4 +-
:
 lisp/progmodes/js.el                      |   74 +
:
 lisp/progmodes/python.el                  |  381 ++--
:
 lisp/progmodes/ruby-mode.el               |   33 +-
:
 lisp/progmodes/sql.el                     |   45 +-
:
 lisp/progmodes/verilog-mode.el            |   37 +-
:
 lisp/progmodes/vhdl-mode.el               |  273 ++-
:
 lisp/progmodes/xref.el                    |   23 +
:
 lisp/rect.el                              |    3 +-
:
 lisp/register.el                          |   17 +-
:
 lisp/replace.el                           |    2 +-
:
 lisp/server.el                            |   12 +-
:
 lisp/simple.el                            |   82 +-
:
 lisp/startup.el                           |    7 +-
:
 lisp/subr.el                              |    7 +-
:
 lisp/textmodes/artist.el                  |    2 +-
:
 lisp/textmodes/css-mode.el                |  290 +--
:
 lisp/textmodes/flyspell.el                |  125 +-
:
 lisp/textmodes/ispell.el                  |   67 +-
:
 lisp/textmodes/reftex-vars.el             |   33 +-
:
 lisp/textmodes/text-mode.el               |   17 +
:
 lisp/url/ChangeLog                        |   11 +
:
 lisp/url/url-handlers.el                  |   15 +-
:
 lisp/vc/vc-bzr.el                         |   13 +-
:
 lisp/vc/vc-cvs.el                         |   24 +-
:
 lisp/vc/vc-git.el                         |   14 +-
:
 lisp/vc/vc-hg.el                          |   16 +-
:
 lisp/vc/vc-hooks.el                       |    4 +-
:
 lisp/vc/vc-mtn.el                         |   16 +-
:
 lisp/vc/vc-rcs.el                         |  164 +-
:
 lisp/vc/vc-sccs.el                        |   15 +-
:
 lisp/vc/vc-src.el                         |    8 +-
:
 lisp/vc/vc-svn.el                         |   15 +-
:
 lisp/vc/vc.el                             |   21 +
:
 lisp/w32-vars.el                          |   17 +-
:
 lisp/widget.el                            |    3 +
:
 lisp/windmove.el                          |    4 +-
:
 lisp/window.el                            |   57 +-
:
 lisp/winner.el                            |    2 +-
:
 lisp/xwidget.el                           |  592 ------
:
 lwlib/ChangeLog                           |    9 +
:
 lwlib/xlwmenu.c                           |   71 +-
:
 m4/dirfd.m4                               |   83 +
:
 m4/dup2.m4                                |   84 +-
:
 m4/fcntl.m4                               |   58 +-
:
 m4/getdtablesize.m4                       |    6 +-
:
 m4/gnulib-comp.m4                         |   20 +
:
 nt/ChangeLog                              |   19 +
:
 nt/INSTALL                                |   23 +-
:
 nt/cmdproxy.c                             |   72 +-
:
 nt/inc/ms-w32.h                           |    2 +
:
 src/ChangeLog                             |  669 ++++++-
:
 src/Makefile.in                           |   10 -
:
 src/alloc.c                               |  213 ++-
:
 src/bidi.c                                |    5 +
:
 src/buffer.c                              |   17 +-
:
 src/bytecode.c                            |    8 +-
:
 src/callint.c                             |   12 +-
:
 src/callproc.c                            |    2 +-
:
 src/character.c                           |   38 +
:
 src/character.h                           |    3 +
:
 src/charset.c                             |    4 +-
:
 src/coding.c                              |    8 +-
:
 src/data.c                                |   10 +-
:
 src/dispextern.h                          |   55 +-
:
 src/dispnew.c                             |  156 +-
:
 src/editfns.c                             |   63 +-
:
 src/emacs.c                               |   70 +-
:
 src/emacsgtkfixed.c                       |  119 +-
:
 src/emacsgtkfixed.h                       |   28 -
:
 src/eval.c                                |   22 +-
:
 src/fileio.c                              |   18 +-
:
 src/fns.c                                 |    2 +-
:
 src/font.c                                |    1 -
:
 src/frame.c                               |  231 ++-
:
 src/frame.h                               |   21 +-
:
 src/ftfont.c                              |    1 -
:
 src/gtkutil.c                             |  118 +-
:
 src/indent.c                              |   73 +-
:
 src/intervals.h                           |    4 +-
:
 src/keyboard.c                            |   72 +-
:
 src/keymap.c                              |    4 +-
:
 src/lisp.h                                |   68 +-
:
 src/lread.c                               |   37 +-
:
 src/menu.c                                |   58 +-
:
 src/minibuf.c                             |   26 +-
:
 src/nsfns.m                               |   88 +-
:
 src/print.c                               |   25 +-
:
 src/regex.c                               |   18 +-
:
 src/search.c                              |    6 +
:
 src/sysdep.c                              |   20 +-
:
 src/sysstdio.h                            |   29 +
:
 src/systime.h                             |    6 +-
:
 src/termhooks.h                           |    4 -
:
 src/textprop.c                            |    3 +-
:
 src/w32.c                                 |    1 +
:
 src/w32fns.c                              |   50 +-
:
 src/w32font.c                             |  110 +-
:
 src/w32inevt.c                            |    2 +-
:
 src/w32term.c                             |  247 ++-
:
 src/widget.c                              |   39 +-
:
 src/window.c                              |   29 +-
:
 src/xdisp.c                               | 2823 ++++++++++++---------------
:
 src/xfaces.c                              |    7 +-
:
 src/xfns.c                                |  150 +-
:
 src/xfont.c                               |  167 +-
:
 src/xmenu.c                               |   47 +-
:
 src/xml.c                                 |    3 +-
:
 src/xterm.c                               |  239 ++-
:
 src/xterm.h                               |   29 +-
:
 src/xwidget.c                             | 1853 ------------------
:
 src/xwidget.h                             |  115 --
:
 test/ChangeLog                            |  229 ++-
:
 test/automated/cl-lib-tests.el            |  216 ++-
:
 test/automated/eieio-test-methodinvoke.el |    4 +-
:
 test/automated/eieio-test-persist.el      |   17 +-
:
 test/automated/eieio-tests.el             |   57 +-
:
 test/automated/f90.el                     |   16 +
:
 test/automated/finalizer-tests.el         |   83 +
:
 test/automated/generator-tests.el         |  298 +++
:
 test/automated/package-test.el            |   83 +-
:
 test/automated/python-tests.el            |  359 +++-
:
 test/automated/sasl-scram-rfc-tests.el    |   50 +
:
 test/automated/seq-tests.el               |   55 +-
:
 test/automated/tramp-tests.el             |  264 ++-
:
 test/automated/vc-tests.el                |  240 ++-
:
 test/automated/xwidget-tests.el           |  121 --
:
 test/cedet/srecode-tests.el               |    2 +-
:
 test/indent/Makefile                      |    7 +-
:
 test/indent/js-indent-init-dynamic.js     |   30 +
:
 test/indent/js-indent-init-t.js           |   21 +
:
 test/indent/js.js                         |   10 +-
:
 test/indent/ruby.rb                       |    4 +
:
 test/xwidget-test-manual.el               |  204 --
:
 429 files changed, 19954 insertions(+), 13494 deletions(-)
======================================================================

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 05:10:59 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: lele@metapensiero.it, emacs-devel@gnu.org
> 
> I tried to verify this by investigating what changes I stashed last
> week.  But I could not tell the answer, because 'git stash show' gave
> me the output below.

It looks like you've stashed all the changes upstream that the failed
pull brought in, but failed to merge due to your local changes (in
lisp/ChangeLog) that conflicted with the changes upstream.

> Now I am concerned that when I pull again, it will reinstall all of this.

I suggest to unstash them, fix the conflict in lisp/ChangeLog, and
then commit all of that.  Then you should be in sync with upstream and
can pull again.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Sun, 05 Apr 2015 05:10:59 -0400
>> From: Richard Stallman<rms@gnu.org>
>> Cc: lele@metapensiero.it, emacs-devel@gnu.org

Note: I had not seen this mail from Richard when I responded to his 
other one. It does change things a bit.

> It looks like you've stashed all the changes upstream that the failed
> pull brought in, but failed to merge due to your local changes (in
> lisp/ChangeLog) that conflicted with the changes upstream.
>
>> Now I am concerned that when I pull again, it will reinstall all of this.
>
> I suggest to unstash them, fix the conflict in lisp/ChangeLog, and
> then commit all of that.  Then you should be in sync with upstream and
> can pull again.

Yes. At risk of repeating myself: After committing, run

git diff origin/master

which should give you exactly the changes you have written, no more, no 
less. Don't push unless the output looks sane.

– Harald

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 14:54:59 +0200
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> CC: rms@gnu.org, lele@metapensiero.it, stephen@xemacs.org, 
>  emacs-devel@gnu.org
> 
> > I suggest to unstash them, fix the conflict in lisp/ChangeLog, and
> > then commit all of that.  Then you should be in sync with upstream and
> > can pull again.
> 
> Yes. At risk of repeating myself: After committing, run
> 
> git diff origin/master
> 
> which should give you exactly the changes you have written, no more, no 
> less. Don't push unless the output looks sane.

Meanwhile is looks like at least some of those changes were already
pushed, as I see them on master.  So I'm no longer sure what is the
current status of Richard's local repository.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 16:02:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lele@metapensiero.it, stephen@xemacs.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Meanwhile is looks like at least some of those changes were already
> pushed, as I see them on master.  So I'm no longer sure what is the
> current status of Richard's local repository.

The changes pushed include only changes to lisp/ChangeLog.  They don't
include the code changes in rmail.el and in browse-url.el.

My guess would be that these are still stashed, and need to be
unstashed and then pushed.

Re: VC mode and git

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
>> Date: Sun, 05 Apr 2015 16:02:56 +0300
>> From: Eli Zaretskii<eliz@gnu.org>
>> Cc: lele@metapensiero.it, stephen@xemacs.org, rms@gnu.org, emacs-devel@gnu.org
>>
>> Meanwhile is looks like at least some of those changes were already
>> pushed, as I see them on master.

Yay!

>>  So I'm no longer sure what is the
>> current status of Richard's local repository.
>
> The changes pushed include only changes to lisp/ChangeLog.  They don't
> include the code changes in rmail.el and in browse-url.el.

git diff f1cea3e dca743f

– Harald

Re: VC mode and git

[Dmitry Gutov]

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

> The changes pushed include only changes to lisp/ChangeLog.  They don't
> include the code changes in rmail.el and in browse-url.el.

I think they are included, in commits 
414e79feeb445dc141b65767dfc3ba8dbb55723c and 
1a80be15bb1974d454cf37bcd1bd1be64e2cb488.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 16:19:41 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: lele@metapensiero.it, stephen@xemacs.org, hanche@math.ntnu.no,
> 	emacs-devel@gnu.org
> 
> On 04/05/2015 04:12 PM, Eli Zaretskii wrote:
> 
> > The changes pushed include only changes to lisp/ChangeLog.  They don't
> > include the code changes in rmail.el and in browse-url.el.
> 
> I think they are included, in commits 
> 414e79feeb445dc141b65767dfc3ba8dbb55723c and 
> 1a80be15bb1974d454cf37bcd1bd1be64e2cb488.

Right.  I thought I've seen all of the relevant commits, but it turns
out I've missed some.  Sorry.

Re: VC mode and git

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

  > The changes pushed include only changes to lisp/ChangeLog.  They don't
  > include the code changes in rmail.el and in browse-url.el.

'git diff origin/master' showed the changes in all three files.
Then I did git commit and git push.  Why didn't that install them?

I did git pull again, and it told me there was a problem
lisp/ChangeLog again, but there was no conflict in it.
Then I did git commit again.

Then I did git push again, and got this.

    To rms@git.sv.gnu.org:/srv/git/emacs.git
     ! [rejected]        master -> master (non-fast-forward)
    error: failed to push some refs to 'rms@git.sv.gnu.org:/srv/git/emacs.git'
    To prevent you from losing history, non-fast-forward updates were rejected
    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
    'Note about fast-forwards' section of 'git push --help' for details.

I have no idea what that means.

      > My guess would be that these are still stashed, and need to be
      > unstashed and then pushed.

How can I tell?

And if those changes are stashed, why did they show up in git diff?


-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 13:42:44 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: hanche@math.ntnu.no, lele@metapensiero.it, stephen@xemacs.org,
> 	emacs-devel@gnu.org
> 
>   > The changes pushed include only changes to lisp/ChangeLog.  They don't
>   > include the code changes in rmail.el and in browse-url.el.
> 
> 'git diff origin/master' showed the changes in all three files.
> Then I did git commit and git push.  Why didn't that install them?

It did; I was mistaken.  Sorry.

> I did git pull again, and it told me there was a problem
> lisp/ChangeLog again, but there was no conflict in it.
> Then I did git commit again.
> 
> Then I did git push again, and got this.
> 
>     To rms@git.sv.gnu.org:/srv/git/emacs.git
>      ! [rejected]        master -> master (non-fast-forward)
>     error: failed to push some refs to 'rms@git.sv.gnu.org:/srv/git/emacs.git'
>     To prevent you from losing history, non-fast-forward updates were rejected
>     Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>     'Note about fast-forwards' section of 'git push --help' for details.
> 
> I have no idea what that means.

It means you tried to push some commits that are not descendants of
the last commit on savannah.  The savannah repository is configured to
reject such pushes.

What does "git diff origin/master" show now?

And what does "git status -s" show?

>       > My guess would be that these are still stashed, and need to be
>       > unstashed and then pushed.
> 
> How can I tell?

Forget it for now, it was probably my mistake.  Your changes in
rmail.el and browse-url.el are on savannah.  What's left is to find
out why you still get error messages when pushing.

Re: VC mode and git

[Eli Zaretskii]

> Date: Sun, 05 Apr 2015 13:42:44 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: lele@metapensiero.it, stephen@xemacs.org, hanche@math.ntnu.no,
> 	emacs-devel@gnu.org
> 
> 'git diff origin/master' showed the changes in all three files.
> Then I did git commit and git push.  Why didn't that install them?

It did, I see the changes in my local clone of savannah.

> I did git pull again, and it told me there was a problem
> lisp/ChangeLog again, but there was no conflict in it.
> Then I did git commit again.

Try this:

  . copy lisp/ChangeLog to some place safe
  . type "git checkout lisp/ChangeLog"
  . type "git pull"

Does the last "git pull" report any problems?  If so, which ones?

If it doesn't report any problems, what is the diff between
lisp/ChangeLog produced by the "git checkout" command and the copy you
copied to that other place?

Re: VC mode and git

[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 discussing git, claiming that "commit" is anything other than a
  > verb that means "to create a commit object" is what confuses
  > understanding.

If there is no simple way to explain what that operation does, that means
Git is hard to understand.  That is a grave flaw in Git.

If Git requires programmers to adopt a different and complex way of thinking
in order to use it, that is a grave flaw in Git.

I wish Bzr had had continued support so that we could have stayed with
it.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Fri, 03 Apr 2015 07:04:54 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, sorganov@gmail.com, emacs-devel@gnu.org
> 
> If there is no simple way to explain what that operation does, that means
> Git is hard to understand.  That is a grave flaw in Git.

IME, Git _is_ hard to understand, but only if you want to dig deeper
than necessary under the hood.  In this case, I don't think that it's
hard to understand what committing does, because it basically does
what the same operation does in any other VCS -- unless you are
talking about implementation details, like how exact is the commit
data represented on disk etc.

This is not so easy with operations that have no direct equivalents in
other VCSes, or have a significantly different semantics in Git.  The
main problem IME is that most documentation out there describes those
operations inadequately, when seen from the POV of someone who has
deep roots in other VCSes and no need/desire to learn the
implementation details.  So in those cases you have no other way but
make up your own mind and form your own mental model of those
operations, based on what you read and process, and your own
experience.

> If Git requires programmers to adopt a different and complex way of thinking
> in order to use it, that is a grave flaw in Git.

IME, it does require that, but only for workflows that are radically
different from what you are used to.  Workflows that you are used to
don't require a change in your mindset, only to memorize a couple of
new commands and perhaps also customize Git a bit, to conceal some
unnecessary complications and make Git a bit more like the other
VCSes.

> I wish Bzr had had continued support so that we could have stayed with
> it.

Agreed.

Re: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 >   > In discussing git, claiming that "commit" is anything other than a
 >   > verb that means "to create a commit object" is what confuses
 >   > understanding.
 > 
 > If there is no simple way to explain what that operation does, that means
 > Git is hard to understand.  That is a grave flaw in Git.

The explanation you quote is simple.  It is precisely equivalent to
"cons creates a cons [object] from its arguments".  Is that a grave
flaw in Lisp?

Re: VC mode and git

[Sergey Organov]

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

> Richard Stallman writes:
>
>  >   > In discussing git, claiming that "commit" is anything other than a
>  >   > verb that means "to create a commit object" is what confuses
>  >   > understanding.
>  > 
>  > If there is no simple way to explain what that operation does, that means
>  > Git is hard to understand.  That is a grave flaw in Git.
>
> The explanation you quote is simple.  It is precisely equivalent to
> "cons creates a cons [object] from its arguments".  Is that a grave
> flaw in Lisp?

To add to this nice parallel:

To other VCSes Git is what Lisp is to other languages.

To other VCSes Git is what Emacs is to other text editors.

... complains or no complains.

-- Sergey.

Re: VC mode and git

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

  > The explanation you quote is simple.  It is precisely equivalent to
  > "cons creates a cons [object] from its arguments".  Is that a grave
  > flaw in Lisp?

Lisp is a programming language.  What is good in a programming
language is a big nuisance in a version control system.

-- 
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: VC mode and git

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

The word "lie" means an intentional falsehood intended to deceive
people.  It is a grave accusation.

If you mean to say someone was mistaken, please make sure not to use
the word "lie".

-- 
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: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rms@gnu.org,
>     sva-news@mygooglest.com,
>     schwab@suse.de,
>     emacs-devel@gnu.org,
>     mikegerwitz@gnu.org,
>     monnier@iro.umontreal.ca
> Date: Tue, 31 Mar 2015 13:03:33 +0900
> 
> Eli Zaretskii writes:
> 
>  > If it needs to cater to non-experts, let alone people who cannot
>  > afford or be bothered to learn enough of Git, it should also make sure
>  > the repository is left in a state from which it is easy to proceed
>  > with fixing whatever problems are left after backing out the commit.
>  > I'm not sure this is easy.
>  
> "Easy to proceed with fixing" is an impossible standard, when you're
> talking about people who don't follow instructions to the letter and
> probably don't remember exactly what they did.

Depends on the interpretation of "easy", I guess.  I think it should
be possible to define that such that this wouldn't be an impossible
standard.  Basically, the "fixing" part should involve a couple of
simple commands.

> For example, I have no fscking idea how Richard put his workspace
> into a state where git thinks a zillion source files are modified.

I think those are just the files brought by "pull", but not merged due
to conflicts.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Depends on the interpretation of "easy", I guess.  I think it should
 > be possible to define that such that this wouldn't be an impossible
 > standard.  Basically, the "fixing" part should involve a couple of
 > simple commands.

Well, often it will be.  But if you don't put restrictions on the
user's behavior, there's no way to be sure of that, and it's
definitely possible for a user to wedge themselves completely (see
Alan's testimony that some operations related to git completely
obliterated some changes).

What I'm saying is that there's a sensible and precise way to define
the requirement, which is to make commit-and-push atomic.  This
requires that if any part of the operation fails, git must reproduce
the state immediately before the commit (including any staged changes
such as file add).

 > > For example, I have no fscking idea how Richard put his workspace
 > > into a state where git thinks a zillion source files are modified.
 > 
 > I think those are just the files brought by "pull", but not merged due
 > to conflicts.

Yeah, I realized that when Harald pointed it out.  I avoid that in
several ways (frequent pulls are part of it, but more important I stay
committed up locally).

Re: VC mode and git

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

  >   For example, I have no
  > fscking idea how Richard put his workspace into a state where git
  > thinks a zillion source files are modified.  The burden of resolving
  > that should not be placed on git or on the Emacs workflow.

You are arguing from your own ignorance.  Because _you don't know_
what commands did this, you don't _know_ it wasn't my fault, so you
presume it was.

I now offer you a chance to reduce your ignorance.  The only commands
I used, after setting up my local copy, were git pull, C-x v v to
commit, C-x v = and C-x v l.

I don't know any other git commands, aside from clone and checkout.
And now stash, but I didn't use stash until after the problem.

Unless you refuse to read this, your argument from ignorance
is now gone.

-- 
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: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > Unless you refuse to read this, your argument from ignorance is now
 > gone.

I read it.  FYI, it provided no information new to me, and I'm
surprised that you think it would matter to my argument even if it had
been new.

Re: VC mode and git

[Mike Gerwitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 30, 2015 at 17:40:35 +0300, Eli Zaretskii wrote:
>> If a push fails, that does not necessarily indicate a "bad state"---it
>> simply represents that your history is different than what the remote
>> server has, and that the tip of the branch you are pushing to cannot
>> simply be "fast-forwarded" to your commit.
>
> It is "bad" from the POV of someone who started with uncommitted
> changes, and ended with them committed locally, but not pushed
> upstream.  IOW, the command did half the work, and now the user needs
> to use commands she might consider "advanced" to fix that.

I intended to convey that recovery was easy and that it could be easily
rolled back as if commit+push were atomic; there's no need to worry,
- From a scripting perspective, that a push has failed, because such a
thing isn't "bad" in Git.

> We decided some time ago that we don't want to rebase, but to pull
> instead.

It is a pull---`git pull` is simply `git fetch && git merge remote`; its
- --rebase option uses `rebase` instead of `merge`.

Regardless, my apologies---I have only had time to read about 1/3 of the
discussion; this is a rather large thread going on.

> First, no one suggested any automation here.  "C-x v v" is a command
> that is invoked by the user, it doesn't invoke itself.  It could also
> show a warning and ask for confirmation in dubious situations.

The thread I responded to was about a hook, which is a script.

> And second, with VCSes as versatile as Git (and assuming that people
> who use Git in such workflows will at all want to use VC, an
> assumption that proved questionable in this discussion), VC should
> offer to customize its "next action" decisions so as to adapt them to
> a particular workflow.

Yes, that's fine; I suggested that.  But Richard wanted commit+push as
an atomic operation, so only a subset of the commands I provided will be
part of any sort of decision tree.

I'm not arguing for or against it.  I personally do not like the idea of
commit+push as an atomic operation, and would rather see VC treat them
separately, but that's not what I was providing my input on.

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVGizQAAoJEPIruBWO4w6rnI4QAKrGlbIhr+nqEUC6IOf1QNbE
kzuuDVwJC0Yt5kMbeN3cyChd8kp1zn/2iz2CaKgqm6muvMdVZ0elgqFKYhY7P/sw
E34YAaexLY1Xz4YfV5WCoR4S5WuQQ+JpxtQZYrlXdMnW7UFeFdzIbtEP45s8WoU6
DWx/R72uYOU5SICex8Hwsa+CkP7EDJ8hvj3VNbVb2/7bSx8qkBkb3s5P+gkC31tp
eG45R3HbFhchZ5HoAFTKLP3qDl/DoWocWv+6vUdBmVaqSUgwzYYGaGIdIPSoxVUP
DfOxPhLhrLNczZEiZZh07vfqMFlNk2Rhxtt/UmHEJgnteQtsNVmXgVI02y/l1mYP
bFJjL49LIieLphwmGoj3xXj8ZJZR1wqHuqjplLTcVsmlFPml7llf9bIs3kKmuZkc
NfaV4xZgtpnuTnFRa2slfTFlXs6hdGweMeBFokcldbzD/MTTAV1TQ7i9h7KBnI5l
RcTr8BfVgeDsKTMfcT1N2PJrMi69mDrcY1I6aB5CkW4B3tdq2damp0wCItYjZlPY
DaCgJ3VqAYyt7EznPwhfJEP54r5hJuqPPdX0rL97ojD+IOaDsdvKg4lgCMPKjO9v
VMkL5zqD4kl3YnDnXJ09bt2PtxoZRQxWwPAqOgcYkOb3IAajNEX23lWZiBtOuxR1
wkrasN3XLJ/FvpVMc6PE
=go3H
-----END PGP SIGNATURE-----

Re: VC mode and git

[Eli Zaretskii]

> From: Mike Gerwitz <mikegerwitz@gnu.org>
> Cc: sva-news@mygooglest.com,  schwab@suse.de,  emacs-devel@gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca
> Date: Tue, 31 Mar 2015 01:12:47 -0400
> 
> > We decided some time ago that we don't want to rebase, but to pull
> > instead.
> 
> It is a pull---`git pull` is simply `git fetch && git merge remote`; its
> - --rebase option uses `rebase` instead of `merge`.

Yes, and that's exactly what we decided to avoid, because it has bad
effects if one merges from another branch and then wants to push.

Re: VC mode and git

[Dmitry Gutov]

On 03/27/2015 11:06 AM, Eli Zaretskii wrote:

>> This is a flawed concept.  You are throwing away the very advantage of a
>> DVCS.
>
> Isn't it clear, after all the flood of the messages, that Richard has
> no use for those advantages?

Considering the amount of time he spends offline, no, it's not at all clear.

Creating commits locally and then merging or rebasing before pushing 
could be helpful in these conditions, provided one learns how to use Git 
properly.

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 16:07:50 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: sva-news@mygooglest.com, rms@gnu.org, emacs-devel@gnu.org
> 
> On 03/27/2015 11:06 AM, Eli Zaretskii wrote:
> 
> >> This is a flawed concept.  You are throwing away the very advantage of a
> >> DVCS.
> >
> > Isn't it clear, after all the flood of the messages, that Richard has
> > no use for those advantages?
> 
> Considering the amount of time he spends offline, no, it's not at all clear.

Richard is traveling for many years.  Ask yourself what he did when
Emacs used CVS.

Re: VC mode and git

[Dmitry Gutov]

On 03/27/2015 04:17 PM, Eli Zaretskii wrote:

>> Considering the amount of time he spends offline, no, it's not at all clear.
>
> Richard is traveling for many years.  Ask yourself what he did when
> Emacs used CVS.

And initially, Emacs used no version control system at all, with 
apparent success. Does that mean that Richard had no use for CVS?

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 16:57:07 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: schwab@suse.de, sva-news@mygooglest.com, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> On 03/27/2015 04:17 PM, Eli Zaretskii wrote:
> 
> >> Considering the amount of time he spends offline, no, it's not at all clear.
> >
> > Richard is traveling for many years.  Ask yourself what he did when
> > Emacs used CVS.
> 
> And initially, Emacs used no version control system at all, with 
> apparent success. Does that mean that Richard had no use for CVS?

Before CVS, Emacs used RCS.

Re: VC mode and git

[Dmitry Gutov]

On 03/27/2015 05:16 PM, Eli Zaretskii wrote:

> Before CVS, Emacs used RCS.

Does that invalidate my point?

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 17:33:44 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: schwab@suse.de, sva-news@mygooglest.com, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> On 03/27/2015 05:16 PM, Eli Zaretskii wrote:
> 
> > Before CVS, Emacs used RCS.
> 
> Does that invalidate my point?

What _is_ your point?

Re: VC mode and git

[Dmitry Gutov]

On 03/27/2015 05:37 PM, Eli Zaretskii wrote:

> What _is_ your point?

That "Richard has no use for [DVCS] advantages" is not true, or doesn't 
have to be. Working offline a lot is a prime use case for making commits 
locally.

But if he intends to continue to only contribute minor changes from time 
to time, the improvement, of course, will be minor as well.

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 19:10:50 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: schwab@suse.de, sva-news@mygooglest.com, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> On 03/27/2015 05:37 PM, Eli Zaretskii wrote:
> 
> > What _is_ your point?
> 
> That "Richard has no use for [DVCS] advantages" is not true, or doesn't 
> have to be.

I think it is true, but you can also ask him directly.

Re: VC mode and git

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

I have no use for the advantages of DVCS because what I do on Emacs is
simple.  The things I do are things that were easy in CVS.

If I were doing heavier work on Emacs, perhaps I would find DVCS
beneficial.  But that is unlikely to happen.


-- 
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: VC mode and git

[Sven Axelsson]

On 27 March 2015 at 15:57, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 03/27/2015 04:17 PM, Eli Zaretskii wrote:
>
>>> Considering the amount of time he spends offline, no, it's not at all
>>> clear.
>>
>>
>> Richard is traveling for many years.  Ask yourself what he did when
>> Emacs used CVS.
>
>
> And initially, Emacs used no version control system at all, with apparent
> success. Does that mean that Richard had no use for CVS?
>

As an interested bystander, I'm wondering if a lot of Emacs development
is driven by mr. Stallmans personal needs? Some previous threads
regarding WYSIWYG publishing functionality springs to mind.

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: VC mode and git

[Eli Zaretskii]

> Date: Fri, 27 Mar 2015 16:16:29 +0100
> From: Sven Axelsson <sven.axelsson@gmail.com>
> 
> As an interested bystander, I'm wondering if a lot of Emacs development
> is driven by mr. Stallmans personal needs?

Emacs development is driven, among other factors, by user requests for
features.  Requests from users who have contributed a lot to Emacs
development (to put that mildly) naturally have more weight.

Re: VC mode and git

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

  > Creating commits locally and then merging or rebasing before pushing 
  > could be helpful in these conditions, provided one learns how to use Git 
  > properly.

I can't afford to learn that much about Git
for things I would do very rarely.  It works fine if I only
commit when I want to change Savannah.

-- 
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: VC mode and git

[Daniel Colascione]

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

On 03/27/2015 02:06 AM, Eli Zaretskii wrote:
>> From: Andreas Schwab <schwab@suse.de>
>> Date: Fri, 27 Mar 2015 08:48:53 +0100
>> Cc: sva-news@mygooglest.com, emacs-devel@gnu.org
>>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> I mean, a commit that goes to the remote repository
>>
>> This is a flawed concept.  You are throwing away the very advantage of a
>> DVCS.
> 
> Isn't it clear, after all the flood of the messages, that Richard has
> no use for those advantages?  Why cannot he have a VC feature, which
> should be optional, to do what he want under certain circumstances and
> given specific customizations?  This _is_ Emacs, after all, isn't it?

I don't think I've seen a user option I didn't like. If Richard or
somebody else wants to send a patch that makes vc operate this workflow,
great. I get the impression that Richard wants to make his preferred
mode of operation the default, however, and that I'm strongly against.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VC mode and git

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Isn't it clear, after all the flood of the messages, that Richard has
> no use for those advantages?  Why cannot he have a VC feature, which
> should be optional, to do what he want under certain circumstances and
> given specific customizations?  This _is_ Emacs, after all, isn't it?

I think that having such a feature optional, and not enabled by default,
wouldn't be nearly as controversial as having it be the default
behaviour.

(I doubt there would be many people actually using it, though)

Re: VC mode and git

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

  > This is a flawed concept.  You are throwing away the very advantage of a
  > DVCS.

Our recommendations for using Bzr with Emacs "threw away" the
same advantage, by directing people to make a bound branch.
Apparently that wasn't a big loss.

-- 
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: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > Our recommendations for using Bzr with Emacs "threw away" the
 > same advantage, by directing people to make a bound branch.
 > Apparently that wasn't a big loss.

Actually, you omit important history.  Karl Fogel and I wrote a modern
workflow (one which is used successfully by many many developers in
projects using DVCSes), you and Ken'ichi screamed, Eli rewrote it to
look like CVS.  Fortunately, you guys were quite late to the party,
and everybody else either used a DVCS-enhanced workflow already, or
read the original BzrForEmacsDevs with the DVCS-enhanced workflow.

So we'll actually never know whether the current version of
BzrForEmacsDevs was a bad idea in general.  But you should be aware
that it is very much adapted to a very small number of Emacs voices
with disproportionate weight.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 29 Mar 2015 07:05:49 +0900
> Cc: sva-news@mygooglest.com, Andreas Schwab <schwab@suse.de>,
> 	emacs-devel@gnu.org
> 
> Richard Stallman writes:
> 
>  > Our recommendations for using Bzr with Emacs "threw away" the
>  > same advantage, by directing people to make a bound branch.
>  > Apparently that wasn't a big loss.
> 
> Actually, you omit important history.  Karl Fogel and I wrote a modern
> workflow (one which is used successfully by many many developers in
> projects using DVCSes), you and Ken'ichi screamed, Eli rewrote it to
> look like CVS.

That's a far cry from what really happen, to put it mildly.  I suggest
that you refresh your memory by re-reading the relevant discussions
from back there.

Re: VC mode and git

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

  > Actually, you omit important history.

I don't remember it, so I will take your word that things happened as
you say.

					   Karl Fogel and I wrote a modern
  > workflow (one which is used successfully by many many developers in
  > projects using DVCSes),

Felicitations for them, but why should that be relevant to this issue.
There is a reason why some people like that workflow, and a reason why
it screwed me.

			    you and Ken'ichi screamed, Eli rewrote it to
  > look like CVS.

Thank you, Eli.

  >   Fortunately, you guys were quite late to the party,
  > and everybody else either used a DVCS-enhanced workflow already, or
  > read the original BzrForEmacsDevs with the DVCS-enhanced workflow.

If that happened, what is fortunate about it?  You seem to be
campaigning to make people stop using CVS-style workflow, even if
it is good for them.

We can see that also in the sneer-word "modern", which is further
name-calling.

-- 
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: VC mode and git

[Eli Zaretskii]

> Date: Sun, 29 Mar 2015 10:33:35 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org
> 
> 					   Karl Fogel and I wrote a modern
>   > workflow (one which is used successfully by many many developers in
>   > projects using DVCSes),
> 
> Felicitations for them, but why should that be relevant to this issue.
> There is a reason why some people like that workflow, and a reason why
> it screwed me.
> 
> 			    you and Ken'ichi screamed, Eli rewrote it to
>   > look like CVS.
> 
> Thank you, Eli.

You are welcome.  But Stephen's version of history is far from what
really happened.  In particular, the CVS-like workflow was written by
Óscar Fuentes, not myself.  And the other workflow, the one written by
Karl and Stephen, suggested a bound branch from the get-go, AFAIR
(although I cannot prove that now, since the Wiki didn't keep the old
versions, and even the Wayback machine only has those instructions
since about a year after they were first published).

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > And the other workflow, the one written by Karl and Stephen,
 > suggested a bound branch from the get-go,

It did, but I don't see your point.  The bound branch was used only
for collecting commits; it was intended to be a perfect mirror of the
remote (public) repository at all times.  In that sense it plays a
role similar to git's remote tracking branch, although the mechanics
and timing of synchronization are rather different.  The fact that it
was bound was a convenience.  (It eliminated a "push" that would
otherwise have been necessary.  But it is easy to implement the same
basic workflow without bound branches.  I use it in Mercurial
workspaces, for example.)  But you didn't edit files in that branch.

In a CVS-like workflow, on the other hand, one works "in" the bound
branch.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rms@gnu.org,
>     sva-news@mygooglest.com,
>     schwab@suse.de,
>     emacs-devel@gnu.org
> Date: Mon, 30 Mar 2015 03:05:00 +0900
> 
> Eli Zaretskii writes:
> 
>  > And the other workflow, the one written by Karl and Stephen,
>  > suggested a bound branch from the get-go,
> 
> It did, but I don't see your point.

You said, repeatedly, that the original instructions didn't use a
bound branch, but instead described a "truly distributed workflow".
That's factually incorrect.  You said, repeatedly, that the bound
branch and the rest of BzrForEmacsDevs was written by me, because
"Richard, Eli, and Handa screamed".  That's factually incorrect, and
tells a story that is very different from what really happened: you
and Karl were the authors, and my changes were late and purely
editorial.

> The bound branch was used only for collecting commits; it was
> intended to be a perfect mirror of the remote (public) repository at
> all times.

That was what you wanted it to be, but it turned out Bazaar didn't
support such "bare" bound branches, so you were forced to change the
instructions for the branch to have a tree.  Or something to that
effect -- the main point here is that the instructions were amended
because of a missing feature in Bazaar, not because someone
"screamed" for fear of distributed workflows.

> In a CVS-like workflow, on the other hand, one works "in" the bound
> branch.

We worked in the bound branch for one-off changes as well.  You just
misremember, that's all.  The CVS-like workflow was born out of
discussions, when Richard asked about something like that, and Óscar
sat down and wrote it.  That workflow basically omitted the
description of feature branches and a few other "advanced" issues.

Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > You said, repeatedly, that the original instructions didn't use a
 > bound branch, but instead described a "truly distributed workflow".
 > That's factually incorrect.

The latter part of the first sentence still is true; the workflow we
described was truly distributed.  That you lump them together in one
statement as "factually incorrect" suggests that you really don't
understand what you're talking about.

In any case, Richard has seen the light and backed all the way down to
a warning (which is not worth arguing against) and implementation of
the missing vc-push command (which is a good idea).  There's no point
in continuing theoretical discussions just for you and Richard, who
simply don't want to hear them.

Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rms@gnu.org,
>     sva-news@mygooglest.com,
>     schwab@suse.de,
>     emacs-devel@gnu.org
> Date: Mon, 30 Mar 2015 09:50:39 +0900
> 
> Eli Zaretskii writes:
> 
>  > You said, repeatedly, that the original instructions didn't use a
>  > bound branch, but instead described a "truly distributed workflow".
>  > That's factually incorrect.
> 
> The latter part of the first sentence still is true; the workflow we
> described was truly distributed.

That description survived mostly with no changes to this day, so if it
described a distributed workflow, it still does.  Nothing's changed.
Therefore, saying that you needed to give up the distributed workflow
due to complaints is inconsistent with the facts.

> That you lump them together in one statement as "factually
> incorrect" suggests that you really don't understand what you're
> talking about.

I think the problem is that you misunderstood what I was saying.

Re: VC mode and git

[Stephen J. Turnbull]

Richard Stallman writes:

 > 					   Karl Fogel and I wrote a modern
 >   > workflow (one which is used successfully by many many developers in
 >   > projects using DVCSes),
 > 
 > Felicitations for them, but why should that be relevant to this issue.

It's relevant because Emacs needed a DVCS, many Emacs developers
needed a distributed workflow, there are *many* possible workflows,
and it made sense to describe one that is proven to be successful and
adapted to the needs of a great many developers in some very active
projects.  Describing several is known to confuse people, and worse,
they often try to pick and choose parts of different workflows without
understanding them.

 > There is a reason why some people like that workflow, and a reason
 > why it screwed me.

You seem to be confused here.  The popular workflow referred to above
has nothing to do with the GitForEmacsDevs workflow as far as I know
(I had nothing to do with GitForEmacsDevs).  And it wasn't the
GitForEmacsDevs workflow that screwed you, either, as you yourself
testify that you didn't follow it accurately at least in respect of
pushing after committing.  Evidently you were using some homebrew
workflow that may, or may not, have closely resembled GitForEmacsDevs.

 >   >   Fortunately, you guys were quite late to the party,
 >   > and everybody else either used a DVCS-enhanced workflow already, or
 >   > read the original BzrForEmacsDevs with the DVCS-enhanced workflow.
 > 
 > If that happened, what is fortunate about it?  You seem to be
 > campaigning to make people stop using CVS-style workflow, even if
 > it is good for them.

Make existing users stop, no, I think you are confusing me with ESR
(among others).  I don't care if you change, that's your decision to
make.  Since you evidently are no longer an active developer, I don't
even really see any advantages for anybody in you switching to a
distributed workflow.  But you're a very unusual case.

Discourage new developers from using CVS-style workflows, and
encourage developers who have not yet tried distributed workflow to
try it, yes, I do intend that.

The CVS-style workflow may be good for some individuals.  In your
case, a long-standing workflow that doesn't seem to benefit from local
commits, and you have a privileged position: no one is going to tell
you not to commit whatever you want to commit to mainline.  And you're
used to waiting for a window to commit.  It's perfect for you.

That isn't true of most Emacs developers, especially those working on
more extensive changes -- most prefer *not* to check in to the public
repository until they have a beta-quality complete change, but they
*do* want to commit so they can move on to another task (perhaps
related and intended to be pushed at the same time, perhaps not).  A
distributed workflow gives them the benefits of version control
without interfering with the project mainline or vice versa, until
they're ready to integrate.

Furthermore, having most developers on a distributed workflow is a lot
less frustrating during peak periods such as just before a feature
freeze.  I remember well the annoyance of having somebody commit just
as I was ready to do so, and having to resolve a pile of irrelevant
conflicts in files I wasn't ready to commit just to make CVS happy.[1]
Worse, a developer would often have a queue of patches, and commit
them one after another at several minutes interval between commits.
In a DVCS, you can commit at will with intervals of seconds, minutes,
or hours, but the push always takes the same amount of time, normally
a few seconds.  Your push may still fail, and you'll need to merge
locally and try again, but the windows for successful push are longer.

 > We can see that also in the sneer-word "modern", which is further
 > name-calling.

"Modern" in my usage above simply means "adapted to tools developed
more recently than CVS."  I live in Asia, where tradition is
appreciated and "modern" is not necessarily a compliment, and
certainly didn't mean to sneer at your use of VCS.

Footnotes: 
[1]  I never used svn in anger, it might be better in this respect.
But in CVS it could be a real PITA.

Re: VC mode and git

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

  >  > Felicitations for them, but why should that be relevant to this issue.

  > It's relevant because Emacs needed a DVCS, many Emacs developers
  > needed a distributed workflow, there are *many* possible workflows,
  > and it made sense to describe one that is proven to be successful and
  > adapted to the needs of a great many developers in some very active
  > projects.

That was fine, for the people who wanted to use it, but it has
nothing to do with my usage.

  > You seem to be confused here.  The popular workflow referred to above
  > has nothing to do with the GitForEmacsDevs workflow as far as I know

That's why it has nothing to do with my usage.

						 And it wasn't the
  > GitForEmacsDevs workflow that screwed you, either, as you yourself
  > testify that you didn't follow it accurately at least in respect of
  > pushing after committing.

I thought I was following it -- but I forgot that it said
to do a push.  It was months from when I read that file to when
I actually built the latest version, and then weeks before
I tried to commit changes.

-- 
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: VC mode and git

[Stefan Monnier]

> I think that C-x v v, when it commits changes, should also push them.

No, instead VC should offer a vc-push command.

> This would make git more comparable to other version control systems.

You mean like Bazaar, Mercurial, etc... who also distinguish between
"commit" and "push"?

> Does anyone see a reason not to?

That would try to pretend that we still live in the CVS days, but these
days are gone.  The new normal is to commit and push separately (even
if Bazaar provides the notion of "bound" branch to try and let you
pretend that they're not separate).


        Stefan

Re: VC mode and git

[Stephen J. Turnbull]

Stefan Monnier writes:

 > That would try to pretend that we still live in the CVS days, but these
 > days are gone.

Richard, and quite probably other long-time contributors, still does
live in the CVS days in an important sense.

 > The new normal is to commit and push separately

True, but not relevant to Emacs, which intends to support users, not
norms.

Perhaps rather than assuming a universal meaning for DWIM, C-x v v
could implement a limited concept of "workflow".  Eg, a workflow could
be modeled by a list ((LEXP1 OP1) (LEXP2 OP2) ...), and the workflow
would be implemented something like

    (catch 'done
      (mapc (lambda (kv)
              (let ((lexp (first kv))
                    (op (second kv)))
                (if (eval lexp) (throw (funcall op)))))))

A couple of default workflows could be provided.

Re: VC mode and git

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Perhaps rather than assuming a universal meaning for DWIM, C-x v v
> could implement a limited concept of "workflow".  Eg, a workflow could
> be modeled by a list ((LEXP1 OP1) (LEXP2 OP2) ...), and the workflow
> would be implemented something like
> 
>     (catch 'done
>       (mapc (lambda (kv)
>               (let ((lexp (first kv))
>                     (op (second kv)))
>                 (if (eval lexp) (throw (funcall op)))))))
> 
> A couple of default workflows could be provided.

That sounds like lots of complexity for small gain to me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: VC mode and git

[Stephen J. Turnbull]

Eric S. Raymond writes:
 > Stephen J. Turnbull <stephen@xemacs.org>:
 > > Perhaps rather than assuming a universal meaning for DWIM, C-x v v
 > > could implement a limited concept of "workflow".  Eg, a workflow could
 > > be modeled by a list ((LEXP1 OP1) (LEXP2 OP2) ...), and the workflow
 > > would be implemented something like
 > > 
 > >     (catch 'done
 > >       (mapc (lambda (kv)
 > >               (let ((lexp (first kv))
 > >                     (op (second kv)))
 > >                 (if (eval lexp) (throw (funcall op)))))))
 > > 
 > > A couple of default workflows could be provided.
 > 
 > That sounds like lots of complexity for small gain to me.

The complexity is already there, it's just hardwired and inflexible,
and would become much more complex for not so much flexiblity if you
provide a couple of optional hardwired workflows.

But I'm not volunteering to implement and maintain either, so I guess
the point is moot.

Re: VC mode and git

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

  > > This would make git more comparable to other version control systems.

  > You mean like Bazaar, Mercurial, etc... who also distinguish between
  > "commit" and "push"?

I used Bzr a few months ago, and my commits were pushed automatically.
I never did an explicit push.

-- 
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: VC mode and git

[Stefan Monnier]

> I used Bzr a few months ago, and my commits were pushed automatically.
> I never did an explicit push.

That's because you used a "bound branch", which is a Bazaar feature that
lets you say that in this branch "bzr commit" should do both a commit
and a push.

For some reason, Git hasn't acquired such a feature yet.
[ I'd love such a feature, especially if the destination of this
  auto-push can be different from the destination of a plain "git push",
  since that then allows to keep a remote copy of your local repository
  in sync.  ]


        Stefan

Re: VC mode and git

[David Engster]

Stefan Monnier writes:
>> I used Bzr a few months ago, and my commits were pushed automatically.
>> I never did an explicit push.
>
> That's because you used a "bound branch", which is a Bazaar feature that
> lets you say that in this branch "bzr commit" should do both a commit
> and a push.
>
> For some reason, Git hasn't acquired such a feature yet.
> [ I'd love such a feature, especially if the destination of this
>   auto-push can be different from the destination of a plain "git push",
>   since that then allows to keep a remote copy of your local repository
>   in sync.  ]

Put whatever push command you like into .git/hooks/post-commit.

-David

Re: VC mode and git

[Stefan Monnier]

>> You mean like Bazaar, Mercurial, etc... who also distinguish between
>> "commit" and "push"?
> I used Bzr a few months ago, and my commits were pushed automatically.
> I never did an explicit push.

And yet, Bzr does distinguish between "commit" and "push".


        Stefan

Re: VC mode and git

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> I think that C-x v v, when it commits changes, should also push them.
> This would make git more comparable to other version control systems.

This completely breaks with the way git is expected to work.

> Does anyone see a reason not to?

Yes.

 1. There may not be an upstream branch to push to, if this is a purely
    local branch
 2. The local git may not be able to contact the upstream server at the
    commit time (the commit may be done offline or behind a firewall)
 3. I may not want to push immediately, because what I do from a single
    file is a partial part of the changes and they need to be complete
    to work, so then I push when I have committed all of them and after
    I've done a bit of testing
 4. I may not want to push immediately for different reasons (I'm
    waiting for someone else's changes to be committed and plan to merge
    them into mine, before publishing them to someone else)

In short: git is distributed, this is a great advantage, and any move to
force it into a centralized workflow should be um... discouraged.

Re: VC mode and git

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 25 Mar 2015 09:40:04 +0100
> 
> In short: git is distributed, this is a great advantage, and any move to
> force it into a centralized workflow should be um... discouraged.

Let's keep this in its true proportions: there's nothing centralized
in a "git push".

Re: VC mode and git

[Mark H Weaver]

Richard Stallman <rms@gnu.org> writes:
> I think that C-x v v, when it commits changes, should also push them.

If this change were made, many git users would accidentally push commits
that they hadn't intended to push.  Git users have a strong expectation
that "committing" means only "to save locally in my private repo".

It is common practice for Git users to make commits locally and then to
post those commits to a mailing list for review before pushing.  It is
also common to create several commits locally before they are fully
tested, before pushing.

To make matters worse, pushing to a public repo is usually an
irreversible operation.  Often the best that can be done is to "revert"
it, which means to add another commit that reverses the changes made in
the first commit.  Both remain in the commit log forever, which is a
permanent embarrassment for whomever made the erroneous push.

If your proposal were accepted, and it caused me to accidentally push a
commit to a public repo, I would be _very_ angry at the Emacs developers
for doing such a thing.  I would lose trust in Emacs.

      Mark