Hello,

Currently I have a script which finalises changelogs and then does

    dgit push-source "$@"
    git push --follow-tags --no-verify

I want to replace this with just 'git debpush'.

I think losing the --no-verify is right; there is no need for
git-debpush to ignore Git hooks just because it has made a tag (by
contrast, in the 'dgit push-source' case, the upload is already
finalised so I definitely want to push it no matter the hooks).

But the --follow-tags seems useful.  For example, for devscripts, I am
about to debpush 2.25.18, but in accordance with that package's
conventions I should also make a v2.25.18 tag.  I wouldn't like to have
to remember to push this separately.  git-debpush won't push it itself,
though, because it's a native package.

Should git-debpush perhaps have a --follow-tags option which is just
passes straight through to git-push?

Hello,

Arguments against:

- this is a very obscure case.  if for example it's a non-native package
  where there are separate vNN tags made by the uploader, it'll push
  them
- we want ordinary uploads to be optionless.

I think I'm leaning towards *not* wanting to add this option.

Sean Whitton writes ("Bug#1111230: git-debpush: git-debpush --follow-tags passthrough option?"):

So it should inherit some of its features.  (But probably not its
defaults and maybe not names, for most things, since git is usually
mad.)

control: retitle -1 git-debpush: --follow-tags passthrough option, escape hatches, policy on passthrough options
control: severity -1 normal

Hello,

After IRC discussion this is what we think we will do:

- Add an escape hatch or hatches to pass arbitrary options to git-push
  and git-tag ('git HERE tag HERE' and 'git HERE push HERE', so four
  hatches).

  + Note in docs that passing options to git-tag is especially
    dangerous.

  + Possibly also escape hatches for git-fetch.
    We're not a wrapper for git-fetch in the same sense that we are for
    git-tag and git-push, though.

- Add --follow-tags as a passthrough option, passed through to git-push.

- Document (in script header) and adopt policy that we generally highly
  reticent to adopt new passthrough options, but will consider them if
  they'll improve UX significantly for a broad enough group of users, as
  opposed to requiring people to use the escape hatches.
  These are some things that must be considered each time:

  + If it's a passthrough option for one of git-tag or git-push,
    consider whether there is already or might be in the future a
    same-named option for the other command.  E.g. we've already a -u
    passthrough option to git-tag but there is also a useful -u option
    to git-push.  We don't want to do that again.

  + Whether the name might be confusing in the context of tag2upload
    (see below for an example).

  + Whether the option is likely to cause chaos in this context.
    E.g. we're unlikely to add --tags.

  + Take into account the design principle that regular uploads
    shouldn't require passing any options.  If this is an option someone
    might always want to pass (contexts of scripting excepted), see if
    we can find some other way to meet the use case.

    (For --follow-tags if someone might always want to pass it they can
    configure push.followTags in their global git config.)

- Don't add an option for git-push's --no-verify, at least not yet.
  Write it in a comment in the script why:

  + The name is not ideal and, specifically, could be confused with
    an option changing something about how we make the tag.

  + We could rename it to --no-git-pre-push-hooks or something but I
    (Sean) think many people will find that more confusing (and indeed
    offputting/annoying/too opinionated) than just having to use an
    escape hatch option in order to pass it.

  + We don't know how useful it is.  So wait for bug reports about
    really wanting it.

Sean Whitton writes ("Bug#1111230: git-debpush: git-debpush --follow-tags passthrough option?"):

Excellent summary; I agree in all respects.

Ian.

Hello,

Adding a --follow-tags passthrough option is probably blocked by [1]
because we are unlikely to want to implement a workaround for that bug
sufficient to support --follow-tags, solely so that we can have the
passthrough option.

[1]  https://gitlab.com/gitlab-org/gitlab/-/issues/558030

Hello,

I actually meant https://gitlab.com/gitlab-org/gitlab/-/issues/562101

control: retitle -1 git-debpush: no --follow-tags passthrough option, add escape hatches, document policy on passthrough options

Hello,

Webhooks are subject to a configured limit for the number of tags.
If the push contains more than that number, no webhook is sent at all.
We have asked the salsa admins to raise the limit to 10.[2]

It seems likely that --follow-tags could mean that more than 10 tags get
pushed, in which case the debpush would fail.  So we should

- document in our policy that --follow-tags is like --tags in that it is
  liable to cause problems with tag2upload so isn't a passthrough option

- pass -cpush.followTags=false to git-push to prevent the user's config
  from breaking a push

- add a "BUGS" section to git-debpush(1) explaining the situation and
  noting that one can use the escape hatch to pass --follow-tags which
  will override the -cpush.followTags=false.

[2]  https://salsa.debian.org/salsa/support/-/issues/498