In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[John Yates]

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

On Tue, Jul 4, 2017 at 7:05 PM, Richard Stallman <rms@gnu.org> wrote:

> I wish someone would write a package comparable to Magit that
> we could get legal papers for and include it in Emacs.
>

​Richard,

I cannot let this go without commenting.  Do you understand what
you are advocating?

In Jonas you have someone who is doing just about everything
right per your notion of software freedom including applying gpl v3.
He has made significant personal sacrifices to provide emacs with
a package that is unique among editors and IDEs.  It could emerge
as one of those oh-so-elusive creatures: a true killer app for the
emacs platform.

Jonas has and continues to deliver a steady stream of features,
bug fixes and refinements.  Magit is clearly a work of love that is
wonderfully supported.  Jonas has exhibited admirable project
leadership skill and has published a detailed, credible map to
the future:

  https://github.com/magit/magit/projects/1

Some of us care enough about developers like Jonas and the
value he is delivering to emacs that we have responded to his
plea for financial support via PayPal, Patreon or Bountysource.

Were Jonas' effort invested in a non-GNU project, or at least not
one so dear to you heart as emacs, I suspect that you would
applaud his work.

Instead you seem to advocate undercutting Jonas' efforts with
no good reason to believe that you would get a replacement of
anywhere near the same quality.  Further, were you actually to
mount such a competing effort I am confident that long before it
ever delivered any useful amount of functionality you, the emacs
community, and the gnu effort would harvest significant bad press.

Sometimes community might be more important than copyright
assignment.  Please reconsider you request.

/john

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

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Kaushal Modi]

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

Adding my support.

On Wed, Jul 5, 2017 at 11:30 AM John Yates <john@yates-sheets.org> wrote:

> In Jonas you have someone who is doing just about everything
> right per your notion of software freedom including applying gpl v3.
> He has made significant personal sacrifices to provide emacs with
> a package that is unique among editors and IDEs.  It could emerge
> as one of those oh-so-elusive creatures: a true killer app for the
> emacs platform.
>
> Jonas has and continues to deliver a steady stream of features,
> bug fixes and refinements.  Magit is clearly a work of love that is
> wonderfully supported.  Jonas has exhibited admirable project
> leadership skill and has published a detailed, credible map to
> the future:
>
>   https://github.com/magit/magit/projects/1
>

In addition, the Magit project is an epitome of elisp projects; it has a
wonderful Info manual with source code in Org (yes, I am aware of RMS'
views on Org mode), tests!, active support by Jonas and other key Magit
developers in bug fixing and providing solutions to user-specific flows,
etc.

Some of us care enough about developers like Jonas and the
> value he is delivering to emacs that we have responded to his
> plea for financial support via PayPal, Patreon or Bountysource.
>

Me too.


> Sometimes community might be more important than copyright
> assignment.  Please reconsider you request.
>

+1
-- 

Kaushal Modi

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

Re: In support of Jonas Bernoulli's Magit

[Óscar Fuentes]

I'm afraid that you guys are missing the point. This has no relation
with the maintainer of Magit, but with the fact that Magit cannot be
distributed with Emacs.

Re: In support of Jonas Bernoulli's Magit

[Kaushal Modi]

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

On Wed, Jul 5, 2017 at 12:24 PM Óscar Fuentes <ofv@wanadoo.es> wrote:

> I'm afraid that you guys are missing the point. This has no relation
> with the maintainer of Magit, but with the fact that Magit cannot be
> distributed with Emacs.
>

So the proposed solution should be to help figure out how to make that
happen instead of proposing a rewrite of the whole project.
-- 

Kaushal Modi

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

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

> I'm afraid that you guys are missing the point.  This has no relation
> with the maintainer of Magit, but with the fact that Magit cannot be
> distributed with Emacs.

I'm afraid you're missing the point: distributing Magit with Emacs is
not terribly important, compared to fostering good relationships.

BTW, if we want to distribute something like Magit with Emacs, there's
no need to write a replacement: we can simply include Magit itself,
since the license allows us to do so.
The only hurdle is the one *we* (Emacs maintainers) put.


        Stefan

Re: In support of Jonas Bernoulli's Magit

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm afraid that you guys are missing the point.  This has no relation
>> with the maintainer of Magit, but with the fact that Magit cannot be
>> distributed with Emacs.
>
> I'm afraid you're missing the point: distributing Magit with Emacs is
> not terribly important, compared to fostering good relationships.

This is your personal opinion, not the policy exercised by the Emacs
project on recent times (see bzr, clang for two glaring examples).

Besides, "fostering good relations" on this case is a bit of a red
herring, since IIRC the current Magit maintainer is quite collaborative
with the Emacs core maintainers and, anyways, enriching Emacs itself is
more important than having good relations with a single individual.

> BTW, if we want to distribute something like Magit with Emacs, there's
> no need to write a replacement: we can simply include Magit itself,
> since the license allows us to do so.
> The only hurdle is the one *we* (Emacs maintainers) put.

Was that hurdle put by the Emacs maintainer or by the GNU governance?

Re: In support of Jonas Bernoulli's Magit

[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'm afraid that you guys are missing the point. This has no relation
  > with the maintainer of Magit, but with the fact that Magit cannot be
  > distributed with Emacs.

You've hit the nail on the head.  I am not saying anything either good
or bad about Magit as such, because that's not the issue here.

We have a problem in Emacs: it doesn't contain a good interface to
git.  People often recommend something that is not in Emacs.  That's
not a good situation.  I want to fix it.

In principle, we could fix it with Magit.  I would be very glad if we
did.  That would require tracking down lots of people and convincing
them to sign the legal papers, and maybe replacing some pieces of code
whose authors didn't sign.

A year ago, more or less, I asked people if we could do this and I was
told it was impossible.

If we don't fix it with Magit, we need something else to fix it with.
So I asked people to build a suitable something else.

However, if there is now a real possibility of putting Magit into
Emacs, of course I would like to do it that way.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Clément Pit-Claudel]

On 2017-07-05 19:03, Richard Stallman wrote:
> That would require tracking down lots of people and convincing
> them to sign the legal papers, and maybe replacing some pieces of code
> whose authors didn't sign.

Or we could make a one-time exception to our copyright paper's policy for Magit.  That may not be easy either, but it might be done.

This does not necessarily mean dropping the requirement to get legal papers.  It could mean re-evaluating the legal papers process, instead, to ensure that it can be conducted entirely online.  There was a bit of discussion on that topic in the past, and this push to get legal papers for Magit could be a good occasion to revisit it.

Concretely, the proposal would be to work with the FSF's lawyers to set up an entirely-online copyright assignment process, with no need to email assign@gnu.org.  "Getting legal papers from 100 Magit contributors" sounds a lot more scary than "getting 100 magit contributors to click through the FSF's CLA" (Contributor's License Agreement).

Re: In support of Jonas Bernoulli's Magit

[Glenn Morris]

Clément Pit-Claudel wrote:

> It could mean re-evaluating the legal papers process, instead, to
> ensure that it can be conducted entirely online. There was a bit of
> discussion on that topic in the past, and this push to get legal
> papers for Magit could be a good occasion to revisit it.

Do you not imagine that the FSF appreciates that completing the
assignment process is an issue for some people, and have already made it
as simple as the legal system allows?

https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signatures-for-copyright-assignments-from-italy

"We are always working on ways to make assignment itself simpler."

Re: In support of Jonas Bernoulli's Magit

[Clément Pit-Claudel]

On 2017-07-05 21:46, Glenn Morris wrote:
> Do you not imagine that the FSF appreciates that completing the 
> assignment process is an issue for some people,

Which part of my email made you think that I didn't?

> and have already made it as simple as the legal system allows?

No, I don't imagine this, in part because Richard did in the past support the idea of setting up an online form (to let people submit the info normally sent to assign@gnu.org).  Is it silly to imagine that this may not be a top priority item?  Or that volunteer efforts could help streamline the process further?

Clément.

Re: In support of Jonas Bernoulli's Magit

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

  > No, I don't imagine this, in part because Richard did in the past
  > support the idea of setting up an online form (to let people
  > submit the info normally sent to assign@gnu.org).

I am in favor of it, in principle, but whether we can do it depends
on legal issues.  Whether the papers are legally valid without a
hand-written signature (physical, or scanned) in a given country,
for instance.

Other kinds of changes in the bureaucracy are easier to make
because they depend only on us.  It might be possible for
volunteers to help with some of the implementation work.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Jean-Christophe Helary]

> On Jul 6, 2017, at 10:46, Glenn Morris <rgm@gnu.org> wrote:
> 
> Clément Pit-Claudel wrote:
> 
>> It could mean re-evaluating the legal papers process, instead, to
>> ensure that it can be conducted entirely online. There was a bit of
>> discussion on that topic in the past, and this push to get legal
>> papers for Magit could be a good occasion to revisit it.
> 
> Do you not imagine that the FSF appreciates that completing the
> assignment process is an issue for some people, and have already made it
> as simple as the legal system allows?
> 
> https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signatures-for-copyright-assignments-from-italy

That was 18 months ago and in the meanwhile I was able to scan a signed document and send it as a PDF. from Japan. There are still lags in the process, mostly because some parts don't seem to be automatized.

Jean-Christophe 

Re: In support of Jonas Bernoulli's Magit

[Philippe Vaucher]

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

>
> This does not necessarily mean dropping the requirement to get legal
> papers.  It could mean re-evaluating the legal papers process, instead, to
> ensure that it can be conducted entirely online.  There was a bit of
> discussion on that topic in the past, and this push to get legal papers for
> Magit could be a good occasion to revisit it.
>

I second this. If the process could have been done entirely online, I would
have contributed *much* earlier. Things need to be "easy", we programmers
are lazy ;-)

Philippe

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

Re: In support of Jonas Bernoulli's Magit

[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 second this. If the process could have been done entirely online, I would
  > have contributed *much* earlier. Things need to be "easy", we programmers
  > are lazy ;-)

We have to get a signature that makes for a legally valid contract.
Among the methods that are legally adequate, in any given country, we
try to make it as convenient as possible.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Glenn Morris]

Richard Stallman wrote:

> We have a problem in Emacs: it doesn't contain a good interface to
> git. 

I get on just fine with Emacs VC and git. It enables me to do just what
I did with other VCS in Emacs, and I appreciate the uniformity of
interface. Obviously, many people prefer a more featureful interface to
git's many bells and whistles, and that's fine. But IMO your statement
is an exaggeration.

Re: In support of Jonas Bernoulli's Magit

[Ted Zlatanov]

On Wed, 05 Jul 2017 21:50:23 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Richard Stallman wrote:
>> We have a problem in Emacs: it doesn't contain a good interface to
>> git. 

GM> I get on just fine with Emacs VC and git. It enables me to do just what
GM> I did with other VCS in Emacs, and I appreciate the uniformity of
GM> interface. Obviously, many people prefer a more featureful interface to
GM> git's many bells and whistles, and that's fine. But IMO your statement
GM> is an exaggeration.

Agreed. Magit in particular adds a steep learning curve to Git's. It's
good software and fun to use, but it's definitely not a good *general*
interface (which I'm assuming RMS meant).

Ted

Re: In support of Jonas Bernoulli's Magit

[Kaushal Modi]

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

On Thu, Jul 6, 2017 at 10:12 AM Ted Zlatanov <tzz@lifelogs.com> wrote:

> Agreed. Magit in particular adds a steep learning curve to Git's.


I felt just the contrary. I would have never used hunk-based staging,
cherry-picking, interactive rebasing (re-ordering, squashing, amending
commits older than HEAD, etc) had I not come across Magit.

(It's so convenient that I can commit stuff to Org mode repo using Magit on
my phone as ssh port is blocked at work.)


> It's
> good software and fun to use, but it's definitely not a good *general*
> interface (which I'm assuming RMS meant).
>
-- 

Kaushal Modi

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

Re: In support of Jonas Bernoulli's Magit

[Óscar Fuentes]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 05 Jul 2017 21:50:23 -0400 Glenn Morris <rgm@gnu.org> wrote: 
>
> GM> Richard Stallman wrote:
>>> We have a problem in Emacs: it doesn't contain a good interface to
>>> git. 
>
> GM> I get on just fine with Emacs VC and git. It enables me to do just what
> GM> I did with other VCS in Emacs, and I appreciate the uniformity of
> GM> interface. Obviously, many people prefer a more featureful interface to
> GM> git's many bells and whistles, and that's fine. But IMO your statement
> GM> is an exaggeration.
>
> Agreed. Magit in particular adds a steep learning curve to Git's. It's
> good software and fun to use, but it's definitely not a good *general*
> interface (which I'm assuming RMS meant).

My impression is that Magit greatly facilitates the acquisition of Git's
core concepts and saves the user from learning Git's command line
interface.

It is one of those rare instances of a package that is very effective
for novices and experts alike.

Re: In support of Jonas Bernoulli's Magit

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

  > > We have a problem in Emacs: it doesn't contain a good interface to
  > > git. 

  > I get on just fine with Emacs VC and git. It enables me to do just what
  > I did with other VCS in Emacs, and I appreciate the uniformity of
  > interface. Obviously, many people prefer a more featureful interface to
  > git's many bells and whistles, and that's fine. But IMO your statement
  > is an exaggeration.

I'm not stating a personal opinion about VC or Magit.  (I don't have
one.)  I'm citing what other people generally say on this list.

When people ask here what they should do to use git with Emacs, the
usual answer posted is "use Magit".  Thus the problem: that the usual
way people recommend to use Emacs with Git is via a package we have
been unable to include in Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Ken Manheimer]

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

On Thu, Jul 6, 2017 at 12:02 PM, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > > We have a problem in Emacs: it doesn't contain a good interface to
>   > > git.
>
>   > I get on just fine with Emacs VC and git. It enables me to do just what
>   > I did with other VCS in Emacs, and I appreciate the uniformity of
>   > interface. Obviously, many people prefer a more featureful interface to
>   > git's many bells and whistles, and that's fine. But IMO your statement
>   > is an exaggeration.
>
> I'm not stating a personal opinion about VC or Magit.  (I don't have
> one.)  I'm citing what other people generally say on this list.
>
> When people ask here what they should do to use git with Emacs, the
> usual answer posted is "use Magit".  Thus the problem: that the usual
> way people recommend to use Emacs with Git is via a package we have
> been unable to include in Emacs.
>

In following this conversation, I'm getting the distinct feeling that Magit
constitutes an interesting and important case, which might warrant
improving the copyright assignment mechanisms.

On one hand, the magnitude of the Magit project, together with the state of
the GNU copyright assignment mechanisms, present a formidable obstacle to
satisfying the copyright assignment requirement.

On the other hand, as many voices are suggesting, the magnitude of the
benefits Magit offers for developers to do their work simply cannot be
disregarded or bypassed. Kaushal Modi's account of ways Magit makes some
git stuff more approachable than git, itself, or other alternatives. My own
experience is similar. This is no small thing, because in some ways git
provides a similar, unbeatable advantage for source code management,
compared to alternatives. So for some developers (including me), Magit is
not just a good option for doing my job, it is irreplaceable.

One conclusion I'm trying to suggest, from all this, is that Magit warrants
extra effort to solve the copyright assignment problem. Phillip Lords
account of his effort to bring Dash into conformance suggests what seem
like crucial prospective improvements to the copyright assignment
machinery. However, they risk not getting enough attention because they
involve improving legally sensitive bureaucratic processes, which requires
a lot of persistence. I hope that effort is invested - Magit really is that
valuable.

Ken

--
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.
>
>
>

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

Re: In support of Jonas Bernoulli's Magit

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

  > which might warrant
  > improving the copyright assignment mechanisms.

I don't think the mechanism, as such, is much of an inconvenience any
more.  Isn't all the commnication is done digitally now?

It could be improved, but that's like speeding up the fast parts
of a program -- not going to make a big difference.

The substantial part of the job is finding those people and asking
them to please sign.  But it's not terribly hard.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

>> which might warrant improving the copyright assignment mechanisms.
> I don't think the mechanism, as such, is much of an inconvenience any
> more.  Isn't all the commnication is done digitally now?

I think Phillip's points are very valid: there are still friction
points, *especially* when the one doing the work is not a maintainer.
When I was Emacs maintainer, I'd be advised whenever a new assignment
for Emacs came in and I could easily check existing assignments, so it
was rather painless.  I still have my fencepost.gnu.org account so I can
still easily check existing assignments, but I'm not informed any more
when a new assignment comes in.

In a sense the new process where the communication is all done
electronically has made those remaining friction points more apparent.

> The substantial part of the job is finding those people and asking
> them to please sign.  But it's not terribly hard.

There's also finding who you need to contact, keeping track of the
status, reminding them after a while, ...  maybe it's not *hard* but
it's tedious and it can eat a lot of time.

I really appreciated that Phillip did that work for dash, and
I think in general that's a kind of work that would benefit from being
delegated, but for that we need better access to the copyright.list
database for non-maintainers.


        Stefan

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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. ]]]
>
>   > which might warrant
>   > improving the copyright assignment mechanisms.
>
> I don't think the mechanism, as such, is much of an inconvenience any
> more.  Isn't all the commnication is done digitally now?

Only if you live in Italy, Germany, India or the US.

At least according to

https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-scanned-signatures-for-copyright-assignments-from-india

This post also says the full list is in information for maintainers

https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers

Although, this only mentions Italy and the US.

> It could be improved, but that's like speeding up the fast parts
> of a program -- not going to make a big difference.
>
> The substantial part of the job is finding those people and asking
> them to please sign.  But it's not terribly hard.

It is terribly hard. The process consists of this:

1) Get list of all contributors
2) Email them all, recording the date
3) Email those who respond instructions
4) Email assign@fsf to find out current status
5) Email those who havent again
6) Reply to people who say "haven't heard anything"
7) Repeat some variation of 4,5, and 6

8) Work out how many are left
9) Once n < 3 or 4 check how big their contributions are
10) Write them out

Now, for dash, this wasn't too bad (of the 40 contributors I had to get
about 10 through the process, and do only one write out). A quick check
of my mailbox suggests it took around 100 emails over the course of
three months. Not too bad, but still painful. Magit has 4-5x as many
contributors, plus dependencies. Assuming linear scaling, we are looking
at ~1000 emails.

So, we can all bitch about the process; here is a suggestion to improve
things using current software that we already use -- debbugs, installed
with non-public archives which I presume it can do.

1) Get list of all contributors/contributor emails
2) Email assign with full list to find out who needs doing
3) Email each person with new debugs ticket
4) One of:
     assign@fsf cc's electronic communication to debbugs
     assign@fsf acknowledges paper communication *in either direction*
     to debbugs. assign would probably need to attach an ID number to
     outgoing assignment forms.

This would allow tracking the status of the current situation with
respect to each author in need of assignment. It would be more work for
assign@fsf, but would reduce their need to respond to "do we have
assignment for x yet" emails. It would work imperfectly: debbugs is
painful; not everyone would keep debbugs in the CC; and debbugs has a
X-Debbugs-CC field, which means the initial request would be CC'd to the
person when really you want X-Debbugs-TO. But it might work okay. And it
would mean that anyone could take on the task for a given package.

If you will get someone to set up debbugs to support this, help with
using it, and get assign@gnu to buy into the process, I will test it out
with the new assignments need to update dash. If you and GNU are bought
into improving the process, we can refine the details overtime.

If you think "it's not terribly hard", that's probably because you're a
very driven individual who has managed to achieve much that I would have
thought is hard to the point of impossibility. I'm not.

Phil

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

> So, we can all bitch about the process; here is a suggestion to improve
> things using current software that we already use -- debbugs, installed
> with non-public archives which I presume it can do.

IIUC the FSF already uses a tracking system (RT) for copyright
assignments, so it might be even simpler than that.


        Stefan

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 07 Jul 2017 18:22:26 -0400
> 
> IIUC the FSF already uses a tracking system (RT) for copyright
> assignments, so it might be even simpler than that.

Yes, each request has an RT number, stated in each email sent about
it.

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Fri, 07 Jul 2017 23:08:52 +0100
> Cc: ofv@wanadoo.es, rgm@gnu.org, Ken Manheimer <ken.manheimer@gmail.com>,
> 	emacs-devel@gnu.org
> 
> So, we can all bitch about the process; here is a suggestion to improve
> things using current software that we already use -- debbugs, installed
> with non-public archives which I presume it can do.
> 
> 1) Get list of all contributors/contributor emails
> 2) Email assign with full list to find out who needs doing
> 3) Email each person with new debugs ticket
> 4) One of:
>      assign@fsf cc's electronic communication to debbugs
>      assign@fsf acknowledges paper communication *in either direction*
>      to debbugs. assign would probably need to attach an ID number to
>      outgoing assignment forms.

There's no need to rely on the FSF assignment clerk for tracking this
process: you can ask me to do that instead.  I see all the steps of
this process in my email inbox anyway, whether I want it or not.

In general, people who bump into bureaucratic impediments related to
GNU or FSF should ask for help.  Making this better/easier is part of
my and John's duties, and we have access to resources others don't.
You shouldn't need to try to solve these problems alone.

> If you will get someone to set up debbugs to support this, help with
> using it, and get assign@gnu to buy into the process, I will test it out
> with the new assignments need to update dash. If you and GNU are bought
> into improving the process, we can refine the details overtime.

FWIW, I don't want this to be handled via debbugs, as debbugs is
terribly unhelpful in little things that sometimes just make me mad.
Having to cope with it for handling bug reports is bad enough.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

