Dear all, Am Fr., 26. Apr. 2019 um 10:43 Uhr schrieb Mathieu Bridon <boche...@daitauha.fr>: > > 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<tab> > > 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/<lang>.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
