Re: Git Packaging Round 2: When to Salsa

[Guillem Jover <guillem@debian.org>]

Hi!

On Wed, 2019-11-06 at 12:43:58 +0000, Simon McVittie wrote:
> On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> > It does, it's specifically mentioned as a branch that will be
> > rewinded. See the “Branch management for next and pu after a feature
> > release” section.
> 
> gitworkflows(7) describes how git.git works, as an example of the workflow
> of a particular project, rather than mandating particular workflows for
> all projects:
> 
>     This document attempts to write down and motivate some of the workflow
>     elements used for git.git itself. Many ideas apply in general
>
> In git.git, next and pu are branches themselves, not prefixes for families
> of branches. This means that branches called next/foo and pu/bar cannot
> exist in git.git. The workflows and naming used to develop git, dpkg and
> (for example) GNOME are all entirely valid, but they aren't the same.

Hmm, I find this reply slightly confusing TBH. :) It's clear that git
upstream cannot mandate how other projects operate their branches (as
long as they would not do that via code). But the point here was
whether there is precedent on branch nomenclature that people might
easily understand or be aware of to have the desired rebasing+force-push
semantics. And I provided a prominent example of this, which granted,
does not use the same exact naming format, but uses the same concepts
(nomenclature and semantics). To recap we have at least:

  * git.git: workflows(7)
  * Pro Git book:
    https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project
  * linux-next.
  * dpkg: https://wiki.debian.org/Teams/Dpkg/GitUsage

I didn't include dpkg, because I assume its git usage does not really
have much of an impact. But the git man page or the git book would be
two things I assume do have quite some exposure.

I note that GNOME seems to be using “wip“ (which was one of the
other proposals on this thread), which looks clearish to me too.
<https://developer.gnome.org/programming-guidelines/stable/version-control.html.en>

Perhaps your point was that the “pu” and “next” names are not really
commonly understood depending on the communities or context, and might
be considered confusing or non-obvious? I'm clearly biased here, as
I've been using those terms for a long time, so I cannot really tell.
But having at least some prominent references, I think counts in favor.

Thanks,
Guillem