Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear all,

Am Fr., 26. Apr. 2019 um 10:43 Uhr schrieb Mathieu Bridon
:
>
> On Fri, 2019-04-26 at 10:38 +0200, Niels De Graef via desktop-devel-
> list wrote:
> > Note that you don't need to script this kind of stuff, if you use the
> > following tricks:
> >
> > # 1. This creates a symbolic link from master to mainline, which
> > solves your problem already.
> > $ git symbolic-ref refs/heads/master refs/heads/mainline

Unfortunately that is not sufficient to solve the problem.  The
problem was not how to update the default branch for one repository.
I have 250+ repositories checked out of GNOME.  Now maintainers start
renaming branches for no justified reason (moving to git was well
justified and everyone did so; moving to Gitlab likewise) so where
before it was always master, now it will be anyone's guess.  This is a
slippery slope.  Rule number one is keep it simple.

> >
> > # 2. This worfklow doesn't even need you to specify a branch if you
> > start from mainline/master
> > $ git checkout -b feature/
> > # work, work, work and commit
> > # If you no longer want to continue on this branch, you can go back
> > to the previous one with
> > $ git checkout -

So we need to change workflow for all of GNOME because one maintainer
decides that we must use a special name for one project.  That does
not sound like a good decision. The maintainers should keep in mind
that there are people whose work touches all the repositories, and
uniformity is a requirement for an efficient workflow.  If I only
needed to ever work on a single repository or a few repositories, I
would not care either.  So that is what the maintainer probably
thinks, but surprisingly, the devs don't belong to the set people whom
the change affects the most.

Typically we are interested in committing either to master, or to a
stable branch like gnome-3-32 and then also master (but now we need an
extra incantation to see the name of the branch), but for hundreds of
projects.  The appropriate branch names can often but not always be
inferred from the filename.  Often we have simultaneous changes across
large numbers of modules, like when GNOME started recommending unicode
punctuation (“” »« etc.).

>
> # 3. Tab completion works wonders:
> $ git checkout ma
>
> Mike said himself that choosing a new name starting with the same
> letters as "master" was a deliberate choice to further minimize the
> disruption.

I always use tab completion when working with git.

Both Damned-Lies and our own scripts/workflows rely on the fact that
there are certain common elements shared by the GNOME projects: Things
like everything being on GNOME's Gitlab instead of svn, consistent
naming of files and paths (po/.po, LINGUAS), and so on.  For any
particular change, we *can* deal with it, at the cost of needing to
invest more time, and making mistakes at a higher frequency because
that is what you get when things are not as simple as possible.

There are always a few repositories that don't work well, sometimes
D-L produces inconsistent filenames or something was moved to a
different Gitlab group, you need manually commit the documentation
within a certain class of project, and so on.  We can always deal with
these exceptions which are generally unintended or at least not the
product of willful deviation from the standard, but we don't /like/ to
do those things, and there is no reason why our scripts and
infrastructure should be made more complicated to satisfy everyone's
whims.

This is not even a UI change.  Years ago there was a discussion for
changing GNOME branding because the logo (a foot) is considered rude
in some cultures.  As I recall, such a change was not made.  Now we
compromise the simplicity of our infrastructure to satisfy political
standards that do not even affect users.

Please go back to master.

Best regards
Ask

>
>
> --
> Mathieu
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Niels De Graef via gnome-i18n]

On Fri, Apr 26, 2019 at 10:14 AM Ask Hjorth Larsen via
desktop-devel-list  wrote:
>
> Am Mi., 24. Apr. 2019 um 13:57 Uhr schrieb Michael Gratton :
> >
> > On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García
> >  wrote:
> > > So hardcoding the name "mainline" to the list of branches that Damned
> > > Lies' looks up resolves the problem for you... and tomorrow another
> > > maintainer decides to rename it's master branch to
> > > whatever_non_offensive_name and DL breaks again until a patch is
> > > submited... no, sorry but this is not a solution for this.
> >
> > I agree, which is why I have been working to fix it places where it's
> > hard coded.
>
> When actually working on the project, you probably type the branch
> name now and then.  This means you need to be aware of it - it is a
> piece of information which must reside within your short-term memory.
> This is not a problem if you work on one project.  It is a problem if
> you work on hundreds of projects.  Then you need to run things like
> git branch and git status, read the output, and decide what to type
> based on that.  A good workflow seeks to minimize the risk that humans
> make mistakes, and that means making things as simple as possible.
> Please do not remove this particular piece of simplicity from our
> lives.

Hi Ask,

Note that you don't need to script this kind of stuff, if you use the
following tricks:

