threads / discuss / 45719

Draft of Git Rev News edition 26

Subject: Draft of Git Rev News edition 26

## tl;dr

3 messages between Apr 17, 2017 and Apr 19, 2017.

replies: 2people: 2as markdown or json

Christian Couder· Apr 17, 2017, 14:33 UTC · lore

Hi,

A draft of a new Git Rev News edition is available here:

  https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-26.md

Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub issue:

  https://github.com/git/git.github.io/issues/238

You can also reply to this email.

In general all kinds of contribution, for example proofreading, suggestions for articles or links, help on the issues in GitHub, and so on, are very much appreciated.

I tried to cc everyone who appears in this edition, but maybe I missed some people, sorry about that.

Thomas, Jakub, Markus and myself plan to publish this edition on Wednesday April 19th.

Thanks, Christian.

Michael J Gruber· Apr 19, 2017, 07:49 UTC · re: Christian Couder · lore

Re: Draft of Git Rev News edition 26

Christian Couder venit, vidit, dixit 17.04.2017 16:33:

Show 26 quoted lines

> Hi,
> 
> A draft of a new Git Rev News edition is available here:
> 
>   https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-26.md
> 
> Everyone is welcome to contribute in any section either by editing the
> above page on GitHub and sending a pull request, or by commenting on
> this GitHub issue:
> 
>   https://github.com/git/git.github.io/issues/238
> 
> You can also reply to this email.
> 
> In general all kinds of contribution, for example proofreading,
> suggestions for articles or links, help on the issues in GitHub, and
> so on, are very much appreciated.
> 
> I tried to cc everyone who appears in this edition, but maybe I missed
> some people, sorry about that.
> 
> Thomas, Jakub, Markus and myself plan to publish this edition on
> Wednesday April 19th.
> 
> Thanks,
> Christian.

Hi Christian,

Thanks for the ping on the draft.

Re gpg: Maybe some valuable point of information is what Werner Koch himself said in that thread: "That [the command line is not a stable API to GnuPG] is not true. The command line interface has been stable for the last 19 years. We only removed a left over PGP-2 backward compatibility in 2.1 (-kvv). I doubt that this has even been noticed."

I think our conclusion was that on Git's side, there is no problem to solve (except, maybe, to use gpg2 by default when gpg is not installed) because the main problem is mixed installations of gpg1 and gpg2.1+, and we don't want to use a library instead of the command line API for the reasons mentioned by Linus and others.

Michael

Christian Couder· Apr 19, 2017, 12:31 UTC · re: Michael J Gruber · lore

Re: Draft of Git Rev News edition 26

Hi Michael,

> Hi Christian,
>
> Thanks for the ping on the draft.

Thanks for you input on this!

Show 6 quoted lines

> Re gpg: Maybe some valuable point of information is what Werner Koch
> himself said in that thread:
> "That [the command line is not a stable API to GnuPG] is not true.  The
> command line interface has been stable for the
> last 19 years.  We only removed a left over PGP-2 backward compatibility
> in 2.1 (-kvv).  I doubt that this has even been noticed."

Yeah, I could add the above, but there is already the following in the article (which is already quite long):

------------------ Bernhard then replied to each of the points Linus had raised. About "library versioning" his reply was:

> In my experience Werner (the lead GnuPG developers) is quite reasonable about
> keeping APIs stable (he often goes out of his way to keep even the command
> line version stable, maybe he shouldn't do that to the command line options
> so you are more motivated to go to this official API gpgme. >:) )

------------------

So I think Bernhard already knew and had already written that the command line API is basically stable thanks to Werner's efforts.

Show 5 quoted lines

> I think our conclusion was that on Git's side, there is no problem to
> solve (except, maybe, to use gpg2 by default when gpg is not installed)
> because the main problem is mixed installations of gpg1 and gpg2.1+, and
> we don't want to use a library instead of the command line API for the
> reasons mentioned by Linus and others.

I agree that one conclusion is that maybe we should use gpg2 by default when gpg is not installed or when both gpg and gpg2 are installed. But I think another important conclusion on the Git side is Peff's email, which basically says that gpg.program cannot be removed and "gpg.program = gpgme" could be added. But I prefer not to state these conclusions explicitly in the article as people might disagree :-)