Re: elpa.git and `new-master`

Re: elpa.git and `new-master`

[Boruch Baum]

On Tue, 15 Dec 2020 16:35:44 -0500, Stefan Monnier wrote:
> > On Tue, 15 Dec 2020 10:57:25 -0800, Stephen Leake wrote:
> >>   As a result, I decided to create a fresh `new-master` branch which
> >>   doesn't share its history with `master`.  This new branch will replace
> >>   `master` in the coming days.
> > In keeping with the Black Lives Matter movement, can we name this branch
> > "main" instead of "master"?

+1. Also, I discourage names of the form 'new-*' because it begs some
future eventuality requiring some 'new-new-*' or 'newer-*' or
'newest-*'or 'really-honestly-the-newest-*'.

> Only if you can tell me how to arrange elpa.git such that `git clone
> https://.../elpa.git` gives you the `main` branch instead of the
> `master` branch.

You don't need to perform any arranging; the operation acts on the
currently active upstream branch (see 'git help clone' first paragraph):

  mkdir -p clone-test/{1,2}
  cd clone-test/1
  git init
  touch a
  git add a
  git -am "add a"
  git status
  git branch main
  git switch main
  git status
  cd ../2
  git clone ../1
  cd 1
  git status

The example creates a new branch 'main' but you could just as well just
rename the master branch to main:

  git branch -m master main

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-12-16 09:48]:
> The example creates a new branch 'main' but you could just as well just
> rename the master branch to main:
> 
>   git branch -m master main

There is no need to remain the branch just because some users will not
understand that one word may have several different meanings. One does
not change the world and reality to accommodate lack of understanding
of subset of people. We need rich meanings and rich understandings,
not less rich meanings and less understandings.

Person complaining assumed that "master" comes from etymology related
to slavery, but it is not. So far I know Italian for me etymology
comes from maestro, like somebody being very skillful. It is nothing
related to slavery in regards to etymology.

Word has different meanings and "master" on a git is nothing related
to slavery.

Definiton of "main" as noun does not even fit to git branch.

Definition of main as adjective is also synonym to some definitions of
"master".

It is politics that does not inspect itself, it does not research the
definitions of words.

* Overview of noun master