# 1. This creates a symbolic link from master to mainline, which
solves your problem already.
$ git symbolic-ref refs/heads/master refs/heads/mainline

# 2. This worfklow doesn't even need you to specify a branch if you
start from mainline/master
$ git checkout -b feature/
# work, work, work and commit
# If you no longer want to continue on this branch, you can go back to
the previous one with
$ git checkout -

Also note that cloning Geary will immediately take you to the default
branch of the remote (so no need to specify 'mainline' or anything).

> I can also script my way out of this for most of the tasks I need to
> do.  But inconsistencies have never made life easier in computing, and
> this is an inconsistency which we could simply choose not to deal
> with.

We _could_, but if we want to (which is still Mike's decision as
maintainer of Geary), we can. Every change has its trade-offs, and
given the work Mike has put into this to make it a smooth(er)
transition, I'd say there is little inconsistency left to care about.
At least it would take less time then all the mails I (in hindsight
regrettably) read on d-d-l.

Kind regards,
Niels


> Best regards
> Ask
>
> >
> > //Mike
> >
> > --
> > ⊨ Michael Gratton, Percept Wrangler.
> > ⚙ 
> >
> >
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Am Mi., 24. Apr. 2019 um 13:57 Uhr schrieb Michael Gratton :
>
> On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García
>  wrote:
> > So hardcoding the name "mainline" to the list of branches that Damned
> > Lies' looks up resolves the problem for you... and tomorrow another
> > maintainer decides to rename it's master branch to
> > whatever_non_offensive_name and DL breaks again until a patch is
> > submited... no, sorry but this is not a solution for this.
>
> I agree, which is why I have been working to fix it places where it's
> hard coded.

When actually working on the project, you probably type the branch
name now and then.  This means you need to be aware of it - it is a
piece of information which must reside within your short-term memory.
This is not a problem if you work on one project.  It is a problem if
you work on hundreds of projects.  Then you need to run things like
git branch and git status, read the output, and decide what to type
based on that.  A good workflow seeks to minimize the risk that humans
make mistakes, and that means making things as simple as possible.
Please do not remove this particular piece of simplicity from our
lives.

I can also script my way out of this for most of the tasks I need to
do.  But inconsistencies have never made life easier in computing, and
this is an inconsistency which we could simply choose not to deal
with.

Best regards
Ask

>
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Michael Gratton]

On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García 
 wrote:
So hardcoding the name "mainline" to the list of branches that Damned 
Lies' looks up resolves the problem for you... and tomorrow another 
maintainer decides to rename it's master branch to 
whatever_non_offensive_name and DL breaks again until a patch is 
submited... no, sorry but this is not a solution for this.


I agree, which is why I have been working to fix it places where it's 
hard coded.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Daniel Mustieles García via gnome-i18n]

So hardcoding the name "mainline" to the list of branches that Damned Lies'
looks up resolves the problem for you... and tomorrow another maintainer
decides to rename it's master branch to whatever_non_offensive_name and DL
breaks again until a patch is submited... no, sorry but this is not a
solution for this.

GNOME's modules follow a standard nomenclature and it might be followed by
all GNOME's modules. If you disagree with the naming policy you should open
a thread, discuss it with the community and follow the final decission.
It'ns not right to open the door to change master branches name freely,
although Gitlab allows it (technical ability to change it doesn't give you
the right to do it).

Since this is a not only i18n-related issue I'm Ccing Release Team and
d-d-l to hear opinion from others, what I think you should have done before
appliying this change (opening an issue in Gitlab is not enough... not
every GNOME's member is subscribed to every proyect's notifications).

Really it is a big problem for you to have a branch called «master»? It's
annoying for me spending time on this instead of working on real
problems/tasks.

Regards

El mié., 24 abr. 2019 a las 13:17, Michael Gratton ()
escribió:

