Using `dgit push-source`, I noticed the following warning:

```
warning: could not open directory 'debian/source/': No such file or
directory
```

as the first line. Everything continued fine from there on (except the
warning reappeared a couple of times).

I feel that is not a warning I should see as a user. A warning about "no
explicit source format definition, please consider creating
debian/source/format" or something along those lines would have been
fair game (I presume that is what this warning relates to).

The package in question was `debputy-lsp/0.2.1` though I will be fixing
the implicit format in git.

Best regards,
Niels

PS: I am pretty sure it is not from dpkg-source. A longer snippet of the
output was:

```
$ dgit push-source
warning: could not open directory 'debian/source/': No such file or
directory
canonical suite name for unstable is sid
dpkg-source: warning: no source format specified in
debian/source/format, see dpkg-source(1)
dpkg-source: warning: --include-removal is not a valid option for
Dpkg::Source::Package::V1
dpkg-source: warning: --no-preparation is not a valid option for
Dpkg::Source::Package::V1
dpkg-source: info: using source format '1.0'
```

(Note that dpkg-source correctly identifies itself and gives a clear
warning for this purpose. Additionally there is a "canonical suite name
for unstable is sid" between the first `dpkg-source` line and the
warning in question, which I also assume is coming from `dgit`).

Hi, git maintainers.  I'm afraid I have another bug for you.

Steps to reproduce

  dgit clone debputy-lsp
  cd debputy-lsp
  git checkout 9ca98dc71acbde18e6328c90d6b48eb752248af1
  git status -uall --ignored --porcelain debian/source/format debian/source/options debian/source/local-options debian/source/local-patch-header

Expected behaviour

  Successful execution, with no ouptut, as seen in earlier versions of
  git, for example 1:2.20.1-2+deb10u9.

Actual behaviour

  This message is printed to stderr:
    warning: could not open directory 'debian/source/': No such file or directory

This has been reported by a dgit user.  dgit runs that rune and
expects it not to mind about the fact that files may not exist.

Indeed, the files not existing is normal and git status doesn't
complain about nonexistence of individual files, only about the
absence of the containing directory.  It's not clear to my why git
thinks this is wrong.  (Especially given that git doesn't really even
properly track empty directories!)


Niels Thykier writes ("Bug#1078765: dgit: warning: could not open directory 'debian/source/': No such file or directory"):

I was able to reproduce this.  Passing -D makes dgit print the
commands its running.  I saw this (without my key available, so it
definitely wouldn't actually upload):

  $ dgit -D -wgfa push-source
  | git rev-parse --show-toplevel
  => `/volatile/ian/Dgit/Bugs/1078765/debputy-lsp'
  | git config -z --get-regexp --local '.*'
  | git config -z --get-regexp --local '.*'
  | git config -z --get-regexp --global '.*'
  | git config -z --get-regexp --system '.*'
  format , quilt mode linear
  | git status -uall --ignored --porcelain debian/source/format debian/source/options debian/source/local-options debian/source/local-patch-header
  warning: could not open directory 'debian/source/': No such file or directory
  => `'
  + git diff --quiet HEAD
  [...]
  dgit: error: You seem to be trying to push an old version.
  dgit: Version current in archive:       0.2.1 (in suite sid)
  dgit: Version you are trying to upload: 0.2.1

I agree.
...

Unfortunately, git frequently fails to identify itself when it prints
messages.

Ian.