Discussion:
Bug#930930: dgit: suggestion to use -wga/-wgfa could also suggest using -wn --include-dirty
(too old to reply)
Sean Whitton
2019-06-22 17:40:02 UTC
Permalink
Package: dgit
Version: 8.3
Severity: minor

Hello,

Since 8.3 dgit will error out if there are untracked files, and make the
following suggestion:

dgit: error: tree contains uncommited, untracked, unignored files
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.

... to which a user might reasonably respond "but I want to keep them!"

dgit could say instead:

dgit: error: tree contains uncommited, untracked, unignored files
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them,
dgit: or --clean=none --include-dirty to include them in the build.

This might cause the user to run into the error message reported in
#914317, so I wonder whether dgit should only do this in the case that
there are no untracked files under d/patches or the source format isn't
3.0 (quilt)? Or maybe it should just refer to the docs for
--include-dirty, assuming you like my patch in #930922?

A third possibility is recommending that the user stage the files and
then just --include-dirty should be sufficient.
--
Sean Whitton
Ian Jackson
2019-07-01 12:40:02 UTC
Permalink
Post by Sean Whitton
A third possibility is recommending that the user stage the files and
then just --include-dirty should be sufficient.
--include-dirty has lots of problems (not compatible with many quilt
modes, awkwardnesses with clean handling, etc.) and I don't think we
should be suggesting it if they user doesn't think of it. Certainly
we shouldn't recommend using it without reading the docs.

Is the idea of committing them not obvious enough ?

If not, maybe
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them, you should probably git add and commit them.
?
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton
2019-07-21 12:10:02 UTC
Permalink
Hello,
Post by Ian Jackson
Post by Sean Whitton
A third possibility is recommending that the user stage the files and
then just --include-dirty should be sufficient.
--include-dirty has lots of problems (not compatible with many quilt
modes, awkwardnesses with clean handling, etc.) and I don't think we
should be suggesting it if they user doesn't think of it. Certainly
we shouldn't recommend using it without reading the docs.
Agreed.
Post by Ian Jackson
Is the idea of committing them not obvious enough ?
I'd like to add the suggestion -- it might not be obvious to someone
with a whole load of packaging stuff on the brain and not much
experience with dgit.
Post by Ian Jackson
If not, maybe
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them, you should probably git add and commit them.
?
A bit friendlier and less opinionated:

dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them in the build, it is usually simplest to just
dgit: git add and commit them.

Possibly s/simplest/easiest/.
--
Sean Whitton
Ian Jackson
2019-07-21 15:30:02 UTC
Permalink
Post by Sean Whitton
Post by Ian Jackson
Is the idea of committing them not obvious enough ?
I'd like to add the suggestion -- it might not be obvious to someone
with a whole load of packaging stuff on the brain and not much
experience with dgit.
Post by Ian Jackson
If not, maybe
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them, you should probably git add and commit them.
?
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them in the build, it is usually simplest to just
dgit: git add and commit them.
Possibly s/simplest/easiest/.
I don't mind making it friendlier but I do mind making it longer.
Excess verbiage in error messages makes it much harder to see the
point. Can you come up with a formulation that fits on one line ?

As for the adjective, I think "best" is right. It's not only simpler
and easier; it's also less risky and better supports short-timescale
archaeology.

Does that make sense ?

thanks,
Ian.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sean Whitton
2019-07-21 18:30:02 UTC
Permalink
Hello,
Post by Ian Jackson
I don't mind making it friendlier but I do mind making it longer.
Excess verbiage in error messages makes it much harder to see the
point. Can you come up with a formulation that fits on one line ?
On the other hand, if dgit's user-facing error message it longer it's a
bit easier to pick out visually from all the other output. But fair enough.
Post by Ian Jackson
As for the adjective, I think "best" is right. It's not only simpler
and easier; it's also less risky and better supports short-timescale
archaeology.
I agree.

This is surely fine (people know to git add before commit and I don't
think commit is going to make them think of dpkg-source's option):

dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them in the build, it is usually best to just commit them.
--
Sean Whitton
Ian Jackson
2019-07-21 18:50:02 UTC
Permalink
Post by Sean Whitton
This is surely fine (people know to git add before commit and I don't
dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
dgit: To include them in the build, it is usually best to just commit them.
LGTM, thanks.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Loading...