On Sat, July 8, 2017 6:57 am, Eli Zaretskii wrote:
>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Fri, 07 Jul 2017 23:08:52 +0100
>> Cc: ofv@wanadoo.es, rgm@gnu.org, Ken Manheimer
>> <ken.manheimer@gmail.com>,
>> emacs-devel@gnu.org
>> 1) Get list of all contributors/contributor emails
>> 2) Email assign with full list to find out who needs doing
>> 3) Email each person with new debugs ticket
>> 4) One of:
>> assign@fsf cc's electronic communication to debbugs assign@fsf
>> acknowledges paper communication *in either direction* to debbugs.
>> assign would probably need to attach an ID number to outgoing assignment
>> forms.
>
> There's no need to rely on the FSF assignment clerk for tracking this
> process: you can ask me to do that instead.  I see all the steps of
> this process in my email inbox anyway, whether I want it or not.

No this is no good. If I am going to do this, I want notifications -- push
not pull. So, there needs to be a way to open this up beyond maintainers.

Having a system to maintain links to the package we are trying to get
assignment for would be good. Currently, we are talking about assignment
for Emacs, of course, but knowing that we are asking for assignment wrt to
magit, rather than any other package, would be helpful.

Having something which handles something like blocking would be nice also.
i.e. we start a bug wrt to magit for assignment, then all the assignment
requests would be blockers. Then we would know when we are finished.




>
> In general, people who bump into bureaucratic impediments related to
> GNU or FSF should ask for help.  Making this better/easier is part of
> my and John's duties, and we have access to resources others don't. You
> shouldn't need to try to solve these problems alone.
>
>> If you will get someone to set up debbugs to support this, help with
>> using it, and get assign@gnu to buy into the process, I will test it out
>>  with the new assignments need to update dash. If you and GNU are
>> bought into improving the process, we can refine the details overtime.
>
> FWIW, I don't want this to be handled via debbugs, as debbugs is
> terribly unhelpful in little things that sometimes just make me mad.
> Having to cope with it for handling bug reports is bad enough.

I would agree. I don't like debbugs either. But, given the length of time,
for example, it has taken to discuss CI or project hosting alternatives,
it has the advantage of already existing.

Phil

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> Date: Sat, 8 Jul 2017 09:05:18 -0000
> From: "Phillip Lord" <phillip.lord@russet.org.uk>
> Cc: "Phillip Lord" <phillip.lord@russet.org.uk>,
>  ofv@wanadoo.es,
>  rgm@gnu.org,
>  ken.manheimer@gmail.com,
>  rms@gnu.org,
>  emacs-devel@gnu.org
> 
> On Sat, July 8, 2017 6:57 am, Eli Zaretskii wrote:
> >> From: phillip.lord@russet.org.uk (Phillip Lord)
> >> Date: Fri, 07 Jul 2017 23:08:52 +0100
> >> Cc: ofv@wanadoo.es, rgm@gnu.org, Ken Manheimer
> >> <ken.manheimer@gmail.com>,
> >> emacs-devel@gnu.org
> >> 1) Get list of all contributors/contributor emails
> >> 2) Email assign with full list to find out who needs doing
> >> 3) Email each person with new debugs ticket
> >> 4) One of:
> >> assign@fsf cc's electronic communication to debbugs assign@fsf
> >> acknowledges paper communication *in either direction* to debbugs.
> >> assign would probably need to attach an ID number to outgoing assignment
> >> forms.
> >
> > There's no need to rely on the FSF assignment clerk for tracking this
> > process: you can ask me to do that instead.  I see all the steps of
> > this process in my email inbox anyway, whether I want it or not.
> 
> No this is no good. If I am going to do this, I want notifications -- push
> not pull. So, there needs to be a way to open this up beyond maintainers.

Maybe there's a misunderstanding: I'm offering to do this in your
stead.  IOW, "if I'm going to do this" is no longer applicable: if you
ask me, I will do it for you -- you will no longer need to bother
about the process, you will just get a notification when it's done
(and you can query me about the current status, if you wish).

It's entirely up to you whether to take the offer, of course.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:
>> No this is no good. If I am going to do this, I want notifications -- push
>> not pull. So, there needs to be a way to open this up beyond maintainers.
>
> Maybe there's a misunderstanding: I'm offering to do this in your
> stead.  IOW, "if I'm going to do this" is no longer applicable: if you
> ask me, I will do it for you -- you will no longer need to bother
> about the process, you will just get a notification when it's done
> (and you can query me about the current status, if you wish).
>
> It's entirely up to you whether to take the offer, of course.

Eli, this is a kind offer, but it misses the point, really. Having you
do the work doesn't make the work less, especially if, as Stefan says,
there is a ticket system there already. And, having you as a single
point of failure is not that scalable. Even if I get magit done, there
are many other packages out there, and I am not going to do them all.

Phil

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: ofv@wanadoo.es,  rgm@gnu.org,  ken.manheimer@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 08 Jul 2017 21:34:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> No this is no good. If I am going to do this, I want notifications -- push
> >> not pull. So, there needs to be a way to open this up beyond maintainers.
> >
> > Maybe there's a misunderstanding: I'm offering to do this in your
> > stead.  IOW, "if I'm going to do this" is no longer applicable: if you
> > ask me, I will do it for you -- you will no longer need to bother
> > about the process, you will just get a notification when it's done
> > (and you can query me about the current status, if you wish).
> >
> > It's entirely up to you whether to take the offer, of course.
> 
> Eli, this is a kind offer, but it misses the point, really. Having you
> do the work doesn't make the work less

It makes the work less for you.

> And, having you as a single point of failure is not that scalable.

It doesn't make me a single point of failure, because if I'm not
available, the process can be restarted by someone else using the
information available to the FSF personnel.

Re: In support of Jonas Bernoulli's Magit

[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, having you as a single
  > point of failure is not that scalable. Even if I get magit done, there
  > are many other packages out there, and I am not going to do them all.

We don't need a scalable solution for Magit.  It just needs to work
for Magit,

If there are some other packages we would like to get into Emacs,
we can handle them in a scalable way by finding, for each package,
a different few volunteers to manage the process.

The better solution to this problem is to prevent problem cases from
arising any more.  That is what the occasional notice aims to do.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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. ]]]
>
>   > And, having you as a single
>   > point of failure is not that scalable. Even if I get magit done, there
>   > are many other packages out there, and I am not going to do them all.
>
> We don't need a scalable solution for Magit.  It just needs to work
> for Magit,

No, I think this is wrong. Magit is just indicative of the more general
problem. We had the same discussion several years back about dash.

> If there are some other packages we would like to get into Emacs,
> we can handle them in a scalable way by finding, for each package,
> a different few volunteers to manage the process.

Finding new volunteers until they get tired of the process? We need to
simplify the process, and provide better support. I think we are working
through this, which is good.

> The better solution to this problem is to prevent problem cases from
> arising any more.  That is what the occasional notice aims to do.

There are 1000s of packages in MELPA. Even if the problem never happens
again, and even if we only want 10% of those packages, we still need to
make the process smoother.

Phil

Re: In support of Jonas Bernoulli's Magit

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

  > > We don't need a scalable solution for Magit.  It just needs to work
  > > for Magit,

  > No, I think this is wrong. Magit is just indicative of the more general
  > problem. We had the same discussion several years back about dash.

It was necessary to do work to fix the problem for dash.
Now it is necessary to do work to fix the problem for Magit.

We can optimize some aspects of the work, and we're working on that.
(Thanks for helping to do this.)  But I can't envision any more
scalable way of doing the work that we don't optimize away.

A more long-term approach is to prevent other projects from getting
into the same situation.  So I've taken up that issue.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

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

  > No this is no good. If I am going to do this, I want notifications -- push
  > not pull. So, there needs to be a way to open this up beyond maintainers.

I am working on getting this set up.

  > Having a system to maintain links to the package we are trying to get
  > assignment for would be good.

I am not sure what that means -- could you say it more concretely?

  > Having something which handles something like blocking would be nice also.
  > i.e. we start a bug wrt to magit for assignment, then all the assignment
  > requests would be blockers. Then we would know when we are finished.

How would this be more convenient
than putting a list of the contributors in a file
and making a note when each one comes in?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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. ]]]
>
>   > No this is no good. If I am going to do this, I want notifications -- push
>   > not pull. So, there needs to be a way to open this up beyond maintainers.
>
> I am working on getting this set up.

Good. From what Stefan says, if there is already a ticket system
involved in copyright assignment, this might be as simple as enabling a
non-maintainer to start a ticket when they email someone a request.


>   > Having a system to maintain links to the package we are trying to get
>   > assignment for would be good.
>
> I am not sure what that means -- could you say it more concretely?

Yes. The copyright assignment process says "I assign copyright for
Emacs"; obviously this makes sense, but if someone is doing this so that
we can get magit into Emacs or ELPA, then we need to know that also, so
we can work out when a new assignment happens which package (i.e. magit)
it has implications for.


>   > Having something which handles something like blocking would be nice also.
>   > i.e. we start a bug wrt to magit for assignment, then all the assignment
>   > requests would be blockers. Then we would know when we are finished.
>
> How would this be more convenient
> than putting a list of the contributors in a file
> and making a note when each one comes in?

Say we have 200 contributors for magit, and 500 people with copyright
assignment for Emacs. New assignment comes in for Emacs, I now have to
check 200 magit contributors to see whether its one of them. To do
magit, we also need to do 5 dependencies, so we need to check against
those lists as well. It's scaling something like quadratically.

It's also worth remembering here: copyright assignment works based on
peoples names, while the list of contributors for magit that I have is
based on their github names, or the email(s) that they used for their
git commits. So making sure that any data that is stored, also includes
peoples aliases.

To re-iterate, this is just my ideas based on my last experience; it's
going to take several attempts and refinements to get the process
working well.

Phil

Re: In support of Jonas Bernoulli's Magit

[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. The copyright assignment process says "I assign copyright for
  > Emacs"; obviously this makes sense, but if someone is doing this so that
  > we can get magit into Emacs or ELPA, then we need to know that also, so
  > we can work out when a new assignment happens which package (i.e. magit)
  > it has implications for.

We have had a system for this for a long time.

  > Say we have 200 contributors for magit, and 500 people with copyright
  > assignment for Emacs. New assignment comes in for Emacs, I now have to
  > check 200 magit contributors to see whether its one of them.

Since the assignment clerk knows which papers are for Magit,
he should be able to inform you of this directly.

  > It's also worth remembering here: copyright assignment works based on
  > peoples names, while the list of contributors for magit that I have is
  > based on their github names, or the email(s) that they used for their
  > git commits.

Doesn't the Magit repository record contributors' official names?

If not, I am sure we can arrange to tell the assignment clerk
each signer's email address and/or repository name,
and include that in the notification message to maintainers.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[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 general, people who bump into bureaucratic impediments related to
  > GNU or FSF should ask for help.  Making this better/easier is part of
  > my and John's duties, and we have access to resources others don't.
  > You shouldn't need to try to solve these problems alone.

I agree.  And the FSF assignments team can help.  There are many
details we can change in whatever way developers would like.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Richard Stallman]

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

  > 1) Get list of all contributors
  > 2) Email them all, recording the date
  > 3) Email those who respond instructions
  > 4) Email assign@fsf to find out current status
  > 5) Email those who havent again
  > 6) Reply to people who say "haven't heard anything"
  > 7) Repeat some variation of 4,5, and 6

  > 8) Work out how many are left
  > 9) Once n < 3 or 4 check how big their contributions are
  > 10) Write them out

Step 4 is due to FSF procedures, so I will try to change them to
eliminate it.  I hope the clerk will directly notify the person
managing this process when each package contributor's papers arrive.

The rest, however, has nothing to do with how the FSF operates.  At
least, not that I can see.  It is rather the nature of persuading many
individuals to do something, independent of what the something is.

Do you have any suggestions for how to simplify parts other than step
4?

Step 8 is easy if you make a list of all the contributors, one per
line, and add a * once a contributors's papers are done.  I think that
will be faster and easier than using RT to keep track of them.

We don't have to wait till there are only 4 nonsigning contributors to
start steps 9 and 10.  It would be feasible to do with 10 or 20 or 50
contributors left out, if their code is small.  Thus, I suggest
identifying after a few months those whose code is not too hard to
replace.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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. ]]]
>
>   > 1) Get list of all contributors
>   > 2) Email them all, recording the date
>   > 3) Email those who respond instructions
>   > 4) Email assign@fsf to find out current status
>   > 5) Email those who havent again
>   > 6) Reply to people who say "haven't heard anything"
>   > 7) Repeat some variation of 4,5, and 6
>
>   > 8) Work out how many are left
>   > 9) Once n < 3 or 4 check how big their contributions are
>   > 10) Write them out
>
> Step 4 is due to FSF procedures, so I will try to change them to
> eliminate it.  I hope the clerk will directly notify the person
> managing this process when each package contributor's papers arrive.

That will be an excellent addition. Also, it would be good to know when
the FSF forms have gone to the contributor -- assuming assignment is
still a two step process.

The reason for this is that people will say "sent it off, not heard
anything back yet". I don't know how long the assignment process spends
at the FSF end; this could all be postage.


> The rest, however, has nothing to do with how the FSF operates.  At
> least, not that I can see.  It is rather the nature of persuading many
> individuals to do something, independent of what the something is.
>
> Do you have any suggestions for how to simplify parts other than step
> 4?

Having a way to track emails going out on a specific topic would be
helpful; this would make it easier to track when you last emailed some
one about assignment.


> Step 8 is easy if you make a list of all the contributors, one per
> line, and add a * once a contributors's papers are done.  I think that
> will be faster and easier than using RT to keep track of them.

I used org-mode to achieve this, and yes it does help.

If we wish to turn this into a bit more of a factory, though, we might
have a contributor who contributes to more than one package, so getting
a single set of papers might have implications for more than one
project. This is where some sort of tracker might help.

Still, it's a smaller issue than notifications.

> We don't have to wait till there are only 4 nonsigning contributors to
> start steps 9 and 10.  It would be feasible to do with 10 or 20 or 50
> contributors left out, if their code is small.  Thus, I suggest
> identifying after a few months those whose code is not too hard to
> replace.

Actually, I do this at the beginning. Not all contributors actually have
code in the current version, so it's good to know this from the
start. For dash, I just asked everybody, though, on the basis that if
they had code in before, they might do in the future.

Phil

Re: In support of Jonas Bernoulli's Magit

[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 for this is that people will say "sent it off, not heard
  > anything back yet". I don't know how long the assignment process spends
  > at the FSF end; this could all be postage.

They never need to use the post.  Our clerk emails the papers.
Contributors anywhere in the world can print the papers, sign them,
and fax them to us.  Or scan them and email them.

Since people looking for this information found statements that gave
the wrong idea, I think some of our pages about assignment procedures
need to be updated or clarified.  If you saw an fsf.org URL which
contradicts what it says above, please report the problem to
assign@gnu.org.  If they find out about all the misleading pages, they
will fix them all.

  > > Do you have any suggestions for how to simplify parts other than step
  > > 4?

  > Having a way to track emails going out on a specific topic would be
  > helpful; this would make it easier to track when you last emailed some
  > one about assignment.

I am having trouble understanding that concretely.
Which emails do you mean?  "Going out" how?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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 for this is that people will say "sent it off, not heard
>   > anything back yet". I don't know how long the assignment process spends
>   > at the FSF end; this could all be postage.
>
> They never need to use the post.  Our clerk emails the papers.
> Contributors anywhere in the world can print the papers, sign them,
> and fax them to us.  Or scan them and email them.

Okay. I seem to remember an ink requirement, but that's fine.

>
>   > > Do you have any suggestions for how to simplify parts other than step
>   > > 4?
>
>   > Having a way to track emails going out on a specific topic would be
>   > helpful; this would make it easier to track when you last emailed some
>   > one about assignment.
>
> I am having trouble understanding that concretely.
> Which emails do you mean?  "Going out" how?

As we have discussed elsewhere, the developer needs to know when the FSF
has mailed stuff to a contributor. This makes it possible for the
developer to know where an assignment is up to.

Phil

Re: In support of Jonas Bernoulli's Magit

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

  > > They never need to use the post.  Our clerk emails the papers.
  > > Contributors anywhere in the world can print the papers, sign them,
  > > and fax them to us.  Or scan them and email them.

  > Okay. I seem to remember an ink requirement, but that's fine.

There IS still a requirement for ink and paper.  The contributor has
to print the papers, sign them and scan or fax them.
But this does not require snail mail.

Actually, it is not enirely a requirement.  The contributor can paste
per signature into the file and thus avoid the need for printing and
scanning.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

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

  > > We don't have to wait till there are only 4 nonsigning contributors to
  > > start steps 9 and 10.  It would be feasible to do with 10 or 20 or 50
  > > contributors left out, if their code is small.  Thus, I suggest
  > > identifying after a few months those whose code is not too hard to
  > > replace.

  > Actually, I do this at the beginning. Not all contributors actually have
  > code in the current version, so it's good to know this from the
  > start. For dash, I just asked everybody, though, on the basis that if
  > they had code in before, they might do in the future.

That's a wise approach.  It can't hurt to invite the
not-actual-contributors to sign -- but there is no need to wait until
they do.

However, I was talking about a point that is slightly broader.
The point is that we can cope with more than 4 nonsigners,
if their contributions are not crucial.

That is important if there are more people we cannot contact.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Marcin Borkowski]

On 2017-07-10, at 11:26, Richard Stallman <rms@gnu.org> wrote:

> Step 8 is easy if you make a list of all the contributors, one per
> line, and add a * once a contributors's papers are done.  I think that
> will be faster and easier than using RT to keep track of them.

This looks to me like reinventing Org-mode.

Just my 2 cents,

-- 
Marcin Borkowski

Re: In support of Jonas Bernoulli's Magit

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

  > > Step 8 is easy if you make a list of all the contributors, one per
  > > line, and add a * once a contributors's papers are done.  I think that
  > > will be faster and easier than using RT to keep track of them.

  > This looks to me like reinventing Org-mode.

Nothing like Org mode.  Org mode is complicated and I want something
simple.  My method uses only a few general-purpose Emacs commands:
C-p, C-n, C-s, C-a, * and SPC.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Marcin Borkowski]

On 2017-07-11, at 01:30, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > > Step 8 is easy if you make a list of all the contributors, one per
>   > > line, and add a * once a contributors's papers are done.  I think that
>   > > will be faster and easier than using RT to keep track of them.
>
>   > This looks to me like reinventing Org-mode.
>
> Nothing like Org mode.  Org mode is complicated and I want something
> simple.  My method uses only a few general-purpose Emacs commands:
> C-p, C-n, C-s, C-a, * and SPC.

What gives you the impression that Org-mode is complicated?

The Org method would use only _one_ basic Org command: apart from C-n,
C-p and C-s, you'd only need C-c C-t (unless you are fine with typing
TODO/DONE manually).  Of course, you'd also be free to use C-c C-n/C-c
C-p, C-c C-f/C-c C-b and above all C-c C-/, which could be tremendously
helpful.

Best,

--
Marcin Borkowski

Re: In support of Jonas Bernoulli's Magit

[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 gives you the impression that Org-mode is complicated?

I started reading the manual once.

Anyway, discussing Org mode here is a tangent.  The point
is to make a list and check off items on it.  If you find that
easier using Org mode, fine.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Dmitry Gutov]

On 7/6/17 7:02 PM, Richard Stallman wrote:

> When people ask here what they should do to use git with Emacs, the
> usual answer posted is "use Magit".  Thus the problem: that the usual
> way people recommend to use Emacs with Git is via a package we have
> been unable to include in Emacs.

Even if we launch a successful GNU project that competes with Magit, 
*and* manage to more or less cover its feature set, it is highly 
unlikely to eclipse Magit by popularity. People will continue 
recommending Magit.

Instead, we should work toward getting Magit into ELPA, and continue 
improving VC and its Git support. It's a decent interface to Git 
already, and it provide a simpler workflow better suited for new users.

Re: In support of Jonas Bernoulli's Magit