The noun master has 10 senses (first 6 from tagged texts)
1. (8) maestro, master -- (an artist of consummate skill; "a master of the violin"; "one of the old masters")
2. (5) overlord, master, lord -- (a person who has general authority over others)
3. (1) victor, master, superior -- (a combatant who is able to defeat rivals)
4. (1) master -- (directs the work of others)
5. (1) headmaster, schoolmaster, master -- (presiding officer of a school)
6. (1) master, master copy, original -- (an original creation (i.e., an audio recording) from which copies can be made)
7. master, captain, sea captain, skipper -- (an officer who is licensed to command a merchant ship)
8. master -- (someone who holds a master's degree from academic institution)
9. master, professional -- (an authority qualified to teach apprentices)
10. passkey, passe-partout, master key, master -- (key that secures entrance everywhere)


* Overview of adj main

The adj main has 3 senses (first 1 from tagged texts)
1. (33) chief, main, primary, principal, master -- (most important element; "the chief aim of living"; "the main doors were of solid glass"; "the principal rivers of America"; "the principal example"; "policemen were primary targets"; "the master bedroom"; "a master switch")
2. independent, main -- ((of a clause) capable of standing syntactically alone as a complete sentence; "the main (or independent) clause in a complex sentence has at least a subject and a verb")
3. main -- (of force; of the greatest possible intensity; "by main strength")

Re: elpa.git and `new-master`

[Andreas Schwab]

On Dez 16 2020, Jean Louis wrote:

> Definiton of "main" as noun does not even fit to git branch.

It's the most important branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: elpa.git and `new-master`

[Jean Louis]

* Andreas Schwab <schwab@linux-m68k.org> [2020-12-16 11:24]:
> On Dez 16 2020, Jean Louis wrote:
> 
> > Definiton of "main" as noun does not even fit to git branch.
> 
> It's the most important branch.

"master" is original as in the "master copy".

Branches should be those deriving from master.

main as noun does not fit there, but as adjective it would fit.

Would you say "main-branch" or "main-copy" it would make more sense
with main as adjective. Not as noun.

Master as noun fits well:

6. (1) master, master copy, original -- (an original creation (i.e.,
an audio recording) from which copies can be made)

Re: elpa.git and `new-master`

[Andreas Schwab]

On Dez 16 2020, Jean Louis wrote:

> Master as noun fits well:

For the repository, yes, but not for branches.  Each has unique
contents, so they are not copies of each other.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: elpa.git and `new-master`

[Pankaj Jangid]

Jean Louis <bugs@gnu.support> writes:

> * Overview of noun master
>
> The noun master has 10 senses (first 6 from tagged texts)
> 1. (8) maestro, master -- (an artist of consummate skill; "a master of the violin"; "one of the old masters")
> 2. (5) overlord, master, lord -- (a person who has general authority over others)
> 3. (1) victor, master, superior -- (a combatant who is able to defeat rivals)
> 4. (1) master -- (directs the work of others)
> 5. (1) headmaster, schoolmaster, master -- (presiding officer of a school)
> 6. (1) master, master copy, original -- (an original creation (i.e., an audio recording) from which copies can be made)
> 7. master, captain, sea captain, skipper -- (an officer who is licensed to command a merchant ship)
> 8. master -- (someone who holds a master's degree from academic institution)
> 9. master, professional -- (an authority qualified to teach apprentices)
> 10. passkey, passe-partout, master key, master -- (key that secures entrance everywhere)

>
> * Overview of adj main
>
> The adj main has 3 senses (first 1 from tagged texts)
> 1. (33) chief, main, primary, principal, master -- (most important
> element; "the chief aim of living"; "the main doors were of solid
> glass"; "the principal rivers of America"; "the principal example";
> "policemen were primary targets"; "the master bedroom"; "a master
> switch")
> 2. independent, main -- ((of a clause) capable of standing
> syntactically alone as a complete sentence; "the main (or independent)
> clause in a complex sentence has at least a subject and a verb")
> 3. main -- (of force; of the greatest possible intensity; "by main strength")

I come from India. And the word is assimilated into Hindi vocabulary as
well. Master => Teacher, and in some contexts “master” also means an
expert.

Re: elpa.git and `new-master`

[Jean Louis]

* Pankaj Jangid <pankaj@codeisgreat.org> [2020-12-16 11:50]:
> I come from India. And the word is assimilated into Hindi vocabulary as
> well. Master => Teacher, and in some contexts “master” also means an
> expert.

That is right and that is also for me this way as coming from Europe.

It is good to look into etymology or where the word comes from:

https://en.wiktionary.org/wiki/master#Etymology_1

From Middle English maister, mayster, meister, from Old English
mǣster, mæġster, mæġester, mæġister, magister (“master”), from Latin
magister (“chief, teacher, leader”), from Old Latin magester, from
Proto-Indo-European *méǵh₂s, (as in magnus (“great”)) + -ester/-ister
(compare minister (“servant”)). Reinforced by Old French maistre,
mestre from the same Latin source. Compare also Saterland Frisian
Mäster (“master”), West Frisian master (“master”), Dutch meester
(“master”), German Meister (“master”). Doublet of maestro and
magister.

Re: elpa.git and `new-master`

[Alfred M. Szmidt]

Since this has nothing to do with Emacs proper, can we please move the
discussion to gnu-misc-discuss@ or emacs-tangets@?

Re: elpa.git and `new-master`

[Joost Kremers]

On Wed, Dec 16 2020, Jean Louis wrote:
> * Boruch Baum <boruch_baum@gmx.com> [2020-12-16 09:48]:
>> The example creates a new branch 'main' but you could just as well just
>> rename the master branch to main:
>> 
>>   git branch -m master main
>
> There is no need to remain the branch just because some users will not
> understand that one word may have several different meanings. One does
> not change the world and reality to accommodate lack of understanding
> of subset of people. We need rich meanings and rich understandings,
> not less rich meanings and less understandings.

The problem is that words not only have meanings but also connotations. And
whether you like it or not, the word 'master' evokes the word 'slave' and
everything associated with it. Perhaps the effect is stronger in English than in
other languages, I don't know. The effect is probably stronger in computer
contexts because of the ubiquity of so-called "master-slave" architectures. And
the effect is likely stronger for some people than for others. But the effect exists.

So please do not assume that people who advocate switching to the term "main" do
not understand that words have different meanings. The point is that words can
evoke sentiments even in contexts where their intended meaning wouldn't give
rise to those sentiments.

Whether that warrants changing the term "master branch" to "main branch" is
certainly worth discussing, but the discussion cannot be decided on the
basis of the dictionary meaning of "master", nor on its etymology. The
discussion should centre around the question whether the benefits outweigh the
costs.

The costs in this case are, AFAIU, fairly low. Renaming a branch in Git, or
creating a new branch, is easy and Git itself doesn't ascribe any special meaning
to the branch name "master". At most it would be a one-time inconvenience for
people regularly pulling from the main repo. (As far as I understand. I'm really
not a Git expert.)

I cannot comment on the benefits. I do not know how offensive the term "master"
in Git is to those whose ancestors were enslaved and who themselves suffer from the
effects of racism in society. We should not, however, preempt the discussion by
pointing to the dictionary meaning of the word "master", implying that those who
feel offended by the term have no reason to feel that way.


-- 
Joost Kremers
Life has its moments

Re: elpa.git and `new-master`

[Jean Louis]

* Joost Kremers <joostkremers@fastmail.fm> [2020-12-16 16:33]:
> 
> On Wed, Dec 16 2020, Jean Louis wrote:
> > * Boruch Baum <boruch_baum@gmx.com> [2020-12-16 09:48]:
> >> The example creates a new branch 'main' but you could just as well just
> >> rename the master branch to main:
> >> 
> >>   git branch -m master main
> >
> > There is no need to remain the branch just because some users will not
> > understand that one word may have several different meanings. One does
> > not change the world and reality to accommodate lack of understanding
> > of subset of people. We need rich meanings and rich understandings,
> > not less rich meanings and less understandings.
> 
> The problem is that words not only have meanings but also connotations. And
> whether you like it or not, the word 'master' evokes the word 'slave' and
> everything associated with it. Perhaps the effect is stronger in English than in
> other languages, I don't know. The effect is probably stronger in computer
> contexts because of the ubiquity of so-called "master-slave" architectures. And
> the effect is likely stronger for some people than for others. But
> the effect exists.

When I read master I just get the meaning of master copy. That is what
I say, some people will get various other meanings and those meanings
are clarified when person knows what is it really and in which
definition the word has been used.

git branch named "master" is not connected to any "slave" that I know
neither in computing terminology neither in real world.

> So please do not assume that people who advocate switching to the term "main" do
> not understand that words have different meanings. The point is that words can
> evoke sentiments even in contexts where their intended meaning wouldn't give
> rise to those sentiments.

It is alright to me to start renaming the git branches from master to
anything you wish. 

Maybe is best to publish that on GNU pages to say what is political
stance regarding it. As if we do not publish it ourselves, it will
most probably be promoted and published directly or indirectly by
those who proposed that change in the first place.

So either way, the integrity is lost for the sake of new social
justice warriors.

Jean

Re: elpa.git and `new-master`

[Stefan Monnier]

> The problem is that words not only have meanings but also connotations. And
> whether you like it or not, the word 'master' evokes the word 'slave' and
> everything associated with it.

While I agree that in the context of CS protocols, "master" evokes
"slave", in my day-to-day life "master" evokes instead the notion of
someone skilled in an art with no connotation of any kind of
slave counterpart (any counterpart would be called student instead).


        Stefan

Re: elpa.git and `new-master`

[Stephen Leake]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Wed, Dec 16 2020, Jean Louis wrote:
>> * Boruch Baum <boruch_baum@gmx.com> [2020-12-16 09:48]:
>>> The example creates a new branch 'main' but you could just as well just
>>> rename the master branch to main:
>>> 
>>>   git branch -m master main
>>
>> There is no need to remain the branch just because some users will not
>> understand that one word may have several different meanings. One does
>> not change the world and reality to accommodate lack of understanding
>> of subset of people. We need rich meanings and rich understandings,
>> not less rich meanings and less understandings.
>
> The problem is that words not only have meanings but also connotations. And
> whether you like it or not, the word 'master' evokes the word 'slave' and
> everything associated with it. Perhaps the effect is stronger in English than in
> other languages, I don't know. 

The effect is stronger in the United States (where I live),
unfortunately; I made the suggestion with a strong US bias. But Gnu
Emacs is a global project, so I withdraw the suggestion.

> The effect is probably stronger in computer contexts because of the
> ubiquity of so-called "master-slave" architectures. And the effect is
> likely stronger for some people than for others. But the effect
> exists.

Yes, this is what I was trying to acknowledge.

> So please do not assume that people who advocate switching to the term "main" do
> not understand that words have different meanings. The point is that words can
> evoke sentiments even in contexts where their intended meaning wouldn't give
> rise to those sentiments.
>
> Whether that warrants changing the term "master branch" to "main branch" is
> certainly worth discussing, but the discussion cannot be decided on the
> basis of the dictionary meaning of "master", nor on its etymology. The
> discussion should centre around the question whether the benefits outweigh the
> costs.

+1.

> The costs in this case are, AFAIU, fairly low. Renaming a branch in Git, or
> creating a new branch, is easy and Git itself doesn't ascribe any special meaning
> to the branch name "master". 

The default clone branch is "master", or was in earlier git versions.
Which is why Stefan asked how to make the default clone work when
"master" is not correct. There was a solution posted, but I have not
tested it.

> At most it would be a one-time inconvenience for people regularly
> pulling from the main repo. (As far as I understand. I'm really not a
> Git expert.)

No, it affects novices cloning emacs.git for the first time. Something
that should not require Googling for an error message like "branch
master does not exist" :(. I have gotten similar messages when I tried
to use a repository with no branch named "master".

> I cannot comment on the benefits. I do not know how offensive the term "master"
> in Git is to those whose ancestors were enslaved and who themselves suffer from the
> effects of racism in society. We should not, however, preempt the discussion by
> pointing to the dictionary meaning of the word "master", implying that those who
> feel offended by the term have no reason to feel that way.

I have heard rumors of free software projects making this change, but I
have not had direct discussions with anyone who might feel offended by
"master" (I am not such a person).

-- 
-- Stephe

Re: elpa.git and `new-master`

[Tim Landscheidt]

Joost Kremers <joostkremers@fastmail.fm> wrote:

> […]

> The costs in this case are, AFAIU, fairly low. Renaming a branch in Git, or
> creating a new branch, is easy and Git itself doesn't ascribe any special meaning
> to the branch name "master". At most it would be a one-time inconvenience for
> people regularly pulling from the main repo. (As far as I understand. I'm really
> not a Git expert.)

> I cannot comment on the benefits. I do not know how offensive the term "master"
> in Git is to those whose ancestors were enslaved and who themselves suffer from the
> effects of racism in society. We should not, however, preempt the discussion by
> pointing to the dictionary meaning of the word "master", implying that those who
> feel offended by the term have no reason to feel that way.

In that context it is probably worth noting that the GNU
Coding Standards /require/ the use of the English language,
one (of several) that achieved its ubiquity not necessarily
always in a laudable way.  But it is unimaginable to find
any communication method that noone has a reason to feel of-
fended about.

So the costs are not fairly low; such a renaming shows that:

a) the offense (allegedly) felt by one group has more weight
   than others' pain, and that

b) someone still using the word "master" to name a Git
   branch does something objectionable, and that

b) loud, concerted campaigns are likely to succeed, encour-
   aging others to focus on such a strategy as well.

Tim

Re: elpa.git and `new-master`

[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 problem is that words not only have meanings but also connotations. And
  > whether you like it or not, the word 'master' evokes the word 'slave' and
  > everything associated with it.

If you mean that as a general statement, I think it is incorrect.
It appears to be true for some people, that they will think of
that spurious association, but I think most programmers will not.

Everyone has particular associations, which will usually be spurious
to the issue at hand.  That's part of being human.  For some people,
'master' in git evokes "slavery".  For some people, the number 13
evokes "unlucky".  For many people, the number 4 evokes "death".

In our work, those associations are usually spurious.  Version 13 will
not actually be unlucky, version 4 will not actually be deadly, and
the 'master' branch of a program will not be associated with actual
oppression (if the program is free).  But there will be people who
press us to avoid 13, 4 and 'master' just so they will not be reminded
of the associations.

We have to respond that that is not our problem.  We do not undertake
to declare a word taboo because it would evoke unpleasant thoughts in
your mind.  Being reminded of unpleasant memories is unavoidable in
life, and you must not pressure people to contort themselves to spare
you some of those reminders.

We must not agree to treat words that might evoke bad things as if
they _were_ the bad things.

As for the question of what to call the trunk of the repo for
NonGNU ELPA, I don't have an opinion about that.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: elpa.git and `new-master`

[Joost Kremers]

[Followup-To: set to emacs-tangents]

On Thu, Dec 17 2020, Richard Stallman wrote:
> We must not agree to treat words that might evoke bad things as if
> they _were_ the bad things.

While I agree in principle, I do think this should be considered on a
case-by-case basis. There are words that are obnoxious enough to be avoided.

-- 
Joost Kremers
Life has its moments

Re: elpa.git and `new-master`

[Stephen Leake]

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 problem is that words not only have meanings but also connotations. And
>   > whether you like it or not, the word 'master' evokes the word 'slave' and
>   > everything associated with it.
>
> If you mean that as a general statement, I think it is incorrect.
> It appears to be true for some people, that they will think of
> that spurious association, but I think most programmers will not.

Only because currently most programmers are not decendents of former
slaves, or are not aware of these issues. But that is part of the
problem - it would benefit many projects to have programming teams that
are more diverse, and more aware of diversity issues. 

> Everyone has particular associations, which will usually be spurious
> to the issue at hand.  That's part of being human.  For some people,
> 'master' in git evokes "slavery".  For some people, the number 13
> evokes "unlucky".  For many people, the number 4 evokes "death".

Clearly, some of these are more significant than others; they affect
more people, or affect them more strongly. It is difficult to judge.

> We have to respond that that is not our problem.  

I disagree. Those of us who have benefited from previous slavery owe a
debt to the people who are still suffering the consequences.

> We do not undertake to declare a word taboo because it would evoke
> unpleasant thoughts in your mind. Being reminded of unpleasant
> memories is unavoidable in life, and you must not pressure people to
> contort themselves to spare you some of those reminders.
>
> We must not agree to treat words that might evoke bad things as if
> they _were_ the bad things.

There are taboo words in all societies. Usually they are not chosen by a
concious process; they are just inherited from the past. Here we have a
chance to decide what should be taboo. A relevant example is "the
N-word", which used to be in common use, but is now taboo.

-- 
-- Stephe

Re: elpa.git and `new-master`

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

Putting a word off-limits to people is a denial of freedom.

Making words taboo is objectionable even when it is done in the name
of a worthy cause.  Even racist insult words should not be taboo --
for instance, studying bigotry and opposing bigotry sometimes require
quoting them.  See
https://www.theatlantic.com/ideas/archive/2019/08/whites-refer-to-the-n-word/596872/.

However, that topic is a tangent here, so let's not go further down it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: elpa.git and `new-master`

[Clément Pit-Claudel]

On 12/16/20 2:38 AM, Jean Louis wrote:
> Word has different meanings and "master" on a git is nothing related
> to slavery.

https://english.stackexchange.com/questions/474419/does-the-term-master-in-git-the-vc-system-refer-to-slavery

Re: elpa.git and `new-master`

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> The example creates a new branch 'main' but you could just as well just
> rename the master branch to main:
>
>   git branch -m master main

Since we're (for some Stefan-like values of "we") doing a rare reorg of
a source repo, and everybody will have to re-pull the ELPA repo anyway,
I'm all for taking this unique opportunity to call the main branch in
ELPA "main".

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

Re: elpa.git and `new-master`

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> The example creates a new branch 'main' but you could just as well just
>> rename the master branch to main:
>>
>>   git branch -m master main
>
> Since we're (for some Stefan-like values of "we") doing a rare reorg of
> a source repo, and everybody will have to re-pull the ELPA repo anyway,
> I'm all for taking this unique opportunity to call the main branch in
> ELPA "main".

We can probably rename new-master to main. That way there will be no
non-fast-foward issues.

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 15:49, Pankaj Jangid wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Boruch Baum <boruch_baum@gmx.com> writes:
> >
> >> The example creates a new branch 'main' but you could just as well just
> >> rename the master branch to main:
> >>
> >>   git branch -m master main
> >
> > Since we're (for some Stefan-like values of "we") doing a rare reorg of
> > a source repo, and everybody will have to re-pull the ELPA repo anyway,
> > I'm all for taking this unique opportunity to call the main branch in
> > ELPA "main".
>
> We can probably rename new-master to main. That way there will be no
> non-fast-foward issues.

It may also help avoid any future confusion to rename the current 'master'
branch to indicate that it has been obsolesced, maybe something like
'master-obsolete-2020-12-16' or, to place it lexical-y closer to 'main'
in listings of branches, rename it to main-obsolete-2020-12-16' - that
would also be helpful for emacs users 200 years from now who can be
expected not to know anything about 'master' branches.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Gregory Heytings via Emacs development discussions.]

>> The example creates a new branch 'main' but you could just as well just 
>> rename the master branch to main:
>>
>>   git branch -m master main
>
> Since we're (for some Stefan-like values of "we") doing a rare reorg of 
> a source repo, and everybody will have to re-pull the ELPA repo anyway, 
> I'm all for taking this unique opportunity to call the main branch in 
> ELPA "main".
>

Could we not adopt "trunk" again, instead of "master" or "main"?

Re: elpa.git and `new-master`

[Lars Ingebrigtsen]

Gregory Heytings <ghe@sdf.org> writes:

> Could we not adopt "trunk" again, instead of "master" or "main"?

"trunk" would definitely be my preference, but it seems like the git
world is settling on "main", and adhering to convention makes things
less confusing, perhaps?

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

Re: elpa.git and `new-master`

[Gregory Heytings via Emacs development discussions.]

>> Could we not adopt "trunk" again, instead of "master" or "main"?
>
> "trunk" would definitely be my preference, but it seems like the git 
> world is settling on "main", and adhering to convention makes things 
> less confusing, perhaps?
>

Who said Emacs should adhere to conventions ;-)

