Raphael Hertzog writes ("Re: Bug#722546: dgit should not pass -i\.git -I.git to
dpkg-source"):
> On Thu, 12 Sep 2013, Ian Jackson wrote:
> > Raphaël Hertzog writes ("Bug#722546: dgit should not pass -i\.git -I.git to
> > dpkg-source"):
> > > This might be helpful with "1.0" source format that did not ignore those
> > > files by default but it's actively bad for newer formats (including
> > > "3.0 (native)") where using those options actually restrict the set of
> > > ignored files (.git is already ignored by default)
> >
> > This is deliberate. In particular, for example, .gitignore should not
> > be ignored if it exists.
>
> Given that the command line overrides what the maintainer has set in
> debian/source/options, you also un-ignore files that the maintainer
> said to ignore... for example some generated files that tend to stay
> around (that might be, or not, in git).
I'm not sure where you're going with this. These dpkg-source ignores
are things which are ignored by dpkg-source when constructing the
source package. So they shouldn't be in the git tree either. If they
are there, then the git tree is not suitable. If they are generated
files, then they should be removed by debian/rules clean and would
therefore not end up in the source package even if they were not
ignored.
An NMUer, who probably doesn't want to shave any clean target yaks, is
probably well-advised to use git clean (via dgit --clean=git) and git
reset rather than relying on perhaps-broken rules targets. The only
reason --clean=git is not the default is that it can be unfortunate if
the user forgot `git add'.
> > dgit's operating principle is that the git tree object corresponding
> > to the git commit corresponds _exactly_ to the results of unpacking
> > the source package.
>
> This just means that when you detect a difference you should fallback
> to do exactly the same as you do when you import a source package from the
> archive, no?
When we detect a difference during dgit build, you mean ? No, because
dgit build, and push, is an output operation. You're supposed to
already have a git commit containing the correct tree.
> > Therefore the only difference should be .git, which exists in working
> > trees but not tree objects.
>
> And what is supposed to happen when you want to mixin the upstream git
> repository which has for example a directory that is excluded from the
> generated tarball that is used in the debian package?
You need to represent that change (the removal of the directory) in
git.
> The debian maintainer might well have added some ignore rule so that
> dpkg-source doesn't try to add the entire directory as a new patch.
The principle behind dgit is that you don't have to worry about any of
this. The git tree provided and used by dgit is exactly correct.
If you are an NMUer, you don't need to care and just need to make sure
that your commits on top of the dgit suite branch (whether they are
merges or not) contain the correct contents. Specifically, in the
context of ignores, they must not reintroduce any material not
intended for the source package.
If you are the maintainer and want to use dgit, you can use whatever
gitish technique you like to construct a tree which is suitable.
dpkg-source ignore options are not a gitish technique, do not affect
the git tree, and therefore are not suitable. So if you are the
maintainer and want to use dgit you should probably not set any
dpkg-source ignore options.
A key point here is this:
Only dgit's users need to conform to dgit's model - and they need to
conform only to it, and don't need to know anything about
dpkg-source's model. It's a tool for people who want a pure gitish
workflow, using tools from the git world.
I think the current behaviour serves those users well. Your implied
proposed change would serve those users less well.
> you're a bit hasty in closing bugs...
I felt that this bug report was unlikely to result in me wanting to
change the code in dgit. I'm happy to talk about it further in case
I'm wrong and you can change my mind. But in the meantime I don't
want reports of this kind clogging up my bug list. Sorry if that's
annoying.
With other bugs, where I feel that the report /is/ likely to result in
me wanting to change the code, or at least warrants further
investigation, I will obviously leave the bug open (or even comment to
the effect that it looks like a real bug).
Ian.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