> Hi Daniel,
>
> On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
>  wrote:
> > Great, but having modules with no standard name for
> > master/trunk/whatever branch might break applications like Damned
> > Lies, so this rename should be reconsidered, at least until we decide
> > to rename the whole modulesed's master branch to another one.
>
> The name of the mainline branch in git cannot be assumed to be "master"
> since git allows it to be changed, and as of Git 1.8 the server sends
> and the client looks for the name of the mainline branch when the repo
> is being fetched (e.g. via a clone). Changing the name of the mainline
> branch is easy to do, and in fact our Gitlab instance lets anyone with
> appropriate privs for a project do just that from the project settings
> UI.
>
> So, Damned-Lies' current behaviour is broken because it makes the
> assumption that the mainline branch is always named "master" (after
> trying a few other hard-coded names), and so it breaks in situations
> like this. However, I submitted a workaround that adds "mainline" to
> that list, and that MR[0] has been merged. I'm not sure if it has been
> deployed, but I think it may have been about a week ago.
>
> Of course, this should be fixed properly to just ask the repo what the
> right name is, and if there's interest in fixing it properly I'll
> happily look into it and submit another MR. I've also worked with
> Andrea to fix places in the sysadmin code (git hooks, GitLab
> integration, etc) making the same assumption[1], and that's been
> working fine for weeks.
>
> Anyway, it should be fixed for Geary now, so if you're still having
> problems with this as of this time last week, please let me know so I
> can look into a fix.
>
> > What would happen if every module maintainer decides to rename it's
> > master branch? It will be a mess... I just think we should keep names
> > homogeously, don't mind if it's called master, trunk... ;-)
> >>
>
> No, everything will work fine as long as people stop writing code that
> (wrongly) assumes git's mainline branch is necessarily called "master".
> :)
>
> //Mike
>
>
> [0] -
> 
> [1] -
> 
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear Michael,

Am Mi., 24. Apr. 2019 um 13:17 Uhr schrieb Michael Gratton :
>
> Hi Daniel,
>
> On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
>  wrote:
> > Great, but having modules with no standard name for
> > master/trunk/whatever branch might break applications like Damned
> > Lies, so this rename should be reconsidered, at least until we decide
> > to rename the whole modulesed's master branch to another one.
>
> The name of the mainline branch in git cannot be assumed to be "master"
> since git allows it to be changed, and as of Git 1.8 the server sends
> and the client looks for the name of the mainline branch when the repo
> is being fetched (e.g. via a clone). Changing the name of the mainline
> branch is easy to do, and in fact our Gitlab instance lets anyone with
> appropriate privs for a project do just that from the project settings
> UI.
>
> So, Damned-Lies' current behaviour is broken because it makes the
> assumption that the mainline branch is always named "master" (after
> trying a few other hard-coded names), and so it breaks in situations
> like this. However, I submitted a workaround that adds "mainline" to
> that list, and that MR[0] has been merged. I'm not sure if it has been
> deployed, but I think it may have been about a week ago.
>
> Of course, this should be fixed properly to just ask the repo what the
> right name is, and if there's interest in fixing it properly I'll
> happily look into it and submit another MR. I've also worked with
> Andrea to fix places in the sysadmin code (git hooks, GitLab
> integration, etc) making the same assumption[1], and that's been
> working fine for weeks.
>
> Anyway, it should be fixed for Geary now, so if you're still having
> problems with this as of this time last week, please let me know so I
> can look into a fix.
>
> > What would happen if every module maintainer decides to rename it's
> > master branch? It will be a mess... I just think we should keep names
> > homogeously, don't mind if it's called master, trunk... ;-)
> >>
>
> No, everything will work fine as long as people stop writing code that
> (wrongly) assumes git's mainline branch is necessarily called "master".
> :)

Using different branch names in different GNOME projects is not a
problem for git, which is a computer program, but it is a problem for
humans who need to agree how to do their everyday work.  Spaghetti
code may also happen work and is hence totally valid (or so says the
computer), but most developers reject unreadable code because it is
makes everyday work more difficult and causes more errors to be made
by the humans who work with it.

In this case, we need to work with a lot of different repos and
branches.  There are good technical reasons to make some essential
changes like migrating from svn to git, or moving to Gitlab, but this
change does not give us any technical advantage, it only makes things
less consistent and more time consuming than before.

Best regards
Ask

>
> //Mike
>
>
> [0] -
> 
> [1] -
> 
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Michael Gratton]

Hi Daniel,

On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n 
 wrote:
Great, but having modules with no standard name for 
master/trunk/whatever branch might break applications like Damned 
Lies, so this rename should be reconsidered, at least until we decide 
to rename the whole modulesed's master branch to another one.


The name of the mainline branch in git cannot be assumed to be "master" 
since git allows it to be changed, and as of Git 1.8 the server sends 
and the client looks for the name of the mainline branch when the repo 
is being fetched (e.g. via a clone). Changing the name of the mainline 
branch is easy to do, and in fact our Gitlab instance lets anyone with 
appropriate privs for a project do just that from the project settings 
UI.


So, Damned-Lies' current behaviour is broken because it makes the 
assumption that the mainline branch is always named "master" (after 
trying a few other hard-coded names), and so it breaks in situations 
like this. However, I submitted a workaround that adds "mainline" to 
that list, and that MR[0] has been merged. I'm not sure if it has been 
deployed, but I think it may have been about a week ago.


Of course, this should be fixed properly to just ask the repo what the 
right name is, and if there's interest in fixing it properly I'll 
happily look into it and submit another MR. I've also worked with 
Andrea to fix places in the sysadmin code (git hooks, GitLab 
integration, etc) making the same assumption[1], and that's been 
working fine for weeks.


Anyway, it should be fixed for Geary now, so if you're still having 
problems with this as of this time last week, please let me know so I 
can look into a fix.


What would happen if every module maintainer decides to rename it's 
master branch? It will be a mess... I just think we should keep names 
homogeously, don't mind if it's called master, trunk... ;-)




No, everything will work fine as long as people stop writing code that 
(wrongly) assumes git's mainline branch is necessarily called "master". 
:)


//Mike


[0] - 

[1] - 



--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen via gnome-i18n]

Dear all,

Having a master branch does not imply slavery anymore than chess
master, masterpiece, jedi master, or master of science in engineering,
but not having a master branch, and particularly having inconsistent
branch names, means extra real work for real people, and particularly
those who work with branches of multiple projects.  Please do
reconsider this change.

If we must change, and if they change the default name in git, could
we at least wait some years until everything is figured out and
reaches stable OS packages?

Best regards
Ask

Am Mi., 24. Apr. 2019 um 12:01 Uhr schrieb Daniel Mustieles García via
gnome-i18n :
>
>
>
> El mié., 24 abr. 2019 a las 11:25, Carmen Bianca Bakker 
> () escribió:
>>
>> Je mer, 2019-04-24 je 10:32 +0200, Andre Klapper skribis:
>> > > , as exposed in #324), but coherence across modules should be kept.
>> >
>> > I agree that it would be good to consider renaming all master branches.
>>
>> Then mightn't it be better to bring up the topic with GNOME and/or Git
>> upstream?
>
>
> This is exactly what I meant when said "consider".
>
>>
>> Because it would be a bit of a mess if every project could
>> decide for themselves what to call their master/mainline branch. For
>> infrastructure reasons, it seems to me that it would be best if the
>> name of that branch were uniform.
>>
>> I would like that name to be something other than "master", which is a
>> bit clunky, inaccurate, and prone to cause offence, but I'd rather have
>> that than a broken infrastructure.
>
>
> I don't think "master" causes any kind of offence, but this is just a 
> question of appreciation.
>
> Of course, If we consider this topic is enough important to take into 
> account, we should open a new thread involving d-d-l and maybe other teams 
> (Releaste team, Infrastructure...). But is this thread we are just discussing 
> if Geary's maintainer should revert the change, at least until a final 
> decission has been taken.
>
> I've exposed some arguments to revert it, the main one is that Damned Lies is 
> currently broken due to this name change. You can see it in the screenshot.
> In the other hand, opening the door to change the name of the master branch 
> in every module will result in a very big mess, broken scripts, etc.
>
> Cheers
>
>>
>> With kindness,
>> Carmen
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Daniel Mustieles García via gnome-i18n]

El mié., 24 abr. 2019 a las 11:25, Carmen Bianca Bakker (<
car...@carmenbianca.eu>) escribió:

> Je mer, 2019-04-24 je 10:32 +0200, Andre Klapper skribis:
> > > , as exposed in #324), but coherence across modules should be kept.
> >
> > I agree that it would be good to consider renaming all master branches.
>
> Then mightn't it be better to bring up the topic with GNOME and/or Git
> upstream?


This is exactly what I meant when said "consider".


> Because it would be a bit of a mess if every project could
> decide for themselves what to call their master/mainline branch. For
> infrastructure reasons, it seems to me that it would be best if the
> name of that branch were uniform.
>
> I would like that name to be something other than "master", which is a
> bit clunky, inaccurate, and prone to cause offence, but I'd rather have
> that than a broken infrastructure.
>

I don't think "master" causes any kind of offence, but this is just a
question of appreciation.

Of course, If we consider this topic is enough important to take into
account, we should open a new thread involving d-d-l and maybe other teams
(Releaste team, Infrastructure...). But is this thread we are just
discussing if Geary's maintainer should revert the change, at least until a
final decission has been taken.

I've exposed some arguments to revert it, the main one is that Damned Lies
is currently broken due to this name change. You can see it in the
screenshot.
In the other hand, opening the door to change the name of the master branch
in every module will result in a very big mess, broken scripts, etc.

Cheers


> With kindness,
> Carmen
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Carmen Bianca Bakker]

Je mer, 2019-04-24 je 10:32 +0200, Andre Klapper skribis:
> > , as exposed in #324), but coherence across modules should be kept.
> 
> I agree that it would be good to consider renaming all master branches.

Then mightn't it be better to bring up the topic with GNOME and/or Git
upstream? Because it would be a bit of a mess if every project could
decide for themselves what to call their master/mainline branch. For
infrastructure reasons, it seems to me that it would be best if the
name of that branch were uniform.

I would like that name to be something other than "master", which is a
bit clunky, inaccurate, and prone to cause offence, but I'd rather have
that than a broken infrastructure.

With kindness,
Carmen



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Daniel Mustieles García via gnome-i18n]

El mié., 24 abr. 2019 a las 10:33, Andre Klapper () escribió:

> On Wed, 2019-04-24 at 08:43 +0200, Daniel Mustieles García wrote:
> > I don't know where is the advantage of this renaming
>
> That is already clearly explained in
> https://gitlab.gnome.org/GNOME/geary/issues/324


Just because "master" implies an "slave" branch? Note that I'm not the only
who disagrees with the change, so maybe the reason is not really clear

>
>
> >  (we don't belong to Linux kernel develpment
>
> And nobody ever said so, so I don't know why it's brought up.
>

Yes, it's mentioned in the issue: "...several projects like Rust, Django
and the Linux kernel..."

>
> > , as exposed in #324), but coherence across modules should be kept.
>
> I agree that it would be good to consider renaming all master branches.
>

Great, but having modules with no standard name for master/trunk/whatever
branch might break applications like Damned Lies, so this rename should be
reconsidered, at least until we decide to rename the whole modulesed's
master branch to another one.

What would happen if every module maintainer decides to rename it's master
branch? It will be a mess... I just think we should keep names homogeously,
don't mind if it's called master, trunk... ;-)

>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Andre Klapper]

On Wed, 2019-04-24 at 08:43 +0200, Daniel Mustieles García wrote:
> I don't know where is the advantage of this renaming

That is already clearly explained in
https://gitlab.gnome.org/GNOME/geary/issues/324

>  (we don't belong to Linux kernel develpment

And nobody ever said so, so I don't know why it's brought up.

> , as exposed in #324), but coherence across modules should be kept.

I agree that it would be good to consider renaming all master branches.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Heads up: Geary mainline development branch renamed to `mainline`

[Daniel Mustieles García via gnome-i18n]

Hi Michael,

As I've already commented in https://gitlab.gnome.org/GNOME/geary/issues/403,
having a "mainline" branch instead of a "master" branch is confusing for
applications like Damned Lies, breaking for example cherry-picks from other
branches to "master" branch, as it doesn't exist.

Stable branches can be named with your own nomenclature (no need to name
them gnome-x.yy) but I would encourage you to keep the "master" branch. It
is the standard name for GNOME's development branches and helps developers
and contributors to identify where to look up the last version of the
source code.

If every GNOME's module begins naming it's "master" branch to whatever the
maintainer wants, this will be a chaos... I don't know where is the
advantage of this renaming (we don't belong to Linux kernel develpment, as
exposed in #324), but coherence across modules should be kept.

Regards.

El mié., 24 abr. 2019 a las 3:46, Michael Gratton () escribió:

> Hi all,
>
> Just a quick heads-up for people who have use git directly for
> traslating Geary: As part of
> https://gitlab.gnome.org/GNOME/geary/issues/324 The `master` branch has
> been renamed to `mainline`. Same great content (and command line
> completion prefix), snazzy new name. :)
>
> So it would be worth doing a `git fetch && git checkout mainline` ASAP,
> cherry pick any pending commits you have on the master branch, then
> deleting the old branch to avoid committing more changes to it in the
> future (`git branch --delete master && git remote prune origin`).
>
> This change happened a few weeks ago, my apologies for not letting
> everyone on the list know sooner.
>
> Cheers!
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Heads up: Geary mainline development branch renamed to `mainline`

[Michael Gratton]

Hi all,

Just a quick heads-up for people who have use git directly for 
traslating Geary: As part of 
https://gitlab.gnome.org/GNOME/geary/issues/324 The `master` branch has 
been renamed to `mainline`. Same great content (and command line 
completion prefix), snazzy new name. :)


So it would be worth doing a `git fetch && git checkout mainline` ASAP, 
cherry pick any pending commits you have on the master branch, then 
deleting the old branch to avoid committing more changes to it in the 
future (`git branch --delete master && git remote prune origin`).


This change happened a few weeks ago, my apologies for not letting 
everyone on the list know sooner.


Cheers!
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n