[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 if we launch a successful GNU project that competes with Magit, 
  > *and* manage to more or less cover its feature set, it is highly 
  > unlikely to eclipse Magit by popularity. 

Maybe so.  But it doesn't need to do everything Magit does.  It only
needs to be good enough to make git easy to use in Emacs.

					     People will continue 
  > recommending Magit.

Maybe so.  But if Emacs contains something that is at least adequate,
most users will find it from the manual and other Emacs distro
contents.

  > Instead, we should work toward getting Magit into ELPA, 

I am all in favor of that.  That is the best possible outcome.

However, developing something else should be plan B
if we can't or don't achieve that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

> Maybe so.  But it doesn't need to do everything Magit does.  It only
> needs to be good enough to make git easy to use in Emacs.

Then I think we already have that in VC


        Stefan

Re: In support of Jonas Bernoulli's Magit

[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 so.  But it doesn't need to do everything Magit does.  It only
  > > needs to be good enough to make git easy to use in Emacs.

  > Then I think we already have that in VC

The reason I think this isn't so is that repeatedly I've seen people
post on this list for help dealing with git, and each time people say
to use Magit.

I have not done a scientific study, which would include investigating
whether the recommendation actually helped those people, and what
fraction of Emacs users think VC is just fine for using git.
I have simply supposed that the advice that was given is good advice
since the people who give it are expert Emacs users.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[raman]

Richard Stallman <rms@gnu.org> writes:

I use both vc and magit -- so this perspective below might help where
each of vc/magit win:

For simple vc tasks -- and that typically equates to many things one
traditionally did in all VC systems, vc-git is what I use --- examples:

1. Check-in  current file,
2. Diff current version against a given version etc.

Reason: These are all one-shot kbd commands starting with C-x v

Magit:

There are many things that Git lets you do that are at the power-user
end of the spectrum --- and magit actually makes those doable, whereas
the git commandline would never encourage  you to venture even close.

Examples:

1. Selectively commiting  diff hunks in a file with many changes 

2. Selectively reverting specific diff hunks

3. Applying git patches 

4. Examining past log entries -- especially commits with many files,

5. From (4) jumping to a given file/diff hunk

These above I dont even know where I'd start with vc -- they may well be
possible.

Bottom-line: When one is going to perform a bunch of git tasks, magit
wins; when one if focusing on writing code and using the vc system as a
helper that makes sure you dont lose work, pressing C-x v   to invoke
the vc keymap means you dont switch attention away from what you are
doing.

Also -- for users coming to Git, magit may have a slight win since the
magit buffer shows you a bunch of things you can do at a given point --
whereas with VC, you need to have been using Emacs/VC for a while, or at
least have read the info pages in order to know what is possible.

> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Maybe so.  But it doesn't need to do everything Magit does.  It only
>   > > needs to be good enough to make git easy to use in Emacs.
>
>   > Then I think we already have that in VC
>
> The reason I think this isn't so is that repeatedly I've seen people
> post on this list for help dealing with git, and each time people say
> to use Magit.
>
> I have not done a scientific study, which would include investigating
> whether the recommendation actually helped those people, and what
> fraction of Emacs users think VC is just fine for using git.
> I have simply supposed that the advice that was given is good advice
> since the people who give it are expert Emacs users.

-- 

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> From: raman <raman@google.com>
> Date: Sat, 08 Jul 2017 10:42:26 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> 1. Selectively commiting  diff hunks in a file with many changes 
> 
> 2. Selectively reverting specific diff hunks
> 
> 3. Applying git patches 
> 
> 4. Examining past log entries -- especially commits with many files,
> 
> 5. From (4) jumping to a given file/diff hunk

"C-x v L" can do (4) and you can then do (5) by pressing '=' on the
commit line.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

raman <raman@google.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
> Magit:
>
> There are many things that Git lets you do that are at the power-user
> end of the spectrum --- and magit actually makes those doable, whereas
> the git commandline would never encourage  you to venture even close.


This is certainly true. I've started using these kind of capabilities of
git when I discovered them in magit.

But for me, the key advantage is a very simple one. It's gives you a
project orientated view of git: rather than a file or directory. It
means that I don't accidentally commit two files when I have modified
three. The user interface is also very good and very discoverable.

These are not "power-user" features; magit is good for beginners.

VCs key advantage: it's not Git specific.

Phil

Re: In support of Jonas Bernoulli's Magit

[John Yates]

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

On Sat, Jul 8, 2017 at 1:42 PM, raman <raman@google.com> wrote:
>
> There are many things that Git lets you do that are at the power-user
> end of the spectrum --- an
d magit actually makes those doable, whereas
> the git commandline would never encourage  you to venture even close.

I mentioned earlier in this thread that because Magit is so compelling I
use it to induce susceptible colleagues to try emacs. Let me elaborate.

I work at a company that is trying to up its software engineering
practices.  An important part of that effort is mandating code reviews.
That alone though does not result in particularly useful reviews or
feedback.  The main obstacle is that developers work until a task is
complete and then submit all of their changes as a single, overwhelming
review request.

There are developers within the company who are familiar with patch
series culture as exemplified by the Gnu/Linux kernel.  Others, though
having no first hand experience, understand the ideas and acknowledge
that offering code for review as a well groomed patch series would be
a big improvement.  The problem is that in the real world code never
gets designed / authored / debugged such that it emerges naturally as
an intelligible, coherent patch series.  It takes real work to extract
such a series.  And of course most developers have absolutely no idea
idea how they would go about turning a workspace or even a chaotic
series of incremental commits into such a series.

That is where Magit shines.  It allows one to move arbitrary chunks
of code forward and back among a sequence of commits.  As such it
gives a developer a concrete visualization of the emerging commits
and their contents.  Nor is one restricted to moving hunks identified
by a diff tool.  In Magit a chunk can just as easily be an arbitrary
marked region.

When I demo Magit for my colleagues they immediately get excited.
It makes it clear that fostering a patch series culture need not be
a pipe dream.

To date I am unaware of any other tool on any platform offering
similar functionality.

Were an emacs user to ask me to suggest a package (s)he should use
to interact with git I would always plug Magit.  Not that I would
discourage learning VC.  Clearly (as Raman has explained) VC has a
role.  Magit though alters how one thinks about presenting one's
coding efforts to the greater world.

/john​

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

Re: In support of Jonas Bernoulli's Magit

[raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2607 bytes --]

John Yates <john@yates-sheets.org> writes:

1+-- well said and well explained!> On Sat, Jul 8, 2017 at 1:42 PM, raman <raman@google.com> wrote:
>>
>> There are many things that Git lets you do that are at the power-user
>> end of the spectrum --- an
> d magit actually makes those doable, whereas
>> the git commandline would never encourage  you to venture even close.
>
> I mentioned earlier in this thread that because Magit is so compelling I
> use it to induce susceptible colleagues to try emacs. Let me elaborate.
>
> I work at a company that is trying to up its software engineering
> practices.  An important part of that effort is mandating code reviews.
> That alone though does not result in particularly useful reviews or
> feedback.  The main obstacle is that developers work until a task is
> complete and then submit all of their changes as a single, overwhelming
> review request.
>
> There are developers within the company who are familiar with patch
> series culture as exemplified by the Gnu/Linux kernel.  Others, though
> having no first hand experience, understand the ideas and acknowledge
> that offering code for review as a well groomed patch series would be
> a big improvement.  The problem is that in the real world code never
> gets designed / authored / debugged such that it emerges naturally as
> an intelligible, coherent patch series.  It takes real work to extract
> such a series.  And of course most developers have absolutely no idea
> idea how they would go about turning a workspace or even a chaotic
> series of incremental commits into such a series.
>
> That is where Magit shines.  It allows one to move arbitrary chunks
> of code forward and back among a sequence of commits.  As such it
> gives a developer a concrete visualization of the emerging commits
> and their contents.  Nor is one restricted to moving hunks identified
> by a diff tool.  In Magit a chunk can just as easily be an arbitrary
> marked region.
>
> When I demo Magit for my colleagues they immediately get excited.
> It makes it clear that fostering a patch series culture need not be
> a pipe dream.
>
> To date I am unaware of any other tool on any platform offering
> similar functionality.
>
> Were an emacs user to ask me to suggest a package (s)he should use
> to interact with git I would always plug Magit.  Not that I would
> discourage learning VC.  Clearly (as Raman has explained) VC has a
> role.  Magit though alters how one thinks about presenting one's
> coding efforts to the greater world.
>
> /john6¤6
>

-- 

Re: In support of Jonas Bernoulli's Magit

[Marcin Borkowski]

On 2017-07-08, at 19:42, raman <raman@google.com> wrote:

> For simple vc tasks -- and that typically equates to many things one
> traditionally did in all VC systems, vc-git is what I use --- examples:

FWIW, I sometimes use VC with Mecurial, and the experience is so bad
that the _sole reason_ I switched to Git was the existence of Magit.

The main annoyance is that if I edit _more than one file_, and press C-x
v v, instead of committing my all changes (or at least asking me about
it), it only commits the changes in the currently edited file.  Several
times I made an incomplete commit because of that.  I tried to find an
option to override this, but to no avail.  _That alone_ renders VC
totally unusable, annoying, broken and actively harmful for me.

Now that I think of it, I could have written a bug report (or even try
to implement this myself).  But you know what?  I just switched to Git
and started to use Magit, because it is so much better.

Now, vc-dir seems similar to magit-status.  But it has one _huge_
drawback: it requires me to press RET each time after I invoke it.  (Why
would I want to invoke vc-dir for some other directory than the one I'm
in anyway?  And in such rare cases, C-u would handle that much better.)

Now that I think of it, I could write a trivial wrapper for that (and
I might actually do it, for the sake of legacy Mercurial projects
I have).  But you know what?  If you use Git, then why even bother when
Magit exists?

I guess that Emacs' VC with distributed VCSs is fundamentally broken,
since it was really designed with RCS and its likes in mind, and
imposing that onto DVCSs is awkward.  I suspect that situation (with VC)
is better now than a few years ago (e.g., AFAIK pushing/pulling is now
implemented), but I haven't looked into it too much.

Sorry if that sounds harsh, but I consider VC's utility (with DVCSs) to
be zero _at best_.

Best,

--
Marcin Borkowski

Re: In support of Jonas Bernoulli's Magit

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Sun, 09 Jul 2017 11:25:28 +0200
> Cc: emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> The main annoyance is that if I edit _more than one file_, and press C-x
> v v, instead of committing my all changes (or at least asking me about
> it), it only commits the changes in the currently edited file.  Several
> times I made an incomplete commit because of that.  I tried to find an
> option to override this, but to no avail.

You can do what you want with VC by first marking the files you want
to commit in vc-dir buffer.

> I guess that Emacs' VC with distributed VCSs is fundamentally broken,
> since it was really designed with RCS and its likes in mind

You seem to talk only about "C-x v v".  That command doesn't assume
RCS-type VCS, it assumes that there's some more-or-less constant
sequence of actions in your workflow, and attempts to support that
sequence by doing "the next thing".  I think this concept can be
naturally generalized to modern VCSes, except that the number of
different workflows is larger, definitely more than one.  At the time,
I proposed to move in that direction, but people disagreed, so nothing
happened.  I still think it's a good idea, so maybe someone will want
to work on it.

But VC includes more than "C-x v v" alone.  There are commands like
"C-x v D", "C-x v ~" (just recently mentioned as very important and
useful -- with Git, no less!), "C-x v g" with its sub-commands,
"C-x v l", "C-x v L", "C-x v I"/"C-x v O", "V-x v u", and others.  I
see no reasons to ignore these useful commands when talking about VC.

> Sorry if that sounds harsh, but I consider VC's utility (with DVCSs) to
> be zero _at best_.

I think this is at least exaggerated.  I certainly don't see how this
could follow from what VC provides.

In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Juliusz Chroboczek]

>> For simple vc tasks -- and that typically equates to many things one
>> traditionally did in all VC systems, vc-git is what I use --- examples:

I agree.  VC stays out of the way, while Magit is a whole new interface,
and a modal one at that.  That's fine if you're doing complicated stuff
with your repository, but if you're actually programming and wish to
commit your work or check a diff, VC is much more streamlined.

> The main annoyance is that if I edit _more than one file_, and press C-x
> v v, instead of committing my all changes (or at least asking me about
> it), it only commits the changes in the currently edited file.

Yes, that's annoying.  You need to mark all the modified files in the
vc-dir buffer.  And I agree that VC should at least warn that there are
other modified files.  (I think this deserves a bug report.)

> I suspect that situation (with VC) is better now than a few years ago
> (e.g., AFAIK pushing/pulling is now implemented), but I haven't looked
> into it too much.

It's quite useful for everyday tasks -- committing, diffing and browsing
the logs.  For more exotic tasks (partial commits, browsing remotes
repositories, merging), I use Magit or the command line.

-- Juliusz

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Michael Albinus]

Juliusz Chroboczek <jch@irif.fr> writes:

>> The main annoyance is that if I edit _more than one file_, and press C-x
>> v v, instead of committing my all changes (or at least asking me about
>> it), it only commits the changes in the currently edited file.
>
> Yes, that's annoying.  You need to mark all the modified files in the
> vc-dir buffer.  And I agree that VC should at least warn that there are
> other modified files.  (I think this deserves a bug report.)

I regard this as a feature of vc-dir. Usually, I keep several modified
files I don't want to commit immediately. Selecting the files to be
committed by a mark is exactly what fits my workflow.

> -- Juliusz

Just my 2¢.

Best regards, Michael.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I regard this as a feature of vc-dir. Usually, I keep several modified
> files I don't want to commit immediately. Selecting the files to be
> committed by a mark is exactly what fits my workflow.

It seems like there's two different workflows here: Some people keep
work in progress going on some files while wanting to commit other
files, while other people only have a single thing going (perhaps over
many files) and always wants to commit all changed files.

This sounds like it should be a user-level switch in vc that would
control whether the default is to commit all changes or just the current
file, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Juliusz Chroboczek]

> It seems like there's two different workflows here: Some people keep
> work in progress going on some files while wanting to commit other
> files, while other people only have a single thing going (perhaps over
> many files) and always wants to commit all changed files.

I can only speak for myself, but I fit in both categories at different
times, depending on what I'm doing.

> This sounds like it should be a user-level switch in vc that would
> control whether the default is to commit all changes or just the current
> file, I think.

I think the default behaviour should be as so: if no files are marked,
and there are modified files other than the one that's being committed,
ask whether to commit the other files (if user is unsure, he can C-g and
investigate).

-- Juliusz

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Yuri Khan]

On Mon, Jul 10, 2017 at 3:47 PM, Juliusz Chroboczek <jch@irif.fr> wrote:

> I think the default behaviour should be as so: if no files are marked,
> and there are modified files other than the one that's being committed,
> ask whether to commit the other files (if user is unsure, he can C-g and
> investigate).

If multiple files are modified, the “next action” could be to display
the ‘vc-dir’ buffer for the current repository.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Marcin Borkowski]

On 2017-07-10, at 10:59, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 3:47 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
>
>> I think the default behaviour should be as so: if no files are marked,
>> and there are modified files other than the one that's being committed,
>> ask whether to commit the other files (if user is unsure, he can C-g and
>> investigate).
>
> If multiple files are modified, the “next action” could be to display
> the ‘vc-dir’ buffer for the current repository.

Out of all the suggestions made here, this is probably the best.

I'll file a bug report later.

And I'm sorry for being so harsh.  Apparently many people appreciate VC
and it works for them.  I'll study the relevant chapter in the manual,
then I'll try to use VC for a while to form a better opinion.

Best,

--
Marcin Borkowski

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 10 Jul 2017 15:59:04 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, Jul 10, 2017 at 3:47 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
> > I think the default behaviour should be as so: if no files are marked,
> > and there are modified files other than the one that's being committed,
> > ask whether to commit the other files (if user is unsure, he can C-g and
> > investigate).
> 
> If multiple files are modified, the “next action” could be to display
> the ‘vc-dir’ buffer for the current repository.

I'd encourage people to work on making the workflow (and thus the
"next action") customizable.  We could have several popular workflows
for the user to choose, for example.  We could even have a facility
whereby the user specifies the sequence of the actions in her
workflow.

I think "C-x v v" is a powerful concept, and if done right, is a great
time saver, and also prevents errors.  We shouldn't give up on that so
easily.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Dmitry Gutov]

On 7/10/17 11:59 AM, Yuri Khan wrote:

> If multiple files are modified, the “next action” could be to display
> the ‘vc-dir’ buffer for the current repository.

We had an argument about changing `M-x vc-dir' to show the repository 
root right away, instead of prompting. Couldn't reach an agreement.

So I doubt your suggestion would be accepted as the default workflow.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Marcin Borkowski]

On 2017-07-16, at 20:01, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 7/10/17 11:59 AM, Yuri Khan wrote:
>
>> If multiple files are modified, the “next action” could be to display
>> the ‘vc-dir’ buffer for the current repository.
>
> We had an argument about changing `M-x vc-dir' to show the repository
> root right away, instead of prompting. Couldn't reach an agreement.

Out of curiosity: what the arguments for asking?  I can't see any.  (And
in the unlikely case the asking behavior is needed, it could be
triggered by giving a prefix argument.)

Best,

--
Marcin Borkowski

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Dmitry Gutov]

On 7/16/17 10:09 PM, Marcin Borkowski wrote:

> Out of curiosity: what the arguments for asking?  I can't see any.  (And
> in the unlikely case the asking behavior is needed, it could be
> triggered by giving a prefix argument.)

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12492#23. There was 
also a discussion on emacs-devel quite a bit later, but David didn't 
link to it in the commit (f302475471df0553b3ee442112981f9b146e0b55).

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[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, that's annoying.  You need to mark all the modified files in the
  > vc-dir buffer.

vc-dir shows all the modified files on its own.
The user has to specify which ones to commit.

Should we add a command to specify "mark all the modified files for
this commit"?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Marcin Borkowski]

On 2017-07-11, at 01:26, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > Yes, that's annoying.  You need to mark all the modified files in the
>   > vc-dir buffer.
>
> vc-dir shows all the modified files on its own.
> The user has to specify which ones to commit.
>
> Should we add a command to specify "mark all the modified files for
> this commit"?

What Magit does is that if you try to commit with nothing staged, it
offers to stage everything that has changed.  This seems reasonable.

-- 
Marcin Borkowski

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

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

  > > Should we add a command to specify "mark all the modified files for
  > > this commit"?

  > What Magit does is that if you try to commit with nothing staged, it
  > offers to stage everything that has changed.  This seems reasonable.

VC does not know about staging.  For it to what you've suggested here
would mean a large change.

Maybe that change would be useful, so try writing it if you wish.  But
I think what we want here is a simple fix.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Marcin Borkowski]

On 2017-07-11, at 13:48, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > > Should we add a command to specify "mark all the modified files for
>   > > this commit"?
>
>   > What Magit does is that if you try to commit with nothing staged, it
>   > offers to stage everything that has changed.  This seems reasonable.
>
> VC does not know about staging.  For it to what you've suggested here
> would mean a large change.

Obviously.  What I meant was for VC to do something along the lines of
"if trying to commit with nothing marked to commit, offer to commit
everything that has changed".  Sorry for my poor wording.

> Maybe that change would be useful, so try writing it if you wish.  But
> I think what we want here is a simple fix.

I don't think I'd be able to do that, especially now that I am quite
busy.  And the staging concept might be difficult to fit into the VC
framework anyway.

Best,

-- 
Marcin Borkowski

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Juliusz Chroboczek]

>> VC does not know about staging.

[...]

>> Maybe that change would be useful, so try writing it if you wish.

[...]

> And the staging concept might be difficult to fit into the VC
> framework anyway.

I agree.

VC shines for everyday operations.  Notice a typo, edit a file, C-x v v,
compose a log message, C-c C-c.  Except for composing the log message,
it feels just like working without a VCS.

Staging is useful for more involved workflows, and so doesn't fit
culturally into VC.  Extending VC to these more involved workflows
without breaking the remarkable simplicity of VC in the simple case
would be a lot of work by somebody with exceedingly good taste, and
duplicated work at that, since Magit works fine in the rare cases when
it's necessary.

(I've been good in this thread until now, so please allow me to indulge
in some trolling.  The good taste requirement excludes git hackers.)

-- Juliusz

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

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

  > Obviously.  What I meant was for VC to do something along the lines of
  > "if trying to commit with nothing marked to commit, offer to commit
  > everything that has changed".  Sorry for my poor wording.

That idea makes sense.  It might be a good change.

Thanks.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Tue, 11 Jul 2017 06:15:18 +0200
> Cc: Juliusz Chroboczek <jch@irif.fr>, emacs-devel@gnu.org
> 
> > vc-dir shows all the modified files on its own.
> > The user has to specify which ones to commit.
> >
> > Should we add a command to specify "mark all the modified files for
> > this commit"?
> 
> What Magit does is that if you try to commit with nothing staged, it
> offers to stage everything that has changed.  This seems reasonable.

Reasonable for Magit, since it supports only Git.  Not sure about VC:
staging is a Git-only feature, whereas VC tries to abstract the user
from the backend as much as possible.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Dmitry Gutov]

On 7/11/17 5:37 PM, Eli Zaretskii wrote:

> Reasonable for Magit, since it supports only Git.  Not sure about VC:
> staging is a Git-only feature, whereas VC tries to abstract the user
> from the backend as much as possible.

Since VC does not offer staging as a feature anyway, for Git and other 
backends it would mean to offer to commit all edited files in the given 
repository.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Andreas Schwab]

On Jul 10 2017, Richard Stallman <rms@gnu.org> wrote:

> Should we add a command to specify "mark all the modified files for
> this commit"?

There is no need for such a command, just put point on the enclosing
directory.  A VC command will then operate on all files in that
directory.

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: In defense of VC [was: In support of Jonas Bernoulli's Magit]

[Michael Albinus]

Andreas Schwab <schwab@suse.de> writes:

> On Jul 10 2017, Richard Stallman <rms@gnu.org> wrote:
>
>> Should we add a command to specify "mark all the modified files for
>> this commit"?
>
> There is no need for such a command, just put point on the enclosing
> directory.  A VC command will then operate on all files in that
> directory.

And there is also `vc-dir-mark-all-files', bound to "M" in a vc-dir buffer.

> Andreas.

Best regards, Michael.

Re: In defense of VC [was: In support of Jonas Bernoulli's Magit]

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

  > > Should we add a command to specify "mark all the modified files for
  > > this commit"?

  > There is no need for such a command, just put point on the enclosing
  > directory.  A VC command will then operate on all files in that
  > directory.

I didn't know this; it is not self-evident.
Perhaps we should display a line as a message in the buffer
to inform users about this option.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[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 main annoyance is that if I edit _more than one file_, and press C-x
  > v v, instead of committing my all changes (or at least asking me about
  > it), it only commits the changes in the currently edited file.

What do you think it to do?

Should it display a message saying, "Use vc-dir to view the whole project
and make commits?"

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Marcin Borkowski]

On 2017-07-10, at 11:29, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > The main annoyance is that if I edit _more than one file_, and press C-x
>   > v v, instead of committing my all changes (or at least asking me about
>   > it), it only commits the changes in the currently edited file.
>
> What do you think it to do?
>
> Should it display a message saying, "Use vc-dir to view the whole project
> and make commits?"

As I wrote in another post, it should just launch vc-dir _in the current
directory_.

Best,

--
Marcin Borkowski

Re: In support of Jonas Bernoulli's Magit

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

  > As I wrote in another post, it should just launch vc-dir _in the current
  > directory_.

Will that do the right thing?  I think it needs to use the main directory
of the project.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Marcin Borkowski]

On 2017-07-11, at 01:30, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > As I wrote in another post, it should just launch vc-dir _in the current
>   > directory_.
>
> Will that do the right thing?  I think it needs to use the main directory
> of the project.

I stand corrected, you are right.

-- 
Marcin Borkowski

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

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. ]]]
>
>   > I'm afraid that you guys are missing the point. This has no relation
>   > with the maintainer of Magit, but with the fact that Magit cannot be
>   > distributed with Emacs.
>
> You've hit the nail on the head.  I am not saying anything either good
> or bad about Magit as such, because that's not the issue here.
>
> We have a problem in Emacs: it doesn't contain a good interface to
> git.  People often recommend something that is not in Emacs.  That's
> not a good situation.  I want to fix it.
>
> In principle, we could fix it with Magit.  I would be very glad if we
> did.  That would require tracking down lots of people and convincing
> them to sign the legal papers, and maybe replacing some pieces of code
> whose authors didn't sign.
>
> A year ago, more or less, I asked people if we could do this and I was
> told it was impossible.


It is not impossible, just difficult and time-consuming. I would relate
my experiences with getting copyright assignment for dash (33
contributors vs 200, no dependencies vs 4 dependencies).

Almost everybody I asked about copyright assignment said yes. Those who
did not just did not reply and have disappeared from the web. I
contacted everybody through their emails in git. I had to write out one
function, of about 14 lines.

The problem is that the process is currently blind. I email all the
developers, but I can't tell who already has assignment. Those who do
not, I email information to, but then cannot tell who has sent the
request forms out. Then I email again, to see whether they have
assignment forms, because I get no notification when the process has
completed. Copyright assignment is, per se, a big slow down. But, with
the FSF process, it's even harder. I know that some people can see the
assignments, but AFAICT, there is not notification of when this changes.

Installing some kind of ticket system, and a method for letting people
declare whether they have assignment already would be an enormous help.

As it stood, I think, dash.el took 4 months, because of the necessity
for the to-ing and fro-ing. dash.el in ELPA is now several versions
behind, because it's has some new contributors since, and I haven't been
able to get the energy up to start the process again. We also now have
seq.el, most of whose functionality is covered by dash; an unfortunate
and unnecessary duplication.

The FSF has a donations drive every year. Can you not spend some of that
on making the process easier? Even a public website showing people with
assignment (who are willing to be public) would help. And, another
copyright assignment clerk who can help with the process of emailing
everyone in a project like magit.

After that, getting magit into Emacs or ELPA might be less impossible
after all.

Phil

Re: In support of Jonas Bernoulli's Magit

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

  > Almost everybody I asked about copyright assignment said yes. Those who
  > did not just did not reply and have disappeared from the web.

It is much better to ask people for papers when they make their
contributions.  At that time, it is not hard to find them,
and there is a natural way to persuade them.

When people develop a package and only much later think about
getting legal papers for it, the job becomes a more difficult,
and that is what we see in the case of Magit.

  > As it stood, I think, dash.el took 4 months, because of the necessity
  > for the to-ing and fro-ing. dash.el in ELPA is now several versions
  > behind, because it's has some new contributors since,

The way to avoid this is for the developers of dash.el to ask new
contributors "please sign papers", as we do.

Why is that not happening?

  > The FSF has a donations drive every year. Can you not spend some of that
  > on making the process easier?

We do.  That is one of the things that some of our staff work on.
Alas, there are many other tasks waiting for them.

The best solution for this hassle is to avoid it -- by collecting
legal papers as the package is developed.

  > Even a public website showing people with
  > assignment (who are willing to be public) would help.

That sounds like something feasible to do.  I think we could
easily find 100 Emacs developers who would be happy to agree
to this.

Can you make the idea more precise?  What should this look like?
Also, how would it help?


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:
>   > As it stood, I think, dash.el took 4 months, because of the necessity
>   > for the to-ing and fro-ing. dash.el in ELPA is now several versions
>   > behind, because it's has some new contributors since,
>
> The way to avoid this is for the developers of dash.el to ask new
> contributors "please sign papers", as we do.
>
> Why is that not happening?


Well, I need to add something to the README file, but I never got around
to it. From a practical POV, though, this also means potentially not
accepting pull requests from people, till the assignment has happened,
which is likely to be weeks to months.


>   > The FSF has a donations drive every year. Can you not spend some
>   > of that on making the process easier?
>
> We do.  That is one of the things that some of our staff work on.
> Alas, there are many other tasks waiting for them.
>
> The best solution for this hassle is to avoid it -- by collecting
> legal papers as the package is developed.

It doesn't avoid the hassle. It just makes it a hassle at the point at
which people first contribute.

>   > Even a public website showing people with
>   > assignment (who are willing to be public) would help.
>
> That sounds like something feasible to do.  I think we could
> easily find 100 Emacs developers who would be happy to agree
> to this.
>
> Can you make the idea more precise?  What should this look like?
> Also, how would it help?

That was step 1 in my protocol. Work out who you need to get copyright
assignment from, given that many people will already have it. It would
also help with working out when peoples assignments run out. I do not
know when mine is out of date, for example.

Being able to get access to this data in a parsable form. Currently, I
get contributor information from git (git log --pretty=format:"%an %ae"
| sort -u). Being able to filter people who already have assignment
would be great.

Phil

Re: In support of Jonas Bernoulli's Magit

[Richard Stallman]

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

  > Well, I need to add something to the README file, but I never got around
  > to it. From a practical POV, though, this also means potentially not
  > accepting pull requests from people, till the assignment has happened,
  > which is likely to be weeks to months.

Now that everything is done on-line, the process should normally take
a few days, unless the clerk is on vacation for a week.  Would you
please start asking all new dash contributors to sign papers
before you put in their contributions?

  > > The best solution for this hassle is to avoid it -- by collecting
  > > legal papers as the package is developed.

  > It doesn't avoid the hassle. It just makes it a hassle at the point at
  > which people first contribute.

It is much less of a hassle if done at that time.

1. There is no hassle of figuring out who to ask for papers.

2. There is no hassle in finding them.

3. They have a motivation to sign, so it is not hard
to convince them.

4. The task feels like less hassle since it consists of a small
job once in a while.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

>> I wish someone would write a package comparable to Magit that
>> we could get legal papers for and include it in Emacs.
> I cannot let this go without commenting.  Do you understand what
> you are advocating?

FWIW, I fully agree with John that developing a "replacement" for Magit
just because we can't get the copyright paperwork would be harmful at best.

A much more constructive path would be to figure out *how* to get Magit
into GNU ELPA (i.e. start collecting copyright paperwork from the
various contributors, look at the code that's not yet covered to see
what we could about it, consider maybe a subset of Magit, consider
tweaking the policy for GNU ELPA, ...).


        Stefan

Re: In support of Jonas Bernoulli's Magit

[Ingo Lohmar]

I agree with the consensus in this thread, and on reading Richard's mail
this morning, several thoughts along the same lines crossed my mind.

Please let's not undermine a successful *free software* project (by the
strictest FSF definition) by trying to duplicate (presumably badly) the
work, passion, clear vision and eye for quality that Jonas has shown.

Also, from a practical point of view --- why would anybody in his/her
right mind contribute to such a project, instead of contributing to
Magit?  There are no ethical incentives, and any technical curiosity
has to face the *huge* amount of work and refinement that has already
happened in Magit.

Since getting copyright assignments for Magit contributions seems a
rather daunting task (given the longevity and the size of the project),
we could try to encourage technical steps to integrate parts of Magit
into GNU ELPA and/or Emacs.  Jonas has extracted several auxiliary
packages that might qualify, for example because they have been newly
written, rewritten, or have all necessary copyright assignments.  A
rewrite of magit's core using libgit2 (maybe as an Emacs module) is also
on the map --- maybe this could be done in such a way that it could
become part of Emacs?

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Noam Postavsky]

On Wed, Jul 5, 2017 at 11:29 AM, John Yates <john@yates-sheets.org> wrote:
> Jonas has and continues to deliver a steady stream of features,
> bug fixes and refinements.  Magit is clearly a work of love that is
> wonderfully supported.  Jonas has exhibited admirable project
> leadership skill and has published a detailed, credible map to
> the future:

Speaking of, Jonas asked me to let you all know he's planning on
commenting here this weekend.

But in the meantime don't worry: he agrees with the idea of making
Magit into a GNU project in principle.

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Paul Michael Reilly]

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

>
> But in the meantime don't worry: he agrees with the idea of making
> Magit into a GNU project in principle.
>

That is wonderful news! Were Magit a GNU project a few years ago, Richard
would no doubt have a few less gray hairs and I would not have been the
proverbial messenger whom Richard shot when trying to help him grok Git by
using Magit. :-)

There are likely more than a few of us who have learned Git via Magit and
for which we are grateful to Jonas and the Magit contributors.

I would implore the GNU leaders to bend over backwards to include projects
like Magit which exemplify Free Software values and practices.  I would go
so far as to suggest that catalogs of GNU software also include a special
category of software that fails the GNU stamp of approval by virtue of only
missing copyright assignment to GNU.  And I would implore these same
leaders to use such software proudly.
-- 
-pmr

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

Re: In support of Jonas Bernoulli's Magit

[Toon Claes]

Paul Michael Reilly <pmr@pajato.com> writes:
> That is wonderful news! Were Magit a GNU project a few years ago...
>
> There are likely more than a few of us who have learned Git via Magit
> and for which we are grateful to Jonas and the Magit contributors.

Let me first say, I am not against making Magit a GNU project, in
contrary. But I think Magit would never have gotten such a vibrant
community if the project was hosted on Savannah, rather than on GitHub.

Having a more /modern development platform/, like GitHub/GitLab/Gitea/...,
makes it much easier for new contributors to participate on a project.

So making a project an official GNU project is two-fold. All the legal
paperwork would be in order for all contributors, but I seriously doubt
the Magit project would ever have reach anything close to the current
207 contributors.

I know this discussion has been raised several times before, but I
really would like to see GNU/FSF to adopt a more modern platform.


-- Toon

Re: In support of Jonas Bernoulli's Magit

[Mike Gerwitz]

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

On Thu, Jul 06, 2017 at 10:46:18 +0200, Toon Claes wrote:
> Let me first say, I am not against making Magit a GNU project, in
> contrary. But I think Magit would never have gotten such a vibrant
> community if the project was hosted on Savannah, rather than on GitHub.
>
> Having a more /modern development platform/, like GitHub/GitLab/Gitea/...,
> makes it much easier for new contributors to participate on a project.

You're free to use GitLab for GNU projects:

  https://www.gnu.org/software/repo-criteria-evaluation.html

> I know this discussion has been raised several times before, but I
> really would like to see GNU/FSF to adopt a more modern platform.

Yes, a GNU GitLab instance (for example) would be good to have.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

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

Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Nicolas Petton]

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

Mike Gerwitz <mtg@gnu.org> writes:

> You're free to use GitLab for GNU projects:
>
>   https://www.gnu.org/software/repo-criteria-evaluation.html

I'd love it if we used GitLab for the development of Emacs.  IIRC, John
talked about setting up an instance to try it out.

If that's of any interest, I would gladly setup an instance for us to try.

Cheers,
Nico

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

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Tino Calancha]

On Fri, 7 Jul 2017, Nicolas Petton wrote:

> Mike Gerwitz <mtg@gnu.org> writes:
>
>> You're free to use GitLab for GNU projects:
>>
>>   https://www.gnu.org/software/repo-criteria-evaluation.html
>
> I'd love it if we used GitLab for the development of Emacs.  IIRC, John
> talked about setting up an instance to try it out.
>
> If that's of any interest, I would gladly setup an instance for us to try.
He and Ted already set up one:
https://gitlab.com/emacs-ci/emacs

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Nicolas Petton]

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

Tino Calancha <tino.calancha@gmail.com> writes:

> He and Ted already set up one:
> https://gitlab.com/emacs-ci/emacs

Was this instnace supposed to be used for development, or just GitLab's
CI?

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

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Ted Zlatanov]

On Fri, 07 Jul 2017 10:29:02 +0200 Nicolas Petton <nicolas@petton.fr> wrote: 

NP> Tino Calancha <tino.calancha@gmail.com> writes:
>> He and Ted already set up one:
>> https://gitlab.com/emacs-ci/emacs

NP> Was this instnace supposed to be used for development, or just GitLab's
NP> CI?

Just CI.

Ted

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Ævar Arnfjörð Bjarmason]

On Fri, Jul 07 2017, Ted Zlatanov jotted:

> On Fri, 07 Jul 2017 10:29:02 +0200 Nicolas Petton <nicolas@petton.fr> wrote:
>
> NP> Tino Calancha <tino.calancha@gmail.com> writes:
>>> He and Ted already set up one:
>>> https://gitlab.com/emacs-ci/emacs
>
> NP> Was this instnace supposed to be used for development, or just GitLab's
> NP> CI?
>
> Just CI.

Which makes this rather off-topic from what Toon Claes was mentioning
upthread in enfm2mv8ineau.fsf@iotcl.com, which is that the main benefit
people get from platforms like Github or Gitlab is not that they're just
some dumb web UI or CI system on the side, but that they're the primary
coordination point & way to contribute to the project.

As a datapoint of one: I have ~20 patches in Magit and a bunch more in
various Elisp projects hosted on Github because contributing is so easy.

Usually when I discover bugs in things part of Emacs itself I just work
around them, since starting to contribute to the project would require
signing papers etc., which would be a huge hurdle compared to what I'm
fixing (none of my Magit contributions are major, just small fixes here
& there).

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Dmitry Gutov]

On 7/8/17 2:02 PM, Ævar Arnfjörð Bjarmason wrote:

> Usually when I discover bugs in things part of Emacs itself I just work
> around them, since starting to contribute to the project would require
> signing papers etc.,

You are not helping our case, unfortunately: even if Emacs switches to 
GitLab or something similar (which I hope it will), contributing will 
still require signing papers.

> which would be a huge hurdle compared to what I'm
> fixing (none of my Magit contributions are major, just small fixes here
> & there).

Small fixes (up to ~15 lines in total) don't require copyright assignment.

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 8 Jul 2017 14:13:44 +0300
> Cc: Toon Claes <toon@iotcl.com>, emacs-devel@gnu.org
> 
> On 7/8/17 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
> 
> > Usually when I discover bugs in things part of Emacs itself I just work
> > around them, since starting to contribute to the project would require
> > signing papers etc.,
> 
> You are not helping our case, unfortunately: even if Emacs switches to 
> GitLab or something similar (which I hope it will), contributing will 
> still require signing papers.

It's actually more than that: patches submitted to Emacs need to
conform to our coding and various other standards: include
properly-formatted commit log messages, documentation, and (where
appropriate) tests, etc.  Patch review could require cleanup changes
etc.

People who find this too much of an effort should perhaps describe
their solution without showing any actual code, so that someone else
could implement it.  This way, copyright assignment is not an issue,
and chances are the change will be eventually made.

Of course, it is better to actually sign papers, which is a one-time
hassle.

> > which would be a huge hurdle compared to what I'm
> > fixing (none of my Magit contributions are major, just small fixes here
> > & there).
> 
> Small fixes (up to ~15 lines in total) don't require copyright assignment.

Yes.  But that limit is quickly exhausted.

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Dmitry Gutov]

On 7/8/17 2:53 PM, Eli Zaretskii wrote:

> It's actually more than that: patches submitted to Emacs need to
> conform to our coding and various other standards: include
> properly-formatted commit log messages, documentation, and (where
> appropriate) tests, etc.  Patch review could require cleanup changes
> etc.

That doesn't negate the advantages of integrated solutions like GitLab, 
though. Emacs is not the only project with standards.

We often enforce those via code review, and GitLab helps with that.

> People who find this too much of an effort should perhaps describe
> their solution without showing any actual code, so that someone else
> could implement it.

Relatedly, a friendlier bug tracker would go a long way as well.

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Phillip Lord]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 7/8/17 2:53 PM, Eli Zaretskii wrote:
>
>> It's actually more than that: patches submitted to Emacs need to
>> conform to our coding and various other standards: include
>> properly-formatted commit log messages, documentation, and (where
>> appropriate) tests, etc.  Patch review could require cleanup changes
>> etc.
>
> That doesn't negate the advantages of integrated solutions like
> GitLab, though. Emacs is not the only project with standards.
>
> We often enforce those via code review, and GitLab helps with that.

And the process is much easier in most projects. Push to feature branch,
get comments, using line-level in diff commenting. Then fix, squash,
force push. Finally, single click merge, PR closes.

Phil

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Tim Cross]

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

I think Phil's point is very important. While I find github/gitlab to be a
nice interface for small projects, I'm not at all convinced that it adds
much for larger or more complex projects. As an example, the bug/issue
tracker really doesn't scale well once you have hundreds of bugs/issues.

Once you have a project with more than ~10k lines of code, multiple
branches and large numbers of contributors and bug reporters,
administration becomes a big issue. I suspect that few except perhaps
casual users will really use the UI's provided by github/gitlab, preferring
instead to use just git. At that point, where the repo is hosted becomes
less relevant.

My experience with github and gitlab issue tracking has been that you need
to either use a different tool or develop custom workflows using the API in
order to manage large numbers of bugs effectively. Again, the web interface
is OK for casual users and smaller projects, but lacks the level of
sophistication necessary for larger teams and larger bug numbers. I'm not
saying that the current bug tracker is great, but I've found few bug
tracking systems to be great and the current one is adequate once you
invest time into it.

I'm certainly not against something like gitlab or the gitlab interface,
but I don't think it will be as beneficial or 'revolutionary' to Emacs'
maintenance or level of contributions as some seem to feel. In most ways,
it is just a little bit of UI sugar and a community is more than just a bit
of sugar.

On 9 July 2017 at 07:02, Phillip Lord <phillip.lord@russet.org.uk> wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 7/8/17 2:53 PM, Eli Zaretskii wrote:
> >
> >> It's actually more than that: patches submitted to Emacs need to
> >> conform to our coding and various other standards: include
> >> properly-formatted commit log messages, documentation, and (where
> >> appropriate) tests, etc.  Patch review could require cleanup changes
> >> etc.
> >
> > That doesn't negate the advantages of integrated solutions like
> > GitLab, though. Emacs is not the only project with standards.
> >
> > We often enforce those via code review, and GitLab helps with that.
>
> And the process is much easier in most projects. Push to feature branch,
> get comments, using line-level in diff commenting. Then fix, squash,
> force push. Finally, single click merge, PR closes.
>
> Phil
>
>
>


-- 
regards,

Tim

--
Tim Cross

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

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Ævar Arnfjörð Bjarmason]

On Sat, Jul 08 2017, Eli Zaretskii jotted:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 8 Jul 2017 14:13:44 +0300
>> Cc: Toon Claes <toon@iotcl.com>, emacs-devel@gnu.org
>>
>> On 7/8/17 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> > Usually when I discover bugs in things part of Emacs itself I just work
>> > around them, since starting to contribute to the project would require
>> > signing papers etc.,
>>
>> You are not helping our case, unfortunately: even if Emacs switches to
>> GitLab or something similar (which I hope it will), contributing will
>> still require signing papers.
>
> It's actually more than that: patches submitted to Emacs need to
> conform to our coding and various other standards: include
> properly-formatted commit log messages, documentation, and (where
> appropriate) tests, etc.  Patch review could require cleanup changes
> etc.
>
> People who find this too much of an effort should perhaps describe
> their solution without showing any actual code, so that someone else
> could implement it.  This way, copyright assignment is not an issue,
> and chances are the change will be eventually made.

   "My project's requirements are so onerous that some find it not worth
   their time to contribute at all, but it's OK because those some
   people can instead describe in prose what their not-good-enough
   contributions should look like instead, surely that'll yield the same
   end result.".

I think that's a fair paraphrasing of the point you made. Of course
everything that adds extra friction to contributing is an issue, and
results in fewer contributions.

Anyway, I'm not trying to get into some flamewar about the relative
merits of FSF's copyright policies or Emacs's contribution policy on
this list. I just wanted to point out that Toon Claes's point that
started this thread had been lost midway through.

Which is that when people talk about having project X on Github or
Gitlab they don't mean so in the narrow sense of having it be mirrored
there in some capacity, or using some narrow subset of features like CI.

They mean that they'd like project X to be as easy to contribute to as
they're used to from contributing to other projects on those platforms.

> Of course, it is better to actually sign papers, which is a one-time
> hassle.
>
>> > which would be a huge hurdle compared to what I'm
>> > fixing (none of my Magit contributions are major, just small fixes here
>> > & there).
>>
>> Small fixes (up to ~15 lines in total) don't require copyright assignment.
>
> Yes.  But that limit is quickly exhausted.

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Eli Zaretskii]

> From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, tzz@lifelogs.com, toon@iotcl.com, emacs-devel@gnu.org
> Date: Sat, 08 Jul 2017 14:43:44 +0200
> 
> > It's actually more than that: patches submitted to Emacs need to
> > conform to our coding and various other standards: include
> > properly-formatted commit log messages, documentation, and (where
> > appropriate) tests, etc.  Patch review could require cleanup changes
> > etc.
> >
> > People who find this too much of an effort should perhaps describe
> > their solution without showing any actual code, so that someone else
> > could implement it.  This way, copyright assignment is not an issue,
> > and chances are the change will be eventually made.
> 
>    "My project's requirements are so onerous that some find it not worth
>    their time to contribute at all, but it's OK because those some
>    people can instead describe in prose what their not-good-enough
>    contributions should look like instead, surely that'll yield the same
>    end result.".
> 
> I think that's a fair paraphrasing of the point you made.

No, it isn't fair.  You've added some derogatory adjectives which
weren't there, and that completely distorts the message.  It was meant
to be positive, and propose a practical alternative through which
people could still contribute and have the problems they bumped into
solved, without requiring too much effort.

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Jean-Christophe Helary]

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


> On Jul 8, 2017, at 20:02, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> 
> Usually when I discover bugs in things part of Emacs itself I just work
> around them, since starting to contribute to the project would require
> signing papers etc., which would be a huge hurdle compared to what I'm
> fixing (none of my Magit contributions are major, just small fixes here
> & there).

That's interesting, because everything I've contributed so far to emacs (2 small code patches and 1 documentation patch, *only*) is trivial and I've signed the papers right away to not be bothered with that anymore.

For one paper signed, you can contribute your fixes that will be used by *all* the emacs community. So a few minutes of your time allow your code to help *everybody* in the emacs community however trivial you think your contribution is.

And conversely, you would not find emacs as useful as it is now if hundreds of people had not taken a few minutes of their time to sign the papers.

Jean-Christophe

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

Re: Trying out GitLab (was Re: In support of Jonas Bernoulli's Magit)

[Mike Gerwitz]

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

On Fri, Jul 07, 2017 at 17:27:18 +0900, Tino Calancha wrote:
> On Fri, 7 Jul 2017, Nicolas Petton wrote:
>> If that's of any interest, I would gladly setup an instance for us to try.
> He and Ted already set up one:
> https://gitlab.com/emacs-ci/emacs

The use of gitlab.com's instance for hosting is fine, but one of the
issues discussed on this list was that of CI:  Using gitlab.com for CI is
relying on a third party to do your computing, which is
SaaSS.  Howerver, if GNU hosted its own GitLab instance on its own
servers, there would be no such issue.

Having the FSF sysadmins work with GNU to set up a GitLab instance is
what I was referring to.  (I'm not aware of any plans to do so atm.)
Obviously if it's also used for CI for GNU projects then it would need
considerable resources, and I have no idea what is even currently
available.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

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

Re: In support of Jonas Bernoulli's Magit

[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 a more /modern development platform/, like GitHub/GitLab/Gitea/...,
  > makes it much easier for new contributors to participate on a project.

You are judging these platforms based on convenience.  We have other
ways of judging their practices -- based on ethics and how they affect
free software.  See https://gnu.org/software/repo-criteria.html.

GitHub has done great harm to our whole community by encouraging
people to post programs with no licenses (thus nonfree) and to be
sloppy about indicating licenses.  We grade it as unacceptable.

GitLab is better but still not entirely good.

I have not heard of Gitea before so I have no opinion.  I will ask
the FSF to evaluate it.

As for changing the software on savannah, that can be done
if people volunteer to work on it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[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 wonderful news! Were Magit a GNU project a few years ago, Richard
  > would no doubt have a few less gray hairs and I would not have been the
  > proverbial messenger whom Richard shot when trying to help him grok Git by
  > using Magit. :-)

I didn't shoot anyone -- I criticized the message.
I still think of you as my friend.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Jonas Bernoulli]

Hello,

I would like to thank John Yates and others for speaking up and for
sharing some thoughts on the role I have played in making Magit what
it is today.

  Richard Stallman said:
> You've hit the nail on the head.  I am not saying anything either
> good or bad about Magit as such, because that's not the issue here.

To some extend, that rubs me the wrong way.  Lacking public statements
to the contrary, this leaves the impression that you want to include
Magit in Emacs not because you think it is good, but because it is
successful.

That being said, and while I appreciate that...

  Stefan Monnier said:
> I'm afraid you're missing the point: distributing Magit with Emacs
> is not terribly important, compared to fostering good relationships.

...the relationship is still good and I don't see that changing.  It
is not particularly strong though, but that is something that I would
like to change.

Part of Magit's success lays in my efforts to take the needs and ideas
of all of its users seriously and to find satisfactory compromises
even when mutually exclusive opinions exist on some matter.

Usually such disagreements mostly concern design matters, but this
situation is similar.  And here too I want to be able to justify the
outcome, while I realize that it will not be possible to satisfy
everybody, because existing opinions range from "this is something
that absolutely must be done" to "doing this would massively hinder
future development and must absolutely be avoided".

I disagree with both opinions and suspect that most people do too, but
toward what side the majority leans I do not know.  And while this is
not the only factor that will guide my decision, public opinion is one
that I will consider.

I dislike being in a situation where I have no choice but to pick the
worst of the available options in the eyes of some, no matter what I
choose to do, i.e. when my only choice is between whom I disappoint.

As a result I feel put on the spot.  And this is the primary reason
why I have taken so long to respond.

  Richard Stallman said:
> We have a problem in Emacs: it doesn't contain a good interface to
> git.  People often recommend something that is not in Emacs.  That's
> not a good situation.  I want to fix it.

I understand why you would like to integrate Magit into Emacs.

I understand why you want to hold the copyright for all code in Emacs.

I do *not* understand why, in the case that this should not happen,
you take issue with people recommending Magit and why you think that
this is a major issue that needs fixing.

I also do not understand why you personally do not want to -- why you
apparently cannot -- use Magit while it is not part of Emacs.

Magit is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.

I understand why you would *rather* have Magit be a part of Emacs, but
I do not understand why that not being the case is a deal breaker --
it is free software released under your preferred license, which you
co-authored.

You will have to provide an answer to that question before I can move
forward with this. It might be that I don't agree with your reasoning.
If so, then that most not necessarily be a deal breaker for me -- but
I think that we as a community can not simply except this premise that
"Magit must be part of Emacs, or else it must be replaced and should
not be recommended" unquestioned.

  Richard Stallman said:
> In principle, we could fix it with Magit.  [...] A year ago, more or
> less, I asked people if we could do this and I was told it was
> impossible.

The last time I replied in a thread such as this one (which might very
well be the conversation you are referring to), I said that I am open
to the idea, but that I have other priorities.  I did not say that it
was impossible, and don't think anybody else did either.

I do prioritize according to my understanding of what will be most
beneficial to Magit's users.  What are the benefits to Magit if it is
integrated into Emacs?  It's not that I don't see any, but I also see
many drawbacks, and I don't really think that I should be the one who
outlines the benefits.

---

I actually want to integrate parts of Magit into Emacs as soon as
possible, because they are useful beyond the Magit/Git use-case and/or
because Magit would benefit from Emacs making some concessions to its
needs.

`with-editor.el' is an existing example.  So are `magit-popup.el' and
`magit-section.el', though I intend to replace those libraries with
better implementations that draw from what I have learned about their
limitations.  (Also `magit-popup.el' is one of, if not the ugliest
part of Magit.  But it is solid never-the-less.)

I should have done that a long time ago, and it is a bit strange to do
so now, shortly before I begin work on the successors.  But I should
probably do so anyway.  I am occasionally being asked to do it, and
even once I have written the replacements, I think that valid reasons
will remain to prefer the old implementations.  (Though it will be a
bit strange that they will continue to be named "magit-*" while Magit
itself will have moved on, maybe the should be renamed once that
happens.)

Could we please start with adding those packages to Elpa?  Baby steps
and all.  It would immensely help me stay motivated to move into this
direction, if Richard could in turn stop treating Magit as a problem
and embrace it, or at least refrain from calling for a replacement
and uttering a warning whenever someone recommends its use.

---

I think that Magit is really good, but also that it could still get a
lot better.  And I have a plan toward that goal -- John Yates called
it a "credible map toward the future".  That plan involves, and to
some extend depends on, contributing large amounts of code to Emacs.

In the long run it would be beneficial for Magit itself to be part of
Emacs.  I just don't think that adding all of Magit to Emacs now, is
the best strategy forward.

---

What I am trying to do is to separate the abstractions from the
concrete uses in the UI and because this has been a major focus all
along I have progressed pretty far already.  I would like to add those
abstractions to Emacs core.

I also intend to soon write new low-level functionality, including
`git-handler.el', a file-handler for Git blobs and trees, and a module
for libgit2 (which John Wiegley has offered to co-author).  I am going
to contribute these libraries soon after as they have progressed
beyond the prototyping stage.  My hope is that VC and Git related
third-party packages will use them, to increase interoperability.

I think experimentation and innovation happens primarily outside of
Emacs core.  I am under the impression, that once a package is part
of Emacs, its basic structure is set in stone.  (Just to be clear, I
think a lot of good changes are being made to Emacs itself too.  And
I plan to make heavy use of some of the newer functionality, which I
in many cases am very exited about.)

But I strongly believe that Magit is only what it is today because
I had the liberty to innovate and make far reaching changes without
having to constantly justify in great detail why those changes were
necessary.  Once Magit is part of Emacs core, that won't be possible
anymore, and merely being part of Elpa doesn't really help Magit at
all.

So what I would like to do instead of adding Magit to Emacs/Elpa, is
to add primarily those abstractions to Emacs core, whose essence is
clearly represented in their implementation.  Essentially code that
feels very obvious.  Such code might look trivial, but is the result
of hard work and the willingness to admit that some earlier attempt
was wrong and to discard it while learning from it.  I feel that too
many Emacs packages work around limitations instead of tackling them
head on.

---

Maintaining Magit is a lot of work, probably more than most realize.
I don't just write most of the code, I also write documentation,
provide user support, and generally do everything in my power to make
Magit as useful and easy to use for as many people as I can.

I won't be able to keep this up much longer unless I am being payed to
do so.  But I love doing it, which is why I will start a fundraising
campaign this month.  (I wasn't actually quite ready to announce that
yet, another reason why it took me so long to respond.  Should I just
conceal this rather relevant detail or talk in great length about it?
As so often, I have decided to compromise, in this case by merely
mentioning it.)

  Cheers,
  Jonas
  

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

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

There are some deep incommensurabilities of premises between your
views as you've just stated them and mine.  We seem to differ on goals
and values.  Your stated concern is for Magit users, whereas my
concern is about Emacs as a part of the GNU project.

I think the best chance of coming to some understanding, and perhaps
agreement, is to talk privately.

I can't communicate any more now, whether publicly or privately.  It
is time for me to go to sleep, and I will spedn the next 24 hours
sleeping and then flying.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Jonas Bernoulli]

> There are some deep incommensurabilities of premises between your
> views as you've just stated them and mine.  We seem to differ on goals
> and values. [...]
>
> I think the best chance of coming to some understanding, and perhaps
> agreement, is to talk privately.

The differences may not be as substantial as the impression you got.
Yes, lets talk.

> It is time for me to go to sleep, and I will spedn the next 24 hours
> sleeping and then flying.

I am in no hurry.  So lets talk next week, probably next weekend.

  Jonas

Re: In support of Jonas Bernoulli's Magit

[Stefan Monnier]

> Could we please start with adding those packages to Elpa?

Sounds pretty good.  We usually welcome new packages into GNU ELPA, so
of course libraries that are in actual use by important packages even
more so.

I know nothing about those libraries, but I'd be happy to help bring
them into GNU ELPA.

> I think experimentation and innovation happens primarily outside of
> Emacs core.  I am under the impression, that once a package is part
> of Emacs, its basic structure is set in stone.

"Backward compatibility" tends to impose  restrictions, indeed.  Less so
for end-user facing functionality than for functionality exported as an
Elisp library, but yes.

Note that this doesn't apply to GNU ELPA packages which can break
backward compatibility all they want.


        Stefan

Re: In support of Jonas Bernoulli's Magit

[Jonas Bernoulli]

Hi Stefan,

  Stefan Monnier said:
> I know nothing about those libraries, but I'd be happy to help bring
> them into GNU ELPA.

I've already started working on getting them into shape.  I probably
won't be ready before mid-August.  I will contact you and/or this list
then.

>> I think experimentation and innovation happens primarily outside of
>> Emacs core.  I am under the impression, that once a package is part
>> of Emacs, its basic structure is set in stone.
>
> "Backward compatibility" tends to impose  restrictions, indeed.

Just to make sure: this was not meant as criticism.

  Jonas

git-handler.el (was: In support of Jonas Bernoulli's Magit)

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Hello,

Hi Jonas,

> I also intend to soon write new low-level functionality, including
> `git-handler.el', a file-handler for Git blobs and trees, and a module
> for libgit2 (which John Wiegley has offered to co-author).  I am going
> to contribute these libraries soon after as they have progressed
> beyond the prototyping stage.  My hope is that VC and Git related
> third-party packages will use them, to increase interoperability.

The idea of writing a file name handler for versioned files is on my
todo list for years. Alas, I haven't been motivated enough to start, and
I'm also not a specialist in vc in general, or git in special.

But I have 15 years experience in using file name handlers in Emacs. If
you need any help to write such a library, I would be glad to support
you. Just ping me, if you believe it could be useful.

>   Cheers,
>   Jonas

Best regards, Michael.

Re: git-handler.el (was: In support of Jonas Bernoulli's Magit)

[Jonas Bernoulli]

Hi Michael,

  Michael Albinus <michael.albinus@gmx.de> writes:
> The idea of writing a file name handler for versioned files is on my
> todo list for years.

Same here ;-) But I very much hope I get to it toward the end of August.

> But I have 15 years experience in using file name handlers in Emacs. If
> you need any help to write such a library, I would be glad to support
> you. Just ping me, if you believe it could be useful.

Thanks for the offer.  I will contact you when I actually start working
on this.  If you get to it before I do, then please let me have a look,
to make sure it satisfies Magit's needs.

  Jonas

Re: git-handler.el

[Michael Albinus]

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

Jonas Bernoulli <jonas@bernoul.li> writes:

> Hi Michael,

Hi Jonas, Dmitry,

>> The idea of writing a file name handler for versioned files is on my
>> todo list for years.
>
> Same here ;-) But I very much hope I get to it toward the end of August.
>
>> But I have 15 years experience in using file name handlers in Emacs. If
>> you need any help to write such a library, I would be glad to support
>> you. Just ping me, if you believe it could be useful.
>
> Thanks for the offer.  I will contact you when I actually start working
> on this.  If you get to it before I do, then please let me have a look,
> to make sure it satisfies Magit's needs.

As a warmup, I have written vc-handler.el and vc-git-handler.el. They
are far from being complete, but they'll show what's possible.

A revisioned filename is something like "/path/to/file@@revision".
"revision" could be a revision like "81656add81", a branch like
"scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
could be changed.

vc-handler.el is the common part. There is the alist
`vc-file-name-handler-alist', which lists for every magic file name
function the responsible handler function. The majority of them is also
implemented in vc-handler.el, because they don't need any vcs specific
handling.

For every different backend, there could be a respective backend
package. I've implemented vc-git-handler.el, because I know more about
vc-git than magit. But there's no problem to implement vc-magit.el, for
example. I plan also to write at least vc-cvs.el.

You might play a little bit to see how it looks like. Maybe the most
simple start is to enter dired, because it uses many of the magic file
name operations. Just do "C-x d ~/src/emacs/src/emacs.c@@" (supposed
your Emacs git is located at ~/src/emacs, as in my case).

Both packages are far from being complete. Performance is terrible (a
proper cache mechanism is needed), my git skill is restricted so I might
not use the best commands, and you will see many TODO comments. It's
just a proof of concept. And I hope it is useful for both magit and vc.

>   Jonas

Best regards, Michael.


[-- Attachment #2: vc-handler.el --]
[-- Type: application/emacs-lisp, Size: 21486 bytes --]

;;; vc-handler.el --- File Name Handler for revisions of version controlled files  -*- lexical-binding:t -*-

;; Copyright (C) 2017 Free Software Foundation, Inc.

;; Author: Michael Albinus <michael.albinus@gmx.de>
;; Keywords: vc tools
;; Package: vc

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This package provides transparent access to revisions of version
;; controlled files.  A revision looks always like
;; "/path/to/file@@/branch/revision-or-label".  The
;; "@@/branch/revision-or-label" syntax depends on the used vc
;; backend.

;; All files or directories with this syntax are handled read-only.
;; It is not intended to modify revisions of such files or
;; directories.

;; For Git, a revision looks like "@@/master/ef7a18a071" or
;; "@@/master/HEAD".  A branch might be "@@/emacs-25/3a34412caa" or
;; "@@/emacs-25/HEAD", and a label is "@@/emacs-25.2"

;; For Cvs, it looks like "@@/2.7" or "@@/V-2-2-6" (a label) or
;; "@@/branch-2-1-stable/2.7.0.2" (a branch).

;; Revisioned file names, which are not complete until the final
;; revision number or label, are regarded as directories.  Files in
;; that directory are the respective revisions.  A directory
;; "@@/emacs-25/" might contain the files "3a34412caa" or
;; "56a4461a48".

;; File name handlers for a magic file operation are declared in
;; `vc-file-name-handler-alist' and vc backend specific
;; `vc-<backend>-file-name-handler-alist' variables.  If a file name
;; handler is declared in both locations, the backend specific one
;; takes precedence.  If no file name handler is declared, the default
;; operation is applied.

;;; Code:

(require 'vc)

;; TODO: This is just temporarily.
(require 'ls-lisp)
(setq ls-lisp-use-insert-directory-program nil
      enable-dir-local-variables nil)

(defconst vc-file-name-regexp "@@[-[:alnum:]._/]*\\'"
  "Regular expression matching revisioned file names.")

;; New handlers should be added here.
(defconst vc-file-name-handler-alist
  '(;; `access-file' performed by default handler.
    (add-name-to-file . ignore)
    ;; `byte-compiler-base-file-name' performed by default handler.
    ;; `copy-directory' performed by default handler.
    (copy-file . vc-handle-copy-file)
    (delete-directory . ignore)
    (delete-file . ignore)
    ;; `diff-latest-backup-file' performed by default handler.
    ;; `directory-file-name' performed by default handler.
    (directory-files . vc-handle-directory-files)
    (directory-files-and-attributes . vc-handle-directory-files-and-attributes)
    (dired-compress-file . ignore)
    ;; `dired-uncache' performed by default handler.
    (expand-file-name . vc-handle-expand-file-name)
    (file-accessible-directory-p . vc-handle-file-accessible-directory-p)
    (file-acl . ignore)
    (file-attributes . vc-handle-file-attributes)
    (file-directory-p . vc-handle-file-directory-p)
    ;; `file-equal-p' performed by default handler.
    (file-executable-p . vc-handle-file-executable-p)
    (file-exists-p . vc-handle-file-exists-p)
    ;; `file-in-directory-p' performed by default handler.
    ;; `file-local-copy' performed by backend specific handler.
    (file-modes . vc-handle-file-modes)
    ;; `file-name-all-completions' performed by backend specific handler.
    ;; `file-name-as-directory' performed by default handler.
    (file-name-case-insensitive-p . vc-handle-file-name-case-insensitive-p)
    (file-name-completion . vc-handle-file-name-completion)
    ;; `file-name-directory' performed by default handler.
    ;; `file-name-nondirectory' performed by default handler.
    ;; `file-name-sans-versions' performed by default handler.
    (file-newer-than-file-p . vc-handle-file-newer-than-file-p)
    (file-notify-add-watch . ignore)
    (file-notify-rm-watch . ignore)
    (file-notify-valid-p . ignore)
    (file-ownership-preserved-p . ignore)
    (file-readable-p . vc-handle-file-readable-p)
    (file-regular-p . vc-handle-file-regular-p)
    (file-remote-p . vc-handle-file-remote-p)
    (file-selinux-context . ignore)
    (file-symlink-p . vc-handle-file-symlink-p)
    (file-truename . vc-handle-file-truename)
    (file-writable-p . ignore)
    ;; `find-backup-file-name' performed by default handler.
    ;; `find-file-noselect' performed by default handler.
    ;; `get-file-buffer' performed by default handler.
    (insert-directory . vc-handle-insert-directory)
    (insert-file-contents . vc-handle-insert-file-contents)
    (load . vc-handle-load)
    (make-auto-save-file-name . ignore)
    (make-directory . ignore)
    (make-nearby-temp-file . vc-handle-make-nearby-temp-file)
    (make-symbolic-link . ignore)
    (process-file . vc-handle-process-file)
    ;; `rename-file' performed by default handler.
    (set-file-acl . ignore)
    (set-file-modes . ignore)
    (set-file-selinux-context . ignore)
    (set-file-times . ignore)
    (set-visited-file-modtime . ignore)
    (shell-command . ignore)
    (start-file-process . ignore)
    (substitute-in-file-name . vc-handle-substitute-in-file-name)
    ;; `temporary-file-directory' performed by default handler.
    (unhandled-file-name-directory . vc-handle-unhandled-file-name-directory)
    (vc-registered . ignore)
    (verify-visited-file-modtime . vc-handle-verify-visited-file-modtime)
    (write-region . ignore))
  "Alist of handler functions.
Operations not mentioned here will be handled by the normal Emacs functions.")

(defun vc-handler-file-name-p (file)
  "Check, whether FILE is a revisioned file name"
  (and (stringp file) (string-match vc-file-name-regexp file)))

(defun vc-handler-file-name-part (file)
  "Return the regular name of FILE, without the revision part."
  (if (vc-handler-file-name-p file)
      (replace-match "" nil nil file)
    file))

(defun vc-handler-file-revision-name (file)
  "Return the revision of FILE, if any."
  (when (vc-handler-file-name-p file)
    (match-string 0 file)))

(defun vc-responsible-handler (operation args)
  "Determine the responsible handler for file name operation ARGS.
One of the elements in ARGS must be a revisioned file name.  This
function checks first whether there is a backend specific
handler, by inspectiong `vc-<backend>-file-name-handler-alist'.
If none is found, `vc-file-name-handler-alist' is inspected."
  ;; Check which element of ARGS is a revisioned file name.
  (setq args (append args `(,default-directory)))
  (while (and (consp args) (not (vc-handler-file-name-p (car args))))
    (setq args (cdr args)))
  ;; Search backend specific handler.
  (when (consp args)
    (let* ((default-directory temporary-file-directory) ;; Avoid recursion.
	   (responsible-backend
	    ;; This check is restricted to `vc-handled-backends'.  But
	    ;; this could be extended to other backends easily, like
	    ;; magit.
	    (ignore-errors
	      (vc-responsible-backend
	       (vc-handler-file-name-part (car args)))))
	   (package
	    (and responsible-backend
		 (concat
		  "vc-"
		  (downcase (symbol-name responsible-backend))
		  "-handler")))
	   (backend-handler-alist
	    (and responsible-backend
		 (intern
		  (concat
		   "vc-"
		   (downcase (symbol-name responsible-backend))
		   "-file-name-handler-alist")))))
      (or (and package
	       (or (featurep (intern package))
		   (load package 'noerror 'nomessage))
	       backend-handler-alist (boundp backend-handler-alist)
	       (assoc operation (symbol-value backend-handler-alist)))
	  (assoc operation vc-file-name-handler-alist)))))

(defun vc-run-real-handler (operation args)
  "Invoke normal file name handler for OPERATION.
First arg specifies the OPERATION, second arg is a list of arguments to
pass to the OPERATION."
  (let* ((inhibit-file-name-handlers
	  `(vc-file-name-handler
	    .
	    ,(and (eq inhibit-file-name-operation operation)
		  inhibit-file-name-handlers)))
	 (inhibit-file-name-operation operation))
    (apply operation args)))

(defun vc-file-name-handler (operation &rest args)
  "Invoke revisioned file name handler.
Falls back to normal file name handler if it doesn't exists."
  (let ((fn (vc-responsible-handler operation args)))
    (if fn
	(save-match-data (apply (cdr fn) args))
      (vc-run-real-handler operation args))))

;; Activate the handler.
(add-to-list 'file-name-handler-alist
	     (cons vc-file-name-regexp
		   'vc-file-name-handler))
(put 'vc-file-name-handler 'safe-magic t)
;; Mark `operations' the handler is responsible for.
(put 'vc-file-name-handler 'operations
     (cl-union
      (get 'vc-file-name-handler 'operations)
      (mapcar 'car vc-file-name-handler-alist)))

;; The handlers.

(defun vc-handle-copy-file
  (filename newname &optional ok-if-already-exists keep-date
   preserve-uid-gid preserve-extended-attributes)
  "Like `copy-file' for revisioned files."
  (setq filename (expand-file-name filename)
	newname (expand-file-name newname))
  (if (vc-handler-file-name-p filename)
      (rename-file (file-local-copy filename) newname ok-if-already-exists)
    (vc-run-real-handler
     'copy-file
     (list filename newname ok-if-already-exists keep-date
	   preserve-uid-gid preserve-extended-attributes))))

(defun vc-handle-directory-files (directory &optional full match nosort)
  "Like `directory-files' for revisioned files."
  (when (file-directory-p directory)
    (setq directory (file-name-as-directory (expand-file-name directory)))
    (let ((temp (nreverse (file-name-all-completions "" directory)))
 	  result item)
      (while temp
 	(setq item (directory-file-name (pop temp)))
 	(when (or (null match) (string-match match item))
 	  (push (if full (concat directory item) item)
 		result)))
      (if nosort result (sort result 'string<)))))

(defun vc-handle-directory-files-and-attributes
    (directory &optional full match nosort id-format)
  "Like `directory-files-and-attributes' for revisioned files."
  (mapcar
   (lambda (x)
     (cons x (file-attributes
 	      (if full x (expand-file-name x directory)) id-format)))
   (directory-files directory full match nosort)))

(defun vc-handle-expand-file-name (filename &optional dir)
  "Like `expand-file-name' for revisioned files."
  (if (not (file-name-absolute-p filename))
      (expand-file-name
       (concat (file-name-as-directory (or dir default-directory)) filename))
    (let* ((default-directory (or dir default-directory))
	   (revision-name
	    (or (vc-handler-file-revision-name filename)
		));(vc-handler-file-revision-name default-directory)))
	   (default-directory
	     (unhandled-file-name-directory default-directory)))
      (when (and revision-name
		 (string-equal (file-name-nondirectory revision-name) "."))
	(setq revision-name (file-name-directory revision-name)))
      (concat
       (expand-file-name (vc-handler-file-name-part filename)) revision-name))))

(defun vc-handle-file-accessible-directory-p (filename)
  "Like `file-accessible-directory-p' for revisioned files."
  (and (file-directory-p filename)
       (file-readable-p filename)))

(defun vc-handle-file-attributes (filename &optional id-format)
  "Like `file-attributes' for revisioned files."
  ;; This is the default implementation.  Shall be superseded by
  ;; backend specific specific implementation. Time, owner, branches
  ;; being directories, ...
  (let ((default-directory (unhandled-file-name-directory default-directory)))
    (file-attributes (vc-handler-file-name-part filename) id-format)))

(defun vc-handle-file-directory-p (filename)
  "Like `file-directory-p' for revisioned files."
  (eq (car (file-attributes filename)) t))

(defun vc-handle-file-executable-p (filename)
  "Like `file-executable-p' for revisioned files."
  (or (file-directory-p filename)
      (file-executable-p (vc-handler-file-name-part filename))))

(defun vc-handle-file-exists-p (filename)
  "Like `file-exists-p' for revisioned files."
  (not (null (file-attributes filename))))

;; This function is stolen from `tramp-mode-string-to-int'.  Maybe a
;; common Emacs function would serve?
(defun vc-handler-mode-string-to-int (mode-string)
  "Converts a ten-letter `drwxrwxrwx'-style mode string into mode bits."
  (let* (case-fold-search
	 (mode-chars (string-to-vector mode-string))
         (owner-read (aref mode-chars 1))
         (owner-write (aref mode-chars 2))
         (owner-execute-or-setid (aref mode-chars 3))
         (group-read (aref mode-chars 4))
         (group-write (aref mode-chars 5))
         (group-execute-or-setid (aref mode-chars 6))
         (other-read (aref mode-chars 7))
         (other-write (aref mode-chars 8))
         (other-execute-or-sticky (aref mode-chars 9)))
    (save-match-data
      (logior
       (cond
	((char-equal owner-read ?r) (string-to-number "00400" 8))
	((char-equal owner-read ?-) 0)
	(t (error "Second char `%c' must be one of `r-'" owner-read)))
       (cond
	((char-equal owner-write ?w) (string-to-number "00200" 8))
	((char-equal owner-write ?-) 0)
	(t (error "Third char `%c' must be one of `w-'" owner-write)))
       (cond
	((char-equal owner-execute-or-setid ?x) (string-to-number "00100" 8))
	((char-equal owner-execute-or-setid ?S) (string-to-number "04000" 8))
	((char-equal owner-execute-or-setid ?s) (string-to-number "04100" 8))
	((char-equal owner-execute-or-setid ?-) 0)
	(t (error "Fourth char `%c' must be one of `xsS-'"
		  owner-execute-or-setid)))
       (cond
	((char-equal group-read ?r) (string-to-number "00040" 8))
	((char-equal group-read ?-) 0)
	(t (error "Fifth char `%c' must be one of `r-'" group-read)))
       (cond
	((char-equal group-write ?w) (string-to-number "00020" 8))
	((char-equal group-write ?-) 0)
	(t (error "Sixth char `%c' must be one of `w-'" group-write)))
       (cond
	((char-equal group-execute-or-setid ?x) (string-to-number "00010" 8))
	((char-equal group-execute-or-setid ?S) (string-to-number "02000" 8))
	((char-equal group-execute-or-setid ?s) (string-to-number "02010" 8))
	((char-equal group-execute-or-setid ?-) 0)
	(t (error "Seventh char `%c' must be one of `xsS-'"
		  group-execute-or-setid)))
       (cond
	((char-equal other-read ?r) (string-to-number "00004" 8))
	((char-equal other-read ?-) 0)
	(t (error "Eighth char `%c' must be one of `r-'" other-read)))
       (cond
	((char-equal other-write ?w) (string-to-number "00002" 8))
	((char-equal other-write ?-) 0)
	(t (error "Ninth char `%c' must be one of `w-'" other-write)))
       (cond
	((char-equal other-execute-or-sticky ?x) (string-to-number "00001" 8))
	((char-equal other-execute-or-sticky ?T) (string-to-number "01000" 8))
	((char-equal other-execute-or-sticky ?t) (string-to-number "01001" 8))
	((char-equal other-execute-or-sticky ?-) 0)
	(t (error "Tenth char `%c' must be one of `xtT-'"
		  other-execute-or-sticky)))))))

(defun vc-handle-file-modes (filename)
  "Like `file-modes' for revisioned files."
  (let ((truename (or (file-truename filename) filename)))
    (when (file-exists-p truename)
      (vc-handler-mode-string-to-int
       (file-attribute-modes (file-attributes truename))))))

(defun vc-handle-file-name-case-insensitive-p (filename)
  "Like `file-name-case-insensitive-p' for revisioned files."
  (let ((default-directory (unhandled-file-name-directory default-directory)))
    (file-name-case-insensitive-p (vc-handler-file-name-part filename))))

(defun vc-handle-file-name-completion (filename directory &optional predicate)
  "Like `file-name-completion' for revisioned files."
  (let (hits-ignored-extensions)
    (or
     (try-completion
      filename (file-name-all-completions filename directory)
      (lambda (x)
 	(when (funcall (or predicate 'identity) (expand-file-name x directory))
 	  (not
 	   (and
 	    completion-ignored-extensions
 	    (string-match
 	     (concat (regexp-opt completion-ignored-extensions 'paren) "$") x)
 	    ;; We remember the hit.
 	    (push x hits-ignored-extensions))))))
     ;; No match.  So we try again for ignored files.
     (try-completion filename hits-ignored-extensions))))

(defun vc-handle-file-newer-than-file-p (file1 file2)
  "Like `file-newer-than-file-p' for revisioned files."
  (cond
   ((not (file-exists-p file1)) nil)
   ((not (file-exists-p file2)) t)
   (t (time-less-p (file-attribute-modification-time
 		    (file-attributes file2))
 		   (file-attribute-modification-time
 		    (file-attributes file1))))))

(defalias 'vc-handle-file-readable-p 'vc-handle-file-exists-p
  "Like `file-readable-p' for revisioned.")

(defun vc-handle-file-regular-p (filename)
  "Like `file-regular-p' for revisioned files."
  (and (file-exists-p filename)
       (eq ?- (aref (file-attribute-modes (file-attributes filename)) 0))))

;; Of course, no revisioned file is remote per se.  But packages use
;; `file-remote-p' as indication, whether a file name could be used
;; literally.  So we return a non-nil value for handled file names.
(defun vc-handle-file-remote-p (filename &optional _identification _connected)
  "Like `file-remote-p' for revisioned files."
  (vc-handler-file-name-part filename))

(defun vc-handle-file-symlink-p (filename)
  "Like `file-symlink-p' for revisioned files."
  (let ((x (file-attribute-type (file-attributes filename))))
    (and (stringp x) x)))

(defun vc-handle-file-truename (filename)
  "Like `file-truename' for revisioned files."
  (if (file-symlink-p filename)
      (file-truename
       (concat
	(vc-handler-file-name-part filename) "@@/"
	(file-symlink-p filename)))
    (concat
     (file-truename (vc-handler-file-name-part filename))
     (vc-handler-file-revision-name filename))))

(defun vc-handle-insert-directory
    (filename switches &optional wildcard full-directory-p)
  "Like `insert-directory' for versioned files."
  (unless switches (setq switches ""))
  ;; Mark trailing "/".
  (when (and (zerop (length (file-name-nondirectory filename)))
 	     (not full-directory-p))
    (setq switches (concat switches "F")))
  (require 'ls-lisp)
  (let (ls-lisp-use-insert-directory-program start)
    (vc-run-real-handler
     'insert-directory
     (list filename switches wildcard full-directory-p))))

(defun vc-handle-insert-file-contents
    (filename &optional visit beg end replace)
  "Like `insert-file-contents' for revisioned files."
  (let* ((tmpfile (file-local-copy (file-truename filename)))
	 (result (insert-file-contents tmpfile visit beg end replace)))
    (when visit
      (setq buffer-file-name filename)
      (setq buffer-read-only (not (file-writable-p filename)))
      (set-visited-file-modtime)
      (set-buffer-modified-p nil))
    (delete-file tmpfile)
    (list (expand-file-name filename)
 	  (cadr result))))

(defun vc-handle-load (file &optional noerror nomessage nosuffix must-suffix)
  "Like `load' for revisioned files."
  (load (file-local-copy file) noerror nomessage nosuffix must-suffix))

(defun vc-handle-make-nearby-temp-file (prefix &optional dir-flag suffix)
  "Like `make-nearby-temp-file' for revisioned files."
  (let ((default-directory (unhandled-file-name-directory default-directory)))
    (make-nearby-temp-file (vc-handler-file-name-part prefix) dir-flag suffix)))

(defun vc-handle-process-file
    (program &optional infile buffer display &rest args)
  "Like `process-file' for revisioned files."
  (let ((default-directory (unhandled-file-name-directory default-directory)))
    (unless (file-directory-p default-directory)
      (setq default-directory
	    (file-name-directory (directory-file-name default-directory))))
    (apply 'process-file program infile buffer display args)))

(defun vc-handle-substitute-in-file-name (filename)
  "Like `substitute-in-file-name' for revisioned files."
  (concat
   (substitute-in-file-name (vc-handler-file-name-part filename))
   (vc-handler-file-revision-name filename)))

(defun vc-handle-verify-visited-file-modtime (&optional buf)
  "Like `verify-visited-file-modtime' for revisioned files."
  ;; Since all files are read-only, we check whether buffer has been modified.
  (not (buffer-modified-p (or buf (current-buffer)))))

(defun vc-handle-unhandled-file-name-directory (filename)
  "Like `unhandled-file-name-directory' for revisioned files."
  (vc-handler-file-name-part filename))

;; Debug.
(dolist (elt (all-completions "vc-handle-" obarray 'functionp))
  (trace-function-background (intern elt)))

(provide 'vc-handler)

;;; vc-handler.el ends here

;; Local Variables:
;; mode: Emacs-Lisp
;; coding: utf-8
;; End:

[-- Attachment #3: vc-git-handler.el --]
[-- Type: application/emacs-lisp, Size: 12566 bytes --]

;;; vc-git-handler.el --- File Name Handler for revisions of Git versioned files  -*- lexical-binding:t -*-

;; Copyright (C) 2017 Free Software Foundation, Inc.

;; Author: Michael Albinus <michael.albinus@gmx.de>
;; Keywords: vc tools
;; Package: vc

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This package provides file name handlers specific for Git.

;; A revision looks like "@@/master/ef7a18a071" or "@@/master/HEAD".
;; Branches are subdirectories, a revision in a branch might be
;; "@@/emacs-25/3a34412caa" or "@@/emacs-25/HEAD", and a label is a
;; symlink like "@@/emacs-25.2".  The element "HEAD" is always a
;; symlink to either the head of a branch, or to the current branch on
;; top level.

;;; Code:

(require 'vc-git)

;; New handlers should be added here.
(defconst vc-git-file-name-handler-alist
  '((file-attributes . vc-git-handle-file-attributes)
    (file-name-all-completions . vc-git-handle-file-name-all-completions)
    ;; TODO: Wouldn't it be better, to have `copy-file' here?
    (file-local-copy . vc-git-handle-file-local-copy))
  "Alist of Git specific handler functions.
Operations not mentioned here will be handled by vc-handler.el or
the default file name functions.")

;; Mark `operations' the handler is responsible for.
(put 'vc-file-name-handler 'operations
     (cl-union
      (get 'vc-file-name-handler 'operations)
      (mapcar 'car vc-git-file-name-handler-alist)))

;; Internal variables and functions.

(defvar vc-git-handler-branches nil
  "Cached local branch names.
The car of the list is the current branch.")

(defun vc-git-handler-branches ()
  "Return a list of local branches.
The car of the list is the current branch."
  (setq vc-git-handler-branches
	(vc-git-branches)))

(defvar vc-git-handler-tags nil
  "Cached tag names.")

(defun vc-git-handler-tags ()
  "Return a list of all tags."
  (setq vc-git-handler-tags
	(or vc-git-handler-tags
	    (split-string
	     (vc-git--run-command-string nil "tag") nil 'omit-nulls))))

(defvar vc-git-handler-heads nil
  "Cached alist of (OBJECT SHA1) tupels.
OBJECT is a branch name, a tag name, or \"HEAD\".")

(defun vc-git-handler-heads ()
  "Return an alist (OBJECT SHA1) tupels.
OBJECT is a branch name, a tag name, or \"HEAD\"."
  (setq vc-git-handler-heads
	(or vc-git-handler-heads
	    (mapcar
	     (lambda (x)
	       (list
		(replace-regexp-in-string
		 "refs/\\(tags\\|heads\\)/" "" (cadr x))
		(car x)))
	     (mapcar
	      ;; Hash object.
	      'split-string
	      ;; Lines.
	      (split-string
	       (vc-git--run-command-string
		nil "show-ref" "--heads" "--tags" "--head" "--abbrev")
	       "[\f\n]+" 'omit-nulls))))))

(defun vc-git-handler-head (object)
  "Return SHA1 of OBJECT.
OBJECT is a branch name, a tag name, or \"HEAD\"."
  (cadr (assoc object (vc-git-handler-heads))))

(defvar vc-git-handler-file-attributes (make-hash-table :test 'equal)
  "Cached file attributes.
It is a hash, the key is the revisioned file name, and the value
is the result of `file-attributes'.")

;; TODO: We shall add also functions to expire the caches.  Best would
;; be file notification, which watches respectice git files (indexes).

(defun vc-git-handler-object-exists-for-file-p (object filename)
  "Check, whether OBJECT (branch or tag) exists for FILE."
  ;; This is a sledge-hammer approach.  There must be something more
  ;; efficient.  For the time being, we simply return t.
  ;; (not
  ;;  (zerop
  ;;   (length
  ;;    (vc-git--run-command-string
  ;;     (vc-handler-file-name-part filename)
  ;;     "log" "--max-count=1" "--oneline" object "--")))))
  t)

;; The handlers.

(defun vc-git-handler-file-attributes-of-head (filename &optional id-format)
  "Like `file-attributes' for HEAD."
  (setq filename (expand-file-name filename))
  (let* ((file-name (vc-handler-file-name-part filename))
	 (revision (vc-handler-file-revision-name filename))
	 attr)
    ;; Revision is @@/branch/name/HEAD.
    (string-match "\\`@@\\(?:/\\(.*\\)\\)?/HEAD\\'" revision)
    (setq revision (match-string 1 revision)
	  attr
	  (file-attributes
	   (concat file-name "@@/" (vc-git-handler-head (or revision "HEAD")))
	   id-format))
    ;; Modify symlink.
    (if (zerop (length revision))
	(setcar attr (car (vc-git-handler-branches))) ;; Current branch.
      (setcar attr (vc-git-handler-head revision))) ;; Head of branch.
    (aset (nth 8 attr) 0 ?l)
    attr))

(defun vc-git-handle-file-attributes (filename &optional id-format)
  "Like `file-attributes' for revisioned files."
  (let ((cache-key (concat filename "@@" (symbol-name (or id-format 'integer))))
	attr)
    (cond
     ;; Cached value.
     ((setq attr (gethash cache-key vc-git-handler-file-attributes)))

     ;; Determine HEAD.
     ((string-equal (file-name-nondirectory filename) "HEAD")
      (setq attr (vc-git-handler-file-attributes-of-head filename id-format)))

     (t
      (setq filename (expand-file-name filename))
      (let* ((default-directory temporary-file-directory) ;; Avoid recursion.
             (file-name (vc-handler-file-name-part filename))
             (root (vc-git-root file-name))
             (default-directory (expand-file-name root))
	     (revision (vc-handler-file-revision-name filename))
	     git-log hash time author)
	(setq attr (file-attributes file-name id-format))
	;; Determine revision.
	(string-match "\\`@@/\\(.+\\)\\'" revision)
	(when (and (setq revision (match-string 1 revision))
		   ;; It could be branch/name/nnnnnnnnnn.
		   (file-name-directory revision)
		   (member
		    (directory-file-name (file-name-directory revision))
		    (vc-git-handler-branches)))
	  (setq revision (file-name-nondirectory revision)
		revision (unless (zerop (length revision)) revision)))

	;; Determine hash, commit time and commit author.
	(ignore-errors
	  (when (and (setq git-log
			   (vc-git--run-command-string
			    (unless (member revision (vc-git-handler-tags))
			      file-name)
			    "log" "--no-color" "--format=%h %at %an"
			    "--max-count=1" revision "--"))
		     (string-match
		      (concat
		       "\\`\\([[:alnum:]]+\\)[[:space:]]"
		       "\\([[:digit:]]+\\)[[:space:]]"
		       "\\(.+\\)\n?\\'")
		      git-log))
	    (setq hash (match-string 1 git-log)
		  time (string-to-number (match-string 2 git-log))
		  author (match-string 3 git-log))))

	;; Modify directory indicator.
	(when (or (null revision) (member revision (vc-git-handler-branches)))
	  (setcar attr t)
	  (aset (nth 8 attr) 0 ?d))

	;; Modify symlink.
	(when (member revision (vc-git-handler-tags))
	  (setcar attr hash)
	  (aset (nth 8 attr) 0 ?l))

	;; Modify uid and gid string.
	(when (and author (eq id-format 'string))
	  (setcar (nthcdr 2 attr) author)
	  (setcar (nthcdr 3 attr) "UNKNOWN"))

	;; Modify last access time, last modification time, and last
	;; status change time.
	(when time
	  (setcar
	   (nthcdr 4 attr) (list (floor time 65536) (floor (mod time 65536))))
	  (setcar
	   (nthcdr 5 attr) (list (floor time 65536) (floor (mod time 65536))))
	  (setcar
	   (nthcdr 6 attr) (list (floor time 65536) (floor (mod time 65536)))))

	;; Modify file size.
	(ignore-errors
	  (and revision
	       (setq git-log
		     (vc-git--run-command-string
		      nil "cat-file" "-s"
		      (format
		       "%s:%s" revision (file-relative-name file-name))))
	       (string-match "\\`\\([[:digit:]]+\\)\n?\\'" git-log)
	       (setcar
		(nthcdr 7 attr) (string-to-number (match-string 1 git-log)))))

	;; Modify mode string.  Remove write bit, and add execute bit
	;; for directories.
	(aset (nth 8 attr) 2 ?-)
	(aset (nth 8 attr) 5 ?-)
	(aset (nth 8 attr) 8 ?-)
	(when (char-equal (aref (nth 8 attr) 0) ?d)
	  (when (char-equal (aref (nth 8 attr) 1) ?r)
	    (aset (nth 8 attr) 3 ?x))
	  (when (char-equal (aref (nth 8 attr) 4) ?r)
	    (aset (nth 8 attr) 6 ?x))
	  (when (char-equal (aref (nth 8 attr) 7) ?r)
	    (aset (nth 8 attr) 9 ?x))))))

    ;; TODO: we need also to modify inode, device-number.

    ;; Result.
    (puthash cache-key attr vc-git-handler-file-attributes)))

;; This function should return "foo/" for directories and "bar" for files.
(defun vc-git-handle-file-name-all-completions (filename directory)
  "Like `file-name-all-completions' for revisioned files."
  (let* ((file-name (vc-handler-file-name-part directory))
	 (branch (vc-handler-file-revision-name directory))
	 (default-directory (unhandled-file-name-directory file-name))
	 base all-revisions all-tags all-branches)
    (unless (file-directory-p default-directory)
      (setq default-directory
	    (file-name-directory (directory-file-name default-directory))))
    ;; Read branch specific revisions.
    ;; TODO: This yields all revisions reachable from the branch head.
    ;; It might be better to return only revisions starting when the
    ;; branch was created, but I don't know how to determine this.
    ;; "git merge-base --fork-point <branch>" sounds like a good
    ;; candidate, but it doesn't work as expected.
    (string-match "\\`@@/\\(.+\\)\\'" branch)
    (when (and (setq branch (match-string 1 branch))
	       (setq branch (directory-file-name branch)))
      (ignore-errors
	(with-temp-buffer
	  (and
	   (vc-git-command
	    (current-buffer) nil file-name
	    "log" "--no-color" "--format=%h" branch "--")
	   (goto-char (point-min))
	   (while (< (point) (point-max))
	     (push
	      (buffer-substring-no-properties (point) (line-end-position))
	      all-revisions)
	     (forward-line 1))))))
    ;; Every branch has a virtual HEAD.
    (setq all-revisions (cons "HEAD" all-revisions))

    ;; Read tags.
    (setq all-tags
	  (mapcar
	   (lambda (x)
	     (and
	      (if branch
		  ;; Mention only tags belonging to branch.
		  (member (vc-git-handler-head x) all-revisions)
		;; All existing tags for that file.
		(vc-git-handler-object-exists-for-file-p x file-name))
	      x))
	   (vc-git-handler-tags)))

    ;; Read branches in top level for that file.  Add trailing "/".
    (unless branch
      (setq all-branches
	    (mapcar
	     (lambda (x)
	       (and (vc-git-handler-object-exists-for-file-p x file-name)
		    (file-name-as-directory x)))
	     (vc-git-handler-branches))))

    ;; Result.
    (all-completions
     filename (delq nil (append all-revisions all-tags all-branches)))))

(defun vc-git-handle-file-local-copy (filename)
  "Like `file-local-copy' for revisioned files."
  (setq filename (expand-file-name filename))
  (let* ((default-directory temporary-file-directory) ;; Avoid recursion.
         (file-name (vc-handler-file-name-part filename))
         (root (vc-git-root file-name))
         (default-directory (expand-file-name root))
	 (revision (vc-handler-file-revision-name filename))
	 (result
	  (make-temp-file "vc-" nil (file-name-extension file-name 'period))))
    ;; Determine revision.
    (string-match "\\`@@/\\(.+\\)\\'" revision)
    (when (setq revision (match-string 1 revision))
      (setq revision (file-name-nondirectory revision))
      (with-temp-buffer
        (and
	 (vc-git-command
	  (current-buffer) nil nil
	  "show" (format "%s:%s" revision (file-relative-name file-name)))
	 (write-region nil nil result)))
      ;; Set attributes.
      (set-file-times
       result (file-attribute-modification-time (file-attributes filename)))
      (set-file-modes result (file-modes filename))
      result)))

;; Debug.
(dolist (elt (all-completions "vc-git-" obarray 'functionp))
  (trace-function-background (intern elt)))

(provide 'vc-git-handler)

;;; vc-git-handler.el ends here

;; Local Variables:
;; mode: Emacs-Lisp
;; coding: utf-8
;; End:

Re: git-handler.el

[Jonas Bernoulli]

Michael Albinus <michael.albinus@gmx.de> writes:
> As a warmup, I have written vc-handler.el and vc-git-handler.el. They
> are far from being complete, but they'll show what's possible.

Great!  I didn't have a change to look at this much yet, hope to get to
it in a week or so.

> A revisioned filename is something like "/path/to/file@@revision".
> "revision" could be a revision like "81656add81", a branch like
> "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
> could be changed.

I would prefer /path/to/repo/@git:REVISION:path/to/file.  I don't have
a strong opinion about what the magic cookie should look like, but I
think it should be inserted at the root of the working tree.

> vc-handler.el is the common part. There is the alist
> `vc-file-name-handler-alist', which lists for every magic file name
> function the responsible handler function. The majority of them is also
> implemented in vc-handler.el, because they don't need any vcs specific
> handling.
>
> For every different backend, there could be a respective backend
> package. I've implemented vc-git-handler.el, because I know more about
> vc-git than magit. But there's no problem to implement vc-magit.el, for
> example. I plan also to write at least vc-cvs.el.

As I said I haven't looked at the code much yet, so I don't know what
the implications of having alternative handlers for the same vc would
be.  But I fear that it would reduce interoperability.  But packages
other than VC should be able to customize the behavior to some extend
and that could probably be implemented using a few hooks and *-function
variables.

> You might play a little bit to see how it looks like. Maybe the most
> simple start is to enter dired, because it uses many of the magic file
> name operations. Just do "C-x d ~/src/emacs/src/emacs.c@@" (supposed
> your Emacs git is located at ~/src/emacs, as in my case).

Speaking of Dired, trees (directories) should be supported in addition
to blobs (files), among other things that would allow visiting them in
Dired.

> Both packages are far from being complete. Performance is terrible (a
> proper cache mechanism is needed),

In what way is performance terrible?  I would have expected that asking
git for information about one blob would not be that much more expensive
than asking the file-system for the same information about one file.
(I.e. the the difference would only become relevant if you needed
information about many files.)

> my git skill is restricted so I might
> not use the best commands, and you will see many TODO comments.

I will try to help with that, but I am a little busy right now.

> It's
> just a proof of concept. And I hope it is useful for both magit and vc.

I am sure we can get it there.  Some more thoughts:

What happens when you visit say HEAD:file and then HEAD is updated?  I
think this should behave much the same as for files that are modified on
disk.  The user could then use `revert-buffer' to update the buffer.

You mentioned in another message that this is read-only.  While that's a
good default, I think it should be possible for Magit or something else
to provide a `modified-p' and a `save-file' function by setting some
`*-function' variables.

It would help me and others that are not very familiar with VC's
internals to understand the file-handler parts if you could create one
commit that implements those parts without taking advantage of any
caching provided by VC and then add that caching in a separate commit.

  Cheers,
  Jonas

Ps: I'll probably be unavailable for a few days.

Re: git-handler.el

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Sat, 12 Aug 2017 12:48:22 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > A revisioned filename is something like "/path/to/file@@revision".
> > "revision" could be a revision like "81656add81", a branch like
> > "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
> > could be changed.
> 
> I would prefer /path/to/repo/@git:REVISION:path/to/file.  I don't have
> a strong opinion about what the magic cookie should look like, but I
> think it should be inserted at the root of the working tree.

That doesn't scale to VCSes which keep separate versions for
individual files.  Michael's scheme does support such VCSes.  For a
VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I
think.  If you disagree, please show some use cases where this could
cause trouble.

Re: git-handler.el

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Date: Sat, 12 Aug 2017 12:48:22 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
>>
>> > A revisioned filename is something like "/path/to/file@@revision".
>> > "revision" could be a revision like "81656add81", a branch like
>> > "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
>> > could be changed.
>>
>> I would prefer /path/to/repo/@git:REVISION:path/to/file.  I don't have
>> a strong opinion about what the magic cookie should look like, but I
>> think it should be inserted at the root of the working tree.
>
> That doesn't scale to VCSes which keep separate versions for
> individual files.

How so?  Wouldn't my scheme just look like:

  /path/to/dir-containing-closest-control-file/<vcs>@<rev>:<file>

instead of

  /path/to/dir-containing-closest-control-file/<vcs>@<file>/<rev>

when trying to stay as close the internals of that <vcs>?

Also isn't that an implementation detail and users of <vcs> still
think of "/path/to/top" as "the repository"?  If that is so then
what should it matter that <vcs> spreads the history files across
the repository instead of putting them into a dedicated control
directory?

Using such a <vcs> and given:

  /path/to/top/
  |- fileA
  |- .fileA.history
  `- subdir/
     |- fileB
     `- .fileB.history

I don't know whether its users would prefer

  A1) /path/to/top/<vcs>@<rev>:<subdir>/<fileB>
  A2) /path/to/top/<vcs>@<subdir>/<fileB>/<rev>

or

  B1) /path/to/top/subdir/<vcs>@<rev>:<fileB>
  B2) /path/to/top/subdir/<vcs>@<fileB>/<rev>

But even if to users of <vcs> (B) is preferable to (A), I don't see
how (B2) is superior to (B1), or how (B1) is even incompatible.

But I never used such a vcs, so probably I am missing something.

> Michael's scheme does support such VCSes.  For a
> VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I
> think.

Maybe we could use different schemes for different vc systems.

> If you disagree, please show some use cases where this could
> cause trouble.

I care more about the conceptual consistency than use cases at this
point, because I think that even if we cannot think of any concrete
issues now, we are sure to eventually run into.

The revision is part of a virtual directory structure and it should
appear in the correct (i.e. hierarchic) place.  People have come to
expect a hierarchic structure when dealing with files, and if we break
that consistency (just for compatibility with legacy vc systems), then
that will cause confusion.

This is one way of accessing <blob> as stored in <branch>:

  cd /tmp/repo
  git worktree add ../repo_<branch> <branch>
  find-file /tmp/repo_<branch>/<blob>

And with a file handler instead of a worktree checkout:

  cd /tmp/repo
  find-file /tmp/repo/git@<branch>:<blob>
    or
  find-file /tmp/repo/@@<blob>/<branch

Clearly only the scheme I suggested is consistent with the expectation
of a hierarchic directory structure.

One example use case where the scheme that I propose would be nicer than
the non-hierarchic one is "using find-file to open another blob from the
same revision/tree".

Re: git-handler.el

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: michael.albinus@gmx.de, emacs-devel@gnu.org, dgutov@yandex.ru
> Date: Sat, 12 Aug 2017 19:26:15 +0200
> 
> >> > A revisioned filename is something like "/path/to/file@@revision".
> >> > "revision" could be a revision like "81656add81", a branch like
> >> > "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
> >> > could be changed.
> >>
> >> I would prefer /path/to/repo/@git:REVISION:path/to/file.  I don't have
> >> a strong opinion about what the magic cookie should look like, but I
> >> think it should be inserted at the root of the working tree.
> >
> > That doesn't scale to VCSes which keep separate versions for
> > individual files.
> 
> How so?  Wouldn't my scheme just look like:
> 
>   /path/to/dir-containing-closest-control-file/<vcs>@<rev>:<file>
> 
> instead of
> 
>   /path/to/dir-containing-closest-control-file/<vcs>@<file>/<rev>
> 
> when trying to stay as close the internals of that <vcs>?

Well, for starters, it will defeat the completion machinery, or at
least make it much more complicated.

> Also isn't that an implementation detail and users of <vcs> still
> think of "/path/to/top" as "the repository"?  If that is so then
> what should it matter that <vcs> spreads the history files across
> the repository instead of putting them into a dedicated control
> directory?

FILE@@revision is not a history file, it is FILE as it looked like at
given VERSION.  Where that information is kept is beside the point.
As I'm sure you understand, so I guess I don't really see the point
you are making here.

> > Michael's scheme does support such VCSes.  For a
> > VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I
> > think.
> 
> Maybe we could use different schemes for different vc systems.

That would be undesirable, I think.

> The revision is part of a virtual directory structure

Sorry, you lost me.  What is that "virtual directory structure", and
how is it relevant to this issue?

> This is one way of accessing <blob> as stored in <branch>:

We are talking about abstractions, not about their Git implementation.
So why do we have to consider blobs?

> One example use case where the scheme that I propose would be nicer than
> the non-hierarchic one is "using find-file to open another blob from the
> same revision/tree".

I guess I'm so Git-ignorant that I don't even understand what that
means.  Maybe I shouldn't be part of this discussion.

Re: git-handler.el

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

> How so?  Wouldn't my scheme just look like:
>
>   /path/to/dir-containing-closest-control-file/<vcs>@<rev>:<file>
>
> instead of
>
>   /path/to/dir-containing-closest-control-file/<vcs>@<file>/<rev>
>
> when trying to stay as close the internals of that <vcs>?

First, we have to agree the file name *syntax*. There shall be a cookie
which delimits the regular file name from the vcs specific part. And the
vcs name shall not be part of the whole file name, this is not
necessary.

I have proposed "@@" as cookie at the end of the regular file or
directory name, a directory indication like a slash prior this cookie is
not needed I believe. I have decided for the double "@@" because it
gives a user more attention. People who have used ClearCase might know
where I have taken this from, but this doesn't matter for the decision.

Could you live with that proposal?

The vcs specific part shall also look the same for all involved
VCSes. It would be great if the semantics is always the same as well (in
the file oriented view, branches are directories, revisions are files,
and labels are symlinks), but I don't know whether we could keep this.

Best regards, Michael.

Re: git-handler.el

[John Wiegley]

>>>>> "JB" == Jonas Bernoulli <jonas@bernoul.li> writes:

JB> I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have a
JB> strong opinion about what the magic cookie should look like, but I think
JB> it should be inserted at the root of the working tree.

I would prefer having both: sometimes I want to "browse into the Git tree at a
revision", and sometimes I'm already in a deep directory within a project, and
I want to think in terms of "browse into the many past versions of a given
file". Both make sense from different points of views.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: git-handler.el

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

> JB> I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have a
> JB> strong opinion about what the magic cookie should look like, but I think
> JB> it should be inserted at the root of the working tree.
>
> I would prefer having both: sometimes I want to "browse into the Git tree at a
> revision", and sometimes I'm already in a deep directory within a project, and
> I want to think in terms of "browse into the many past versions of a given
> file". Both make sense from different points of views.

Same here. I'm just writing an extension of the specification, covering
both cases. Not sure, whether I'll finish tonight.

Best regards, Michael.

Re: git-handler.el

[Jonas Bernoulli]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "JB" == Jonas Bernoulli <jonas@bernoul.li> writes:
>
> JB> I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have a
> JB> strong opinion about what the magic cookie should look like, but I think
> JB> it should be inserted at the root of the working tree.
>
> I would prefer having both: sometimes I want to "browse into the Git tree at a
> revision", and sometimes I'm already in a deep directory within a project, and
> I want to think in terms of "browse into the many past versions of a given
> file". Both make sense from different points of views.

Yes of course.  Unfortunately we cannot have both without making an
additional effort. (*)

When using the REV:PATH scheme "another file from the same revision"
works exactly the same as "another file from the same directory", but
even when using the PATH:REV scheme the "same file, another revision"
use-case only (loosely) corresponds to an operation on regular files:
"same file, from this other revision whose human readable name I know".

So if you are visiting "/path/to/@@file/some-feature", it would be nice
if `find-file' gave you "Find file: /path/to/@@file/" and you could type
"ma TAB RET" to visit "/path/to/@@file/master".  But that's only one
variant of "same file, another revision" and probably not even the most
common one.

Another variant would be "same file, next/previous revision" where
next/previous could have different meanings.  A common one is "the
next/previous revision which touched this line".  Currently there's even
exists a package just for that use case: `git-timemachine'.

(Magit also provides that same feature but the implementations are not
compatible.  `git-timemachine' reuses the same buffer to visit different
version of the file (which has the benefit that no buffers have to be
cleaned up later), while Magit uses a new buffer (which allows you to
look at different versions of the same file at once).)

Anyway, I don't think it makes sense to teach `find-file' about going to
the next/previous revision.  Instead that use-case should be handled by
separate commands, which would likely be bound to "<some-prefix> n" and
"<some-prefix> p" (that's what `git-timemachine' and Magit currently do).

The point I am trying to make here is that `find-file' cannot possibly
the right command to handle all cases of "same file, another revision"
with ease, while it is completely suitable for "same revision, another
revision", with no extra effort.  But only if we go with the REV:PATH
scheme.

(*) If we go with the REV:FILE scheme then I propose that we make the
    "same file, another *named* revision" use-case easy by adding a
    separate command just for that.  The user would be presented with
    "Find revision of file /path/to/: ".  And if the user already
    invoked `find-file' or a variant thereof, then there should be
    a key binding to abort that and switch to the "change revision"
    command instead.

Re: git-handler.el

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

> So if you are visiting "/path/to/@@file/some-feature", it would be nice
> if `find-file' gave you "Find file: /path/to/@@file/" and you could type
> "ma TAB RET" to visit "/path/to/@@file/master".  But that's only one
> variant of "same file, another revision" and probably not even the most
> common one.

That shall work out-of-the-box, file-name-all-completions knows of branches.

> Another variant would be "same file, next/previous revision" where
> next/previous could have different meanings.  A common one is "the
> next/previous revision which touched this line".  Currently there's even
> exists a package just for that use case: `git-timemachine'.
>
> (Magit also provides that same feature but the implementations are not
> compatible.  `git-timemachine' reuses the same buffer to visit different
> version of the file (which has the benefit that no buffers have to be
> cleaned up later), while Magit uses a new buffer (which allows you to
> look at different versions of the same file at once).)

That's not possible with magic file name handler operations as they are
defined now. They don't give you the ability to say something about the
file contents.

> Anyway, I don't think it makes sense to teach `find-file' about going to
> the next/previous revision.  Instead that use-case should be handled by
> separate commands, which would likely be bound to "<some-prefix> n" and
> "<some-prefix> p" (that's what `git-timemachine' and Magit currently do).

I agree. New commands in dired would serve, indeed. But that would be
backend specific.

> The point I am trying to make here is that `find-file' cannot possibly
> the right command to handle all cases of "same file, another revision"
> with ease, while it is completely suitable for "same revision, another
> revision", with no extra effort.  But only if we go with the REV:PATH
> scheme.

Isn't my proposal what you have in mind? Both
/home/albinus/src/emacs/lisp@@/ef7a18a071/display-line-numbers.el and
/home/albinus/src/emacs@@/ef7a18a071/lisp/display-line-numbers.el would
point to the same revision ef7a18a071 of lisp/display-line-numbers.el.

Best regards, Michael.

Re: git-handler.el

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

>> A revisioned filename is something like "/path/to/file@@revision".
>> "revision" could be a revision like "81656add81", a branch like
>> "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
>> could be changed.
>
> I would prefer /path/to/repo/@git:REVISION:path/to/file.  I don't have
> a strong opinion about what the magic cookie should look like, but I
> think it should be inserted at the root of the working tree.

No, we are speaking about file name handlers. So we must give the syntax
a chance to address just one file. As Eli said, think about other VCSes,
like CVS. Your syntax wouldn't match.

I believe we should not use the VCS name, like "git", in the file name
syntax. There is no need for it, because we could offer a variable
`vc-handler-backend' or so, in which a user could tell us the preferred
backend. It could be one of the values of `vc-handled-backends' like
`Git', or it could be something different like the symbol `Magit'.

If this variable is declared directory-local at project root, the user
don't need to think about ever. If that variable is nil, the fallback
would be the vc mechanism via the `vc-responsible-backend' call, as I
have already implemented. Or something else.

I would also recommend to avoid using ":" in the file name. Although we
haven't the case yet, I fear that we would clash some day with Tramp
file name syntax.

So I'm back to the syntax "/path/to/file@@<backend specific>" or
"/path/to/directory@@<backend specific>". Note the /path/to/directory
case I haven't mentioned before, and which isn't implemented yet in the
code. There's no need to use the slash prior the cookie @@, because this
will be detected by ordinary file operations. About the
/path/to/directory@@... semantics more below.

>> vc-handler.el is the common part. There is the alist
>> `vc-file-name-handler-alist', which lists for every magic file name
>> function the responsible handler function. The majority of them is also
>> implemented in vc-handler.el, because they don't need any vcs specific
>> handling.
>>
>> For every different backend, there could be a respective backend
>> package. I've implemented vc-git-handler.el, because I know more about
>> vc-git than magit. But there's no problem to implement vc-magit.el, for
>> example. I plan also to write at least vc-cvs.el.
>
> As I said I haven't looked at the code much yet, so I don't know what
> the implications of having alternative handlers for the same vc would
> be.  But I fear that it would reduce interoperability.  But packages
> other than VC should be able to customize the behavior to some extend
> and that could probably be implemented using a few hooks and *-function
> variables.

I don't see yet what you have in mind. Implementing all magic file name
operations is sufficient in my understanding. vc-handler.el shall be
the common part for all VCSes, and vc-<backend>-handler.el shall be the
backend specific part. Beside the `vc-responsible-backend' call I've
mentioned above, there is no vc*.el functionality used in
vc-handler.el. Maybe the name is misleading here.

I have established a mechanism, allowing backend specific handlers to
overrule common ones. `vc-git-handle-file-attributes' takes priority
over `vc-handle-file-attributes' in my implementation. So could
(vc-)magit-handle-* functions.

>> You might play a little bit to see how it looks like. Maybe the most
>> simple start is to enter dired, because it uses many of the magic file
>> name operations. Just do "C-x d ~/src/emacs/src/emacs.c@@" (supposed
>> your Emacs git is located at ~/src/emacs, as in my case).
>
> Speaking of Dired, trees (directories) should be supported in addition
> to blobs (files), among other things that would allow visiting them in
> Dired.

Dired itself doesn't matter too much for the file name handler
business. It is just a proper UI in order to explore the possibilities.

In my previous mail I have described how a file oriented view would
look like. Take the Emacs source tree, and file
lisp/display-line-numbers.el as example (I take it, because it has a
short commit history :-) In dired, there exists then

--8<---------------cut here---------------start------------->8---
  /home/albinus/src/emacs/lisp/display-line-numbers.el@@:
  total 12
  lr--r--r--  1 Paul Eggert     UNKNOWN 3922 08-03 04:46 emacs23 -> a8a81df8da
  lr--r--r--  1 Michael Albinus UNKNOWN 3922 08-01 10:13 HEAD -> master
  dr-xr-xr-x  1 Michael Albinus UNKNOWN 3922 08-01 10:13 master

  /home/albinus/src/emacs/lisp/display-line-numbers.el@@/master:
  total 23
  -r--r--r--  1 Michael Albinus   UNKNOWN 3846 07-23 09:28 012487bc41
  -r--r--r--  1 Mark Oteiza       UNKNOWN 3937 07-25 02:17 32daa3cb54
  -r--r--r--  1 Alexander Gramiak UNKNOWN 3831 07-22 11:16 ebb78a7bfa
  -r--r--r--  1 Michael Albinus   UNKNOWN 3922 08-01 10:13 ef7a18a071
  -r--r--r--  1 Mark Oteiza       UNKNOWN 3960 07-23 21:41 f57c710772
  lr--r--r--  1 Michael Albinus   UNKNOWN 3922 08-01 10:13 HEAD -> 81e22163eb
--8<---------------cut here---------------end--------------->8---

The file belongs only to the master branch so far; if it would belong to
other branches, there would be respective subdirectories. And there is
only one label on that file so far, emacs23. (Btw, where does it come from?)

A revision oriented view would start with a directory, and not with a
file. Let's use lisp/, and revision ef7a18a071

--8<---------------cut here---------------start------------->8---
  /home/albinus/src/emacs/lisp@@:
  total 12
  lr--r--r--  1 Paul Eggert     UNKNOWN 3922 08-03 04:46 emacs23 -> a8a81df8da
  lr--r--r--  1 Michael Albinus UNKNOWN 3922 08-01 10:13 HEAD -> master
  dr-xr-xr-x  1 Michael Albinus UNKNOWN 3922 08-01 10:13 master
  [... Other branches] 
  dr-xr-xr-x  1 Michael Albinus   UNKNOWN 3922 08-01 10:13 ef7a18a071
  [... Other revisions] 

  /home/albinus/src/emacs/lisp@@/ef7a18a071:
  total 23
  -r--r--r--  1 Michael Albinus   UNKNOWN   3922 08-01 10:13 display-line-numbers.el
  -r--r--r--  1 Michael Albinus   UNKNOWN 109714 08-01 10:13 menu-bar.el
--8<---------------cut here---------------end--------------->8---

(This example I have written manually, it is not implemented yet).

You see the difference. In the file oriented view, we have
"/home/albinus/src/emacs/lisp/display-line-numbers.el@@/master" being a
directory, containing all revisions and labels as regulary files.

In the revision oriented view, we have
"/home/albinus/src/emacs/lisp@@/ef7a18a071" being a directory,
containing the files which have been modified by this commit.

This is just the basic idea, and it would work for other backends as
well. For CVS, the revision oriented view would just offer one file for
a given commit, and likely several files for a given label (which is a
directory or a symlink to a directory).

>> Both packages are far from being complete. Performance is terrible (a
>> proper cache mechanism is needed),
>
> In what way is performance terrible?  I would have expected that asking
> git for information about one blob would not be that much more expensive
> than asking the file-system for the same information about one file.
> (I.e. the the difference would only become relevant if you needed
> information about many files.)

For one blob it might perform better. But I have implemented the file
oriented view first, which asks information for every file containing to
a blob again and again. `vc-git-handle-file-attributes', for example,
raises two process calls. Much place for improvement, of course.

> What happens when you visit say HEAD:file and then HEAD is updated?  I
> think this should behave much the same as for files that are modified on
> disk.  The user could then use `revert-buffer' to update the buffer.

Yep. See the comment in vc-git-handler.el:

;; TODO: We shall add also functions to expire the caches.  Best would
;; be file notification, which watches respective git files (indexes).

Once the cache expires the information of a file, let's say the
`file-attributes' information, new information is retrieved next time
`file-attributes' is called. Emacs will warn you then that the buffer
contents is not current. You could revert.

> You mentioned in another message that this is read-only.  While that's a
> good default, I think it should be possible for Magit or something else
> to provide a `modified-p' and a `save-file' function by setting some
> `*-function' variables.

I don't understand. What do you need, which is not handled by basic file
operations, like `verify-visited-file-modtime'?

> It would help me and others that are not very familiar with VC's
> internals to understand the file-handler parts if you could create one
> commit that implements those parts without taking advantage of any
> caching provided by VC and then add that caching in a separate commit.

I have no plan yet for committing something, because I don't know where
it shall go. Emacs core? ELPA?

>   Cheers,
>   Jonas
>
> Ps: I'll probably be unavailable for a few days.

No problem, take your time.

Best regards, Michael.

Re: git-handler.el

[Yuri Khan]

On Sun, Aug 13, 2017 at 2:17 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

> A revision oriented view would start with a directory, and not with a
> file. Let's use lisp/, and revision ef7a18a071
>
> --8<---------------cut here---------------start------------->8---
>   /home/albinus/src/emacs/lisp@@/ef7a18a071:
>   total 23
>   -r--r--r--  1 Michael Albinus   UNKNOWN   3922 08-01 10:13 display-line-numbers.el
>   -r--r--r--  1 Michael Albinus   UNKNOWN 109714 08-01 10:13 menu-bar.el
> --8<---------------cut here---------------end--------------->8---
>
> (This example I have written manually, it is not implemented yet).
>
> In the revision oriented view, we have
> "/home/albinus/src/emacs/lisp@@/ef7a18a071" being a directory,
> containing the files which have been modified by this commit.

This will not be sufficient. As a Git user, I frequently want to
browse the whole repository as of a specific revision. Use case: “Two
months ago, function foo was changed to call function bar. How did bar
look at that point?”

Also, in a dired buffer showing src/emacs/lisp@@/ef7a18a071, will
dired-jump jump to src/emacs@@/ef7a18a071?

Re: git-handler.el

[Michael Albinus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

Hi Yuri,

>> A revision oriented view would start with a directory, and not with a
>> file. Let's use lisp/, and revision ef7a18a071
>>
>> --8<---------------cut here---------------start------------->8---
>>   /home/albinus/src/emacs/lisp@@/ef7a18a071:
>>   total 23
>>   -r--r--r-- 1 Michael Albinus UNKNOWN 3922 08-01 10:13
>> display-line-numbers.el
>>   -r--r--r--  1 Michael Albinus   UNKNOWN 109714 08-01 10:13 menu-bar.el
>> --8<---------------cut here---------------end--------------->8---
>>
>> (This example I have written manually, it is not implemented yet).
>>
>> In the revision oriented view, we have
>> "/home/albinus/src/emacs/lisp@@/ef7a18a071" being a directory,
>> containing the files which have been modified by this commit.
>
> This will not be sufficient. As a Git user, I frequently want to
> browse the whole repository as of a specific revision. Use case: “Two
> months ago, function foo was changed to call function bar. How did bar
> look at that point?”

You know, that function bar is declared in file baz.el. So you could
inspect the revisions of baz.el by looking into directory
"/home/albinus/src/emacs/lisp/baz.el@@/master" (given you're interested
in branch master).

> Also, in a dired buffer showing src/emacs/lisp@@/ef7a18a071, will
> dired-jump jump to src/emacs@@/ef7a18a071?

Could be, yes. Likely, it needs some adaption of dired-jump (it uses
file-name-directory for traversing the directory path), but why not.

Best regards, Michael.

Re: git-handler.el

[Yuri Khan]

On Sun, Aug 13, 2017 at 4:14 PM, Michael Albinus <michael.albinus@gmx.de> wrote:

>> As a Git user, I frequently want to
>> browse the whole repository as of a specific revision. Use case: “Two
>> months ago, function foo was changed to call function bar. How did bar
>> look at that point?”
>
> You know, that function bar is declared in file baz.el.

Not necessarily. It is today, but two months ago it could have resided
in any of baz.el, quux.el or xyzzy.el.

> So you could
> inspect the revisions of baz.el by looking into directory
> "/home/albinus/src/emacs/lisp/baz.el@@/master" (given you're interested
> in branch master).

In the use case being discussed, I’m not interested in master. Or,
more specifically, not in its current position, and not in the whole
set of its commits that modify baz.el. I am interested in one specific
commit, say ef7a18a071, that does not modify baz.el. Presented by a
list of commits modifying baz.el, I will literally be unable to find
the revision I’m interested in. (No, making a note of the commit
timestamp and bisecting the other commit list for that will not work.
In Git, chronological order is not guaranteed within a branch.)

(Because Emacs is all about custom and idiosyncratic workflows[1], here’s mine:

* I never use find-file interactively except to create a new file or
jump to a directory on a remote server (via Tramp).
* I navigate from a file to its containing directory or from a
directory to its parent using dired-jump, and from a directory to a
file using dired-find-file.

[1]: https://xkcd.com/1172/ )

>> Also, in a dired buffer showing src/emacs/lisp@@/ef7a18a071, will
>> dired-jump jump to src/emacs@@/ef7a18a071?
>
> Could be, yes. Likely, it needs some adaption of dired-jump (it uses
> file-name-directory for traversing the directory path), but why not.

Re: git-handler.el

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 13 Aug 2017 17:08:35 +0700
> Cc: Jonas Bernoulli <jonas@bernoul.li>, Dmitry Gutov <dgutov@yandex.ru>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, Aug 13, 2017 at 4:14 PM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> >> As a Git user, I frequently want to
> >> browse the whole repository as of a specific revision. Use case: “Two
> >> months ago, function foo was changed to call function bar. How did bar
> >> look at that point?”
> >
> > You know, that function bar is declared in file baz.el.
> 
> Not necessarily. It is today, but two months ago it could have resided
> in any of baz.el, quux.el or xyzzy.el.

If you don't know its file, how will you find it?

> > So you could
> > inspect the revisions of baz.el by looking into directory
> > "/home/albinus/src/emacs/lisp/baz.el@@/master" (given you're interested
> > in branch master).
> 
> In the use case being discussed, I’m not interested in master. Or,
> more specifically, not in its current position, and not in the whole
> set of its commits that modify baz.el. I am interested in one specific
> commit, say ef7a18a071, that does not modify baz.el.

Then you should look inside src/emacs/lisp@@/ef7a18a071, I think.  Why
is that a problem?

> * I never use find-file interactively except to create a new file or
> jump to a directory on a remote server (via Tramp).
> * I navigate from a file to its containing directory or from a
> directory to its parent using dired-jump, and from a directory to a
> file using dired-find-file.

This just means Dired will need to be taught about these special file
names.

Re: git-handler.el

[Yuri Khan]

On Sun, Aug 13, 2017 at 9:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> >> As a Git user, I frequently want to
>> >> browse the whole repository as of a specific revision. Use case: “Two
>> >> months ago, function foo was changed to call function bar. How did bar
>> >> look at that point?”
>> >
>> > You know, that function bar is declared in file baz.el.
>>
>> Not necessarily. It is today, but two months ago it could have resided
>> in any of baz.el, quux.el or xyzzy.el.
>
> If you don't know its file, how will you find it?

By trial and error. Find the directory at revision, L1: choose the
next most probable file, look in there. Repeat from L1 until found.

>> > So you could
>> > inspect the revisions of baz.el by looking into directory
>> > "/home/albinus/src/emacs/lisp/baz.el@@/master" (given you're interested
>> > in branch master).
>>
>> In the use case being discussed, I’m not interested in master. Or,
>> more specifically, not in its current position, and not in the whole
>> set of its commits that modify baz.el. I am interested in one specific
>> commit, say ef7a18a071, that does not modify baz.el.
>
> Then you should look inside src/emacs/lisp@@/ef7a18a071, I think.  Why
> is that a problem?

I got the impression that, in the proposed scheme, <path>@@<revision>
only shows files under <path> that are modified by the commit
<revision>. There is no problem for me if it shows *all* files under
<path> that existed at that <revision>.

Re: git-handler.el

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 13 Aug 2017 22:08:55 +0700
> Cc: Michael Albinus <michael.albinus@gmx.de>, Jonas Bernoulli <jonas@bernoul.li>, 
> 	Dmitry Gutov <dgutov@yandex.ru>, Emacs developers <emacs-devel@gnu.org>
> 
> >> Not necessarily. It is today, but two months ago it could have resided
> >> in any of baz.el, quux.el or xyzzy.el.
> >
> > If you don't know its file, how will you find it?
> 
> By trial and error. Find the directory at revision, L1: choose the
> next most probable file, look in there. Repeat from L1 until found.

Then going to a directory @VERSION should be fine for your use case,
AFAIU.

> >> In the use case being discussed, I’m not interested in master. Or,
> >> more specifically, not in its current position, and not in the whole
> >> set of its commits that modify baz.el. I am interested in one specific
> >> commit, say ef7a18a071, that does not modify baz.el.
> >
> > Then you should look inside src/emacs/lisp@@/ef7a18a071, I think.  Why
> > is that a problem?
> 
> I got the impression that, in the proposed scheme, <path>@@<revision>
> only shows files under <path> that are modified by the commit
> <revision>. There is no problem for me if it shows *all* files under
> <path> that existed at that <revision>.

I think it's the latter (for a VCS where a version marks the entire
tree), but maybe I misunderstood what Michael meant.

Re: git-handler.el

[Michael Albinus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> Then you should look inside src/emacs/lisp@@/ef7a18a071, I think.  Why
>> is that a problem?
>
> I got the impression that, in the proposed scheme, <path>@@<revision>
> only shows files under <path> that are modified by the commit
> <revision>. There is no problem for me if it shows *all* files under
> <path> that existed at that <revision>.

Both approaches make sense. Maybe we shall spend an option to control
what is shown.

Best regards, Michael.

Re: git-handler.el

[Michael Albinus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Sun, Aug 13, 2017 at 4:14 PM, Michael Albinus <michael.albinus@gmx.de> wrote:
>
>>> As a Git user, I frequently want to
>>> browse the whole repository as of a specific revision. Use case: “Two
>>> months ago, function foo was changed to call function bar. How did bar
>>> look at that point?”
>>
>> You know, that function bar is declared in file baz.el.
>
> Not necessarily. It is today, but two months ago it could have resided
> in any of baz.el, quux.el or xyzzy.el.

I fear this cannot be followed easily with file name handlers. As the
feature says, file name handlers work on file level, not on function
level. Even "git log -L :<function>:<file>" does not return results for
other files.

>> So you could
>> inspect the revisions of baz.el by looking into directory
>> "/home/albinus/src/emacs/lisp/baz.el@@/master" (given you're interested
>> in branch master).
>
> In the use case being discussed, I’m not interested in master.

You could always use another branch.

> Or, more specifically, not in its current position, and not in the
> whole set of its commits that modify baz.el. I am interested in one
> specific commit, say ef7a18a071, that does not modify
> baz.el. Presented by a list of commits modifying baz.el, I will
> literally be unable to find the revision I’m interested in. (No,
> making a note of the commit timestamp and bisecting the other commit
> list for that will not work.  In Git, chronological order is not
> guaranteed within a branch.)

So you could go to "/home/albinus/src/emacs@@/ef7a18a071", as said
somewhere else. You will see all files which have been changed by this
commit.

> (Because Emacs is all about custom and idiosyncratic workflows[1],
> here’s mine:
>
> * I never use find-file interactively except to create a new file or
> jump to a directory on a remote server (via Tramp).
> * I navigate from a file to its containing directory or from a
> directory to its parent using dired-jump, and from a directory to a
> file using dired-find-file.

I haven't played with this, but it might be possible to support this
workflow. And yes, such revisioned file names shall work also remotely,
for Tramp files.

> [1]: https://xkcd.com/1172/ )

:-)

I like this workflow there. Maybe we find a way to reenable it.

Best regards, Michael.

Re: In support of Jonas Bernoulli's Magit (was: comparing code on different branches)

[Filipe Silva]

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

​I support this, could not agree more.

On Wed, Jul 5, 2017 at 12:29 PM, John Yates <john@yates-sheets.org> wrote:

> On Tue, Jul 4, 2017 at 7:05 PM, Richard Stallman <rms@gnu.org> wrote:
>
>> I wish someone would write a package comparable to Magit that
>> we could get legal papers for and include it in Emacs.
>>
>
> ​Richard,
>
> I cannot let this go without commenting.  Do you understand what
> you are advocating?
>
> In Jonas you have someone who is doing just about everything
> right per your notion of software freedom including applying gpl v3.
> He has made significant personal sacrifices to provide emacs with
> a package that is unique among editors and IDEs.  It could emerge
> as one of those oh-so-elusive creatures: a true killer app for the
> emacs platform.
>
> Jonas has and continues to deliver a steady stream of features,
> bug fixes and refinements.  Magit is clearly a work of love that is
> wonderfully supported.  Jonas has exhibited admirable project
> leadership skill and has published a detailed, credible map to
> the future:
>
>   https://github.com/magit/magit/projects/1
>
> Some of us care enough about developers like Jonas and the
> value he is delivering to emacs that we have responded to his
> plea for financial support via PayPal, Patreon or Bountysource.
>
> Were Jonas' effort invested in a non-GNU project, or at least not
> one so dear to you heart as emacs, I suspect that you would
> applaud his work.
>
> Instead you seem to advocate undercutting Jonas' efforts with
> no good reason to believe that you would get a replacement of
> anywhere near the same quality.  Further, were you actually to
> mount such a competing effort I am confident that long before it
> ever delivered any useful amount of functionality you, the emacs
> community, and the gnu effort would harvest significant bad press.
>
> Sometimes community might be more important than copyright
> assignment.  Please reconsider you request.
>
> /john
>
>

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