There are now two votes for "trunk".  Who else?

Re: elpa.git and `new-master`

[Pankaj Jangid]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>>> Could we not adopt "trunk" again, instead of "master" or "main"?
>>
>> "trunk" would definitely be my preference, but it seems like the git
>> world is settling on "main", and adhering to convention makes things
>> less confusing, perhaps?
>>
>
> Who said Emacs should adhere to conventions ;-)
>
> There are now two votes for "trunk".  Who else?

I prefer trunk. 

Re: elpa.git and `new-master`

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-12-16 17:44]:
> 
> > > Could we not adopt "trunk" again, instead of "master" or "main"?
> > 
> > "trunk" would definitely be my preference, but it seems like the git
> > world is settling on "main", and adhering to convention makes things
> > less confusing, perhaps?
> > 
> 
> Who said Emacs should adhere to conventions ;-)
> 
> There are now two votes for "trunk".  Who else?

That reminds me of dead body without head and neck, I am offended. ;-)

Re: elpa.git and `new-master`

[Alfred M. Szmidt]

   There are now two votes for "trunk".  Who else?

This isn't some kind of popularity contest, and this topic is wholy
unrelated to Emacs.  The convention that we use in the GNU project and
on Savannah is to call the master branch for master.

Moving the old master to master-YYY-MM-DD and then renaming new-master
to master seems like a sensible thing, those who have elpa already
checkedout will just get a non-fast-forwrd checkout.  And history is
preserved -- if it is of interest.

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 16 Dec 2020 14:53:47 +0100
> Cc: emacs-devel@gnu.org
> 
> Gregory Heytings <ghe@sdf.org> writes:
> 
> > Could we not adopt "trunk" again, instead of "master" or "main"?
> 
> "trunk" would definitely be my preference, but it seems like the git
> world is settling on "main"

There can be no meaningful "trunk" in Git, since it doesn't really
support the "mainline" notion, that's why it isn't used too much in
the Git world.  We gave up on trying to maintain a mainline in our Git
repository long ago.

(Of course, that doesn't prevent us from calling a branch "trunk" --
or anything else, really.)

Re: elpa.git and `new-master`

[Dmitry Gutov]

On 16.12.2020 11:03, Lars Ingebrigtsen wrote:
> I'm all for taking this unique opportunity to call the main branch in
> ELPA "main".

+1

And while I agree with the sentiment that it's pretty meaningless and 
"virtue signaling", we don't have to have the pointless argument about 
it. Just signal the virtue and move one.

Re: elpa.git and `new-master`

[Stefan Monnier]

>> I'm all for taking this unique opportunity to call the main branch in
>> ELPA "main".
> +1
> And while I agree with the sentiment that it's pretty meaningless and
> "virtue signaling", we don't have to have the pointless argument about
> it. Just signal the virtue and move one.

I don't have a strong opinion on the specific color of this bikeshed
("master" is convenient because it's less work to implement, "trunk" is
what I got used to back in Bzr days and what I thus keep using locally,
but "main" is more meaningful (and "virtue signaling")).

My original plan was to rename `new-master` to `master`, but I'd be
happy to rename it to `main` instead.  My earlier question remains,
tho: how do I arrange for

    git clone git://git.sv.gnu.org/emacs/elpa.git

to put the user into that `main` branch rather than into `master`?


        Stefan

Re: elpa.git and `new-master`

[Dmitry Gutov]

On 16.12.2020 20:24, Stefan Monnier wrote:
> My original plan was to rename `new-master` to `master`, but I'd be
> happy to rename it to `main` instead.  My earlier question remains,
> tho: how do I arrange for
> 
>      git clone git://git.sv.gnu.org/emacs/elpa.git
> 
> to put the user into that `main` branch rather than into `master`?

I think it's a server-side setting.

E.g. 'git clone https://github.com/mdn/content.git mdn-conent' will 
create a local repository with the 'main' branch current.

Either Savannah has a project settings for that, or we'll need to 
contact the admins.

Also see: 'git symbolic-ref refs/remotes/origin/HEAD'

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 20:46, Dmitry Gutov wrote:
> On 16.12.2020 20:24, Stefan Monnier wrote:
> >  My earlier question remains, tho: how do I arrange for
> >
> >      git clone git://git.sv.gnu.org/emacs/elpa.git
> >
> > to put the user into that `main` branch rather than into `master`?

Was my answer to your question here[1] incorrect?

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00855.html

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Stefan Monnier]

>> >  My earlier question remains, tho: how do I arrange for
>> >
>> >      git clone git://git.sv.gnu.org/emacs/elpa.git
>> >
>> > to put the user into that `main` branch rather than into `master`?
>
> Was my answer to your question here[1] incorrect?
>
> [1] https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00855.html

That answer only changes *your* local clone, AFAICT,
whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.


        Stefan

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 14:06, Stefan Monnier wrote:
> >> >  My earlier question remains, tho: how do I arrange for
> >> >
> >> >      git clone git://git.sv.gnu.org/emacs/elpa.git
> >> >
> >> > to put the user into that `main` branch rather than into `master`?
> >
> > Was my answer to your question here[1] incorrect?
> >
> > [1] https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00855.html
>
> That answer only changes *your* local clone, AFAICT,
> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.

Did you try it? Log into the (remote) server, switch to some existing secondary
branch (or use checkout), then on your local machine perform the clone
and then note the output of 'git status'.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Stefan Monnier]

> Did you try it? Log into the (remote) server,

That's the problem: I can't log onto the remote server.


        Stefan

Re: elpa.git and `new-master`

[Andreas Schwab]

On Dez 16 2020, Stefan Monnier wrote:

> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.

You need to change what HEAD points to on the server.

http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: elpa.git and `new-master`

[Stefan Monnier]

>> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.
> You need to change what HEAD points to on the server.
> http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD

I know, and that's what I'm asking how to do.


        Stefan

Re: elpa.git and `new-master`

[Andreas Schwab]

On Dez 16 2020, Stefan Monnier wrote:

>>> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.
>> You need to change what HEAD points to on the server.
>> http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD
>
> I know, and that's what I'm asking how to do.

That requires direct access to the repository on the server.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 14:55, Stefan Monnier wrote:
> That's the problem: I can't log onto the remote server.

On 2020-12-16 14:56, Stefan Monnier wrote:
> >> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.
> > You need to change what HEAD points to on the server.
> > http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD
>
> I know, and that's what I'm asking how to do.

I'm still missing something. At this point it seems that you're asking
us how you can get console access to GNU's own savannah server, but that
can't be right because the obvious answer is "ask the admin" or "ask the
admin to perform the operation".

--
hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

>> >> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.
>> > You need to change what HEAD points to on the server.
>> > http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD
>>
>> I know, and that's what I'm asking how to do.
>
> I'm still missing something.

Apparently.  I think what Stefan was asking (it was certainly what I
wondered) was "is there an in-git way of doing this?"  And it seems like
the answer is definitely "no"?

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

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 21:19, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> >> >> whereas we need to change git://git.sv.gnu.org/emacs/elpa.git itself.
> >> > You need to change what HEAD points to on the server.
> >> > http://git.savannah.gnu.org/git/emacs/elpa.git/HEAD
> >>
> >> I know, and that's what I'm asking how to do.
> >
> > I'm still missing something.
>
> Apparently.  I think what Stefan was asking (it was certainly what I
> wondered) was "is there an in-git way of doing this?"  And it seems like
> the answer is definitely "no"?

If by "in-git" you mean using the "git push" command from a remote, I
believe you are correct. However, if by "in-git" you mean "using only git
commands without manually editing .git/HEAD", then just once you do log
in to savannah just perform:
 'git switch <branch-you-want-as-the-default>'.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: elpa.git and `new-master`

[Stefan Monnier]

> If by "in-git" you mean using the "git push" command from a remote, I
> believe you are correct. However, if by "in-git" you mean "using only git
> commands without manually editing .git/HEAD", then just once you do log
> in to savannah just perform:
>  'git switch <branch-you-want-as-the-default>'.

The "once you do log in to savannah" is not "in-git".
I can't log into git.sv.gnu.org any more than other people can log into,
say, `gitlab.com`: the SSH access is limited to running the server part
of Git.


        Stefan

Re: elpa.git and `new-master`

[Stefan Monnier]

>> I know, and that's what I'm asking how to do.
> I'm still missing something. At this point it seems that you're asking
> us how you can get console access to GNU's own savannah server, but that

What you're missing is that I'm only now learning that you can't do
it remotely.  I have searched a fair bit how to do it and hadn't come to
a clear answer "you can't do that".

And to be honest, I still haven't seen any first hand documentation
that it can't be done remotely.  The best I could find is experience
reports where have failed to do it.
The most convincing so far seems to be:

    https://stackoverflow.com/questions/37456048/github-remote-symbolic-ref-branch-alias


-- Stefan

Re: elpa.git and `new-master`

[Stefan Monnier]

>> My original plan was to rename `new-master` to `master`, but I'd be
>> happy to rename it to `main` instead.  My earlier question remains,
>> tho: how do I arrange for
>>      git clone git://git.sv.gnu.org/emacs/elpa.git
>> to put the user into that `main` branch rather than into `master`?
>
> I think it's a server-side setting.
>
> E.g. 'git clone https://github.com/mdn/content.git mdn-conent' will create
> a local repository with the 'main' branch current.
>
> Either Savannah has a project settings for that, or we'll need to contact
> the admins.
>
> Also see: 'git symbolic-ref refs/remotes/origin/HEAD'

OK, I renamed `new-master` to `main`.
Will have to ask for a sysadmin to do the server-side dance, now.

But before I do that: if we want to do this for `elpa.git`, why not do it
for `nongnu.git`, and for `emacs.git` as well?


        Stefan

Re: elpa.git and `new-master`

[Dmitry Gutov]

On 16.12.2020 22:46, Stefan Monnier wrote:
> OK, I renamed `new-master` to `main`.
> Will have to ask for a sysadmin to do the server-side dance, now.

Thanks!

> But before I do that: if we want to do this for `elpa.git`, why not do it
> for `nongnu.git`, and for `emacs.git` as well?

nongnu.git seems a non-brainer, but emacs.git might create some tension 
in existing contributors.

But it shouldn't be too much of a problem if we do a big announcement, 
and then make sure to merge any subsequent pushes to 'master' (from 
whoever missed the memo) to the new 'main'.

Re: elpa.git and `new-master`

[Lars Ingebrigtsen]

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

> But before I do that: if we want to do this for `elpa.git`, why not do it
> for `nongnu.git`, and for `emacs.git` as well?

That would be my preference, but I assumed that it would be kinda
disruptive.  If other people working on Emacs think they can adjust
without too much drama, then I'm for it.

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

Re: elpa.git and `new-master`

[Stefan Monnier]

>> But before I do that: if we want to do this for `elpa.git`, why not do it
>> for `nongnu.git`, and for `emacs.git` as well?
> That would be my preference, but I assumed that it would be kinda
> disruptive.  If other people working on Emacs think they can adjust
> without too much drama, then I'm for it.

The thing about moving emacs.git from `master` to `main` is that I don't
think there's a way to prepare for that.  So if we ever want to change,
then we may as well change now.


        Stefan

Re: elpa.git and `new-master`

[Caio Henrique]

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

> But before I do that: if we want to do this for `elpa.git`, why not do it
> for `nongnu.git`, and for `emacs.git` as well?
>
>
>         Stefan

FWIW changing elpa.git or nongnu.git wouldn't make a difference for me,
but changing emacs.git will break the scripts that I use to build
Emacs.

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 16 Dec 2020 15:46:49 -0500
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Boruch Baum <boruch_baum@gmx.com>,
>  Emacs-Devel List <emacs-devel@gnu.org>
> 
> OK, I renamed `new-master` to `main`.
> Will have to ask for a sysadmin to do the server-side dance, now.
> 
> But before I do that: if we want to do this for `elpa.git`, why not do it
> for `nongnu.git`, and for `emacs.git` as well?

Not for emacs.git, please.  Let's leave that at 'master'.

Re: elpa.git and `new-master`

[Joost Kremers]

On Thu, Dec 17 2020, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 16 Dec 2020 15:46:49 -0500
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Boruch Baum <boruch_baum@gmx.com>,
>>  Emacs-Devel List <emacs-devel@gnu.org>
>> 
>> OK, I renamed `new-master` to `main`.
>> Will have to ask for a sysadmin to do the server-side dance, now.
>> 
>> But before I do that: if we want to do this for `elpa.git`, why not do it
>> for `nongnu.git`, and for `emacs.git` as well?
>
> Not for emacs.git, please.  Let's leave that at 'master'.

If you keep 'master' in one repo, it should probably be kept
in all Emacs-related repos. It's less confusing that way.

-- 
Joost Kremers
Life has its moments

Re: elpa.git and `new-master`

[Tim Cross]

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

On Thu, 17 Dec 2020 at 19:18, Joost Kremers <joostkremers@fastmail.fm>
wrote:

>
> On Thu, Dec 17 2020, Eli Zaretskii wrote:
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date: Wed, 16 Dec 2020 15:46:49 -0500
> >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Boruch Baum <
> boruch_baum@gmx.com>,
> >>  Emacs-Devel List <emacs-devel@gnu.org>
> >>
> >> OK, I renamed `new-master` to `main`.
> >> Will have to ask for a sysadmin to do the server-side dance, now.
> >>
> >> But before I do that: if we want to do this for `elpa.git`, why not do
> it
> >> for `nongnu.git`, and for `emacs.git` as well?
> >
> > Not for emacs.git, please.  Let's leave that at 'master'.
>
> If you keep 'master' in one repo, it should probably be kept
> in all Emacs-related repos. It's less confusing that way.
>
> I agree. Things are far less confusing if they are consistent.

I also feel that people have focused on how easy it is to make this change
technically, but have ignored the change management repercussions. In
addition to communicating the change, it is also important to consider what
documentation, howtos, tutorials etc that will need to be updated. Thie
importance is increased by the fact that regardless of personal position,
calling the trunk or initial repository master is the common and expected
practice for many users. It is also the default for many tools.

This is not a vote for or against, simply highlighting the point it is the
technical ease of making the change is not the same as the impact of the
change. As many on this list tend to have a strong technology bias, it is
easy to overlook the impact of such changes and how they impact on uses who
have less of a technical focus. We can expect to see an increase in
messages from people who are confused becauwse the information they found
on forums like stack overflow etc no longer works.
-- 
regards,

Tim

--
Tim Cross

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

Re: elpa.git and `new-master`

[Stefan Monnier]

>> But before I do that: if we want to do this for `elpa.git`, why not do it
>> for `nongnu.git`, and for `emacs.git` as well?
> Not for emacs.git, please.  Let's leave that at 'master'.

OK,


        Stefan

Re: elpa.git and `new-master`

[Juri Linkov]

> I don't have a strong opinion on the specific color of this bikeshed
> ("master" is convenient because it's less work to implement, "trunk" is
> what I got used to back in Bzr days and what I thus keep using locally,
> but "main" is more meaningful (and "virtue signaling")).
>
> My original plan was to rename `new-master` to `master`, but I'd be
> happy to rename it to `main` instead.

For the sake of completion, either `master` or `main` is fine, but
please don't add both branches with the same prefix.  For example,
I use completion on branch names all the time, and it's very convenient
to quickly type just `o TAB m TAB` or `o/m TAB` to complete the
`origin/master` branch.  Having two branches with the same prefix `ma-`
would be a hassle.

Re: elpa.git and `new-master`

[Boruch Baum]

On 2020-12-16 22:41, Juri Linkov wrote:
> > I don't have a strong opinion on the specific color of this bikeshed
> > ("master" is convenient because it's less work to implement, "trunk" is
> > what I got used to back in Bzr days and what I thus keep using locally,
> > but "main" is more meaningful (and "virtue signaling")).
> >
> > My original plan was to rename `new-master` to `master`, but I'd be
> > happy to rename it to `main` instead.
>
> For the sake of completion, either `master` or `main` is fine, but
> please don't add both branches with the same prefix.  For example,
> I use completion on branch names all the time, and it's very convenient
> to quickly type just `o TAB m TAB` or `o/m TAB` to complete the
> `origin/master` branch.  Having two branches with the same prefix `ma-`
> would be a hassle.

Good point. How about using an underscore to prefix the
obsolesced branch? I don't want to suggest a dash prefix because that
can always down the line confuse shell scripts.

Example: _main-obsolete-YYYY-MM-DD

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

elpa.git and `new-master`

[Stefan Monnier]

As part of the effort to setup the NonGNU ELPA infrastructure, I've also
overhauled the GNU ELPA part.

Part of the result is that now all packages are kept on separate
branches (no more "subtree"s).  As a result, the `master` branch has
shrunk significantly..  Especially since even the deployment script
themsevles have moved to a separate branch (`elpa-admin`) so as to be
able to share them between elpa.git and nongnu.git (it also comes with
the side effect that this FSF-copyrighted code is kept in `elpa.git`
rather than `nongnu.git`).

Here are some immediate news linked to this:

- I have now changed elpa.gnu.org to use the new code to build the
  tarballs of GNU ELPA.  Please be on the lookup for any regressions.

- The old `master` branch has shrunk to almost nothing, yet it still
  carries in its history all the code it used to have.  This is not
  a big issue since that code is still around.  More importantly, the
  `master` history includes some entries which Git nowadays considers
  "not quite valid" (resulting in bugs#22690 and bug#25376).
  As a result, I decided to create a fresh `new-master` branch which
  doesn't share its history with `master`.  This new branch will replace
  `master` in the coming days.  So whoever is tracking `master` will be
  faced with a "non-fast-forward" update.
  This can be annoying and I apologize in advance, but I think the
  long terms advantages largely make up for the short term annoyance.

- On the positive side, the new code has some interesting features:
  - It knows how to build Info files from Texinfo files, so we won't need
    to store the generated Info files any more.
  - It also know how to generate Info files from Org manuals.
  - It can even run `make` as part of building the tarballs, making it
    possible to perform various massaging.
    This obviously can't just run "anything you like" since it depends
    on what's available on `elpa.gnu.org`, so if you want to use this
    feature, please get in touch with me so we can coordinate it.
  There is an embryo of documentation of those new features in the
  `README` file in the `elpa-admin` branch.
  This should hopefully make it possible to build a Tramp tarball
  directly from the code in Emacs, or similarly for AUCTeX avoid the
  need to store generated files in Git.
  The `Org` package is an example that uses some of those new features
  to build the tarballs directly from an unadulterated copy of the
  upstream branch.

- Another advantage is that the new code makes it much easier to build
  your own tarballs, for example to test them before pushing to code.
  You can just do `make build/[PKGNAME]` and the resulting package will
  be built in `archive/[PKGNAME]-[VERSION].tar.

- A subtle but important change affects the exact code placed in the
  tarballs.  The old code detected the need to make a new release
  tarball by watching for changes in the `Version:` header and whenever
  it saw a new value, it built the tarball from the HEAD revision.
  The new code detects the need in the same way but will not just use
  the HEAD revision: it will use the specific revision that modified the
  `Version:` header.  This means you can push a commit that bumps the
  `Version:` together with a bunch of subsequent commits that introduce
  wild bleeding edge changes without fearing that the release will
  actually be made from the bleeding edge code.  It also means that if
  you see a remaining bug after you've bumped the `Version:`, there's no
  point quickly pushing a subsequent fix unless you also re-bump the
  `Version:` header.


        Stefan

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 14 Dec 2020 23:46:17 -0500
> 
> - The old `master` branch has shrunk to almost nothing, yet it still
>   carries in its history all the code it used to have.  This is not
>   a big issue since that code is still around.  More importantly, the
>   `master` history includes some entries which Git nowadays considers
>   "not quite valid" (resulting in bugs#22690 and bug#25376).
>   As a result, I decided to create a fresh `new-master` branch which
>   doesn't share its history with `master`.  This new branch will replace
>   `master` in the coming days.  So whoever is tracking `master` will be
>   faced with a "non-fast-forward" update.
>   This can be annoying and I apologize in advance, but I think the
>   long terms advantages largely make up for the short term annoyance.
> 
> - On the positive side, the new code has some interesting features:
>   - It knows how to build Info files from Texinfo files, so we won't need
>     to store the generated Info files any more.
>   - It also know how to generate Info files from Org manuals.
>   - It can even run `make` as part of building the tarballs, making it
>     possible to perform various massaging.
>     This obviously can't just run "anything you like" since it depends
>     on what's available on `elpa.gnu.org`, so if you want to use this
>     feature, please get in touch with me so we can coordinate it.

Can you explain what does this mean in practice for those who, like
me, just maintain the Git repository without installing the packages
via package.el?  Whenever I need to use some package, mainly for
testing or debugging, I simply invoke that package from its place in
the Git repository.  The fact that I needed to invoke "make" for
getting the "external" packages was an annoyance, but it was a
relatively rare case.  Now it sounds like it will be much more
frequent?  Or am I confused?

IOW, what would I need to do, under this "new master", to get a
package in my local clone of the ELPA's Git repository?

TIA

Re: elpa.git and `new-master`

[Stefan Monnier]

> Can you explain what does this mean in practice for those who, like
> me, just maintain the Git repository without installing the packages
> via package.el?

Could you clarify what you mean by "maintain the Git repository"?
An example would probably work best.

> IOW, what would I need to do, under this "new master", to get a
> package in my local clone of the ELPA's Git repository?

A normal clone of the elpa.git repository will include all the packages,
as before, none of them in `master` or `new-master`, tho: all of them in
externals/[PKGNAME] branches.

    make packages/[PKGNAME]

will bring a specific package into its `packages/[PKGNAME]` subdirectory
(by way of `git worktree`).


        Stefan

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 11:53:19 -0500
> 
> > Can you explain what does this mean in practice for those who, like
> > me, just maintain the Git repository without installing the packages
> > via package.el?
> 
> Could you clarify what you mean by "maintain the Git repository"?

It's just the result of cloning the ELPA repository.  I'm not really
sure what kind of example is needed.

> A normal clone of the elpa.git repository will include all the packages,
> as before, none of them in `master` or `new-master`, tho: all of them in
> externals/[PKGNAME] branches.
> 
>     make packages/[PKGNAME]
> 
> will bring a specific package into its `packages/[PKGNAME]` subdirectory
> (by way of `git worktree`).

So I will have to use 'make' to get every single package?  That's
inconvenient.

Re: elpa.git and `new-master`

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 15 Dec 2020 11:53:19 -0500
>> 
>> > Can you explain what does this mean in practice for those who, like
>> > me, just maintain the Git repository without installing the packages
>> > via package.el?
>> 
>> Could you clarify what you mean by "maintain the Git repository"?
>
> It's just the result of cloning the ELPA repository.  I'm not really
> sure what kind of example is needed.
>
>> A normal clone of the elpa.git repository will include all the packages,
>> as before, none of them in `master` or `new-master`, tho: all of them in
>> externals/[PKGNAME] branches.
>> 
>>     make packages/[PKGNAME]
>> 
>> will bring a specific package into its `packages/[PKGNAME]` subdirectory
>> (by way of `git worktree`).
>
> So I will have to use 'make' to get every single package?  That's
> inconvenient.

There should be a 'make all' to handle this case.


-- 
-- Stephe

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 11:02:42 -0800
> 
> > So I will have to use 'make' to get every single package?  That's
> > inconvenient.
> 
> There should be a 'make all' to handle this case.

There is (or was).  But I never want to use it, since it was never
necessary to have every single external package on my disk -- as long
as they were the minority.  Now, I guess I will have to do that, sigh.

Re: elpa.git and `new-master`

[Dmitry Gutov]

On 15.12.2020 20:24, Eli Zaretskii wrote:
>> A normal clone of the elpa.git repository will include all the packages,
>> as before, none of them in `master` or `new-master`, tho: all of them in
>> externals/[PKGNAME] branches.
>>
>>      make packages/[PKGNAME]
>>
>> will bring a specific package into its `packages/[PKGNAME]` subdirectory
>> (by way of `git worktree`).
> So I will have to use 'make' to get every single package?  That's
> inconvenient.
> 

Or you could 'git checkout externals/<package-name>' to switch to the 
branch containing the package.

Not sure which one is more convenient, but the latter might be faster.

Re: elpa.git and `new-master`

[Stefan Monnier]

>> > Can you explain what does this mean in practice for those who, like
>> > me, just maintain the Git repository without installing the packages
>> > via package.el?
>> Could you clarify what you mean by "maintain the Git repository"?
> It's just the result of cloning the ELPA repository.

Cloning is a pretty small part of "maintaining" and is usually useless
on its own.  So give an example of what you want to do.  It would start
with

    git clone .../elpa.git

presumably, but the interesting part is what you want to do after that.

>> A normal clone of the elpa.git repository will include all the packages,
>> as before, none of them in `master` or `new-master`, tho: all of them in
>> externals/[PKGNAME] branches.
>> 
>>     make packages/[PKGNAME]
>> 
>> will bring a specific package into its `packages/[PKGNAME]` subdirectory
>> (by way of `git worktree`).
>
> So I will have to use 'make' to get every single package?

No: `make externals` works as before to populate `packages` with all the
packages, if that's what you're after.  In that case, nothing has
changed from before, mostly (except that if you want to commit changes
to a particular package, you have to do so from the
`packages/[PKGNAME]` subdirectory).


        Stefan

Re: elpa.git and `new-master`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 16:33:14 -0500
> 
> >> Could you clarify what you mean by "maintain the Git repository"?
> > It's just the result of cloning the ELPA repository.
> 
> Cloning is a pretty small part of "maintaining" and is usually useless
> on its own.  So give an example of what you want to do.  It would start
> with
> 
>     git clone .../elpa.git
> 
> presumably, but the interesting part is what you want to do after that.

  emacs -Q
  M-: (add-to-list 'load-path ".../elpa/packages/FOO") RET
  M-x load-library FOO RET
  <use package FOO>

> >> A normal clone of the elpa.git repository will include all the packages,
> >> as before, none of them in `master` or `new-master`, tho: all of them in
> >> externals/[PKGNAME] branches.
> >> 
> >>     make packages/[PKGNAME]
> >> 
> >> will bring a specific package into its `packages/[PKGNAME]` subdirectory
> >> (by way of `git worktree`).
> >
> > So I will have to use 'make' to get every single package?
> 
> No: `make externals` works as before to populate `packages` with all the
> packages, if that's what you're after.  In that case, nothing has
> changed from before, mostly (except that if you want to commit changes
> to a particular package, you have to do so from the
> `packages/[PKGNAME]` subdirectory).

Maybe I'm confused, but my understanding was that more packages will
now need to be treated as "externals".

Re: elpa.git and `new-master`

[Stephen Leake]

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

>   As a result, I decided to create a fresh `new-master` branch which
>   doesn't share its history with `master`.  This new branch will replace
>   `master` in the coming days.  

In keeping with the Black Lives Matter movement, can we name this branch
"main" instead of "master"?


-- 
-- Stephe

Re: elpa.git and `new-master`

[Stefan Monnier]

>>   As a result, I decided to create a fresh `new-master` branch which
>>   doesn't share its history with `master`.  This new branch will replace
>>   `master` in the coming days.  
> In keeping with the Black Lives Matter movement, can we name this branch
> "main" instead of "master"?

Only if you can tell me how to arrange elpa.git such that `git clone
https://.../elpa.git` gives you the `main` branch instead of the
`master` branch.


        Stefan

Re: elpa.git and `new-master`

[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 keeping with the Black Lives Matter movement, can we name this branch
  > "main" instead of "master"?

The GNU Project sees nothing objectionable in the name "master", and
likewise for the name "main".

The GNU Project supports basic human rights in computing, so it
opposes slavery in computing.  However, naming a branch "master" is
not slavery.  The only thing in computing that is partially like
slavery is the injustice of nonfree software and online dis-services.

See the node Other Politics in Information for Maintainers of GNU
Software.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: elpa.git and `new-master`

[Tim Cross]

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

On Wed, 16 Dec 2020 at 05:58, Stephen Leake <stephen_leake@stephe-leake.org>
wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >   As a result, I decided to create a fresh `new-master` branch which
> >   doesn't share its history with `master`.  This new branch will replace
> >   `master` in the coming days.
>
> In keeping with the Black Lives Matter movement, can we name this branch
> "main" instead of "master"?
>
> IMO this is misguided political correctness which is likely to create
unnecessary friction with little benefit for the movement. If anything,
runs the risk of creating a distraction which undermines the real and
important issues highlighted by the black lives matter movement.

-- 
regards,

Tim

--
Tim Cross

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

Re: elpa.git and `new-master`

[Richard Stallman]

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

  > If anything,
  > runs the risk of creating a distraction which undermines the real and
  > important issues highlighted by the black lives matter movement.

I agree, but that's getting outside the topic of this list.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: elpa.git and `new-master`

[Alfred M. Szmidt]

While other movements might be just causes, the GNU project has a
specific and narrow mission (Emacs even more so) which should not
stray from that goal, so the only movement we keep with is the one of
the free software movement.  See (maintain) Other Politics .

Re: elpa.git and `new-master`

[Stephen Leake]

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

> As part of the effort to setup the NonGNU ELPA infrastructure, I've also
> overhauled the GNU ELPA part.

Thanks for all your work on ELPA; it is a very nice feature of Emacs.


-- 
-- Stephe

Re: elpa.git and `new-master`

[Jonas Bernoulli]

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

> As part of the effort to setup the NonGNU ELPA infrastructure, I've also
> overhauled the GNU ELPA part.

Thanks a lot for your work on this!

>   As a result, I decided to create a fresh `new-master` branch which
>   doesn't share its history with `master`.  This new branch will replace
>   `master` in the coming days.

Since you have to do this for this branch anyway, please also force-push
to 'externals/transient' in order to discard the last few commits, which
were only needed because the `:renames' property did not exist yet.  Now
that that is available, I plan to use transient's "master" branch and do
the edits using `:renames' et al.

>   So whoever is tracking `master` will be faced with a
>   "non-fast-forward" update.  This can be annoying and I apologize in
>   advance, but I think the long terms advantages largely make up for
>   the short term annoyance.

I noticed that non-fast-forward pushes are disallowed (when trying to
do the reset I just mentioned myself) and ended up wondering if there
are any other checks in place that prevent other potential push errors.

Most importantly what happens if someone has managed to merge the old
"master" into the new one and then pushes that?  That is a fast-forward,
though one that we very much want to prevent.  Is there some list with
disallowed hashes?

>   - It also know how to generate Info files from Org manuals.
>   - It can even run `make` as part of building the tarballs, making it
>     possible to perform various massaging.
>     This obviously can't just run "anything you like" since it depends
>     on what's available on `elpa.gnu.org`, so if you want to use this
>     feature, please get in touch with me so we can coordinate it.

I had some issues with this.  Some of them are due to my packages
needing some additional libraries to generate the *.texi files from the
*.org input and I will contact you about that privately.  But there was
also one issue that might affect others:

`org-texinfo-export-to-texinfo' may end up calling git (e.g. to get the
version number), which requires access to the git (control) directory
"ELPA/.git" (just "ELPA/.git/worktrees/<package>" probably won't do),
but currently bubblewrap is not given access to that.

> - Another advantage is that the new code makes it much easier to build
>   your own tarballs, for example to test them before pushing to code.
>   You can just do `make build/[PKGNAME]` and the resulting package will
>   be built in `archive/[PKGNAME]-[VERSION].tar.

That almost worked. "make build/<package>" (or `elpaa--make-one-package')
calls `elpaa--external-package-sync', which pulls.  That of course is not
desirable when one wants to test some other revision of the package than
what would end up being pulled.

     Jonas

Re: elpa.git and `new-master`

[Stefan Monnier]

[ I task-switched to something else, so this will have to wait a bit,
  but in the mean time: ]

> I noticed that non-fast-forward pushes are disallowed (when trying to
> do the reset I just mentioned myself) and ended up wondering if there
> are any other checks in place that prevent other potential push errors.

Indeed.  You can still delete a branch, so you can non-fast-forward by
deleting and then pushing something else.  We discourage doing it, tho,
so please don't abuse it.

> Most importantly what happens if someone has managed to merge the old
> "master" into the new one and then pushes that?  That is a fast-forward,
> though one that we very much want to prevent.

Yes, that'd be a problem.  But no, there's no protection against that.

> Is there some list with disallowed hashes?

No.

> `org-texinfo-export-to-texinfo' may end up calling git (e.g. to get the
> version number), which requires access to the git (control) directory
> "ELPA/.git" (just "ELPA/.git/worktrees/<package>" probably won't do),
> but currently bubblewrap is not given access to that.

> That almost worked. "make build/<package>" (or `elpaa--make-one-package')
> calls `elpaa--external-package-sync', which pulls.  That of course is not
> desirable when one wants to test some other revision of the package than
> what would end up being pulled.

Could you make bug reports for those (and put me in the X-Debbugs-Cc) so
I don't forget?


        Stefan