(which might not be faithful to dgit's invariants)
or previous non-Dgit uploads
(which would not provide a very rich history).
+
+git represents only file executability.
+git does not represent empty directories,
+or any leaf objects other than plain files and symlinks.
+The behaviour of Debian source package formats
+on objects with unusual permissions is complicated.
+Some pathological Debian source packages will no longer build
+if empty directories are pruned
+(or if other things not reproduced by git are changed).
+Such sources cannot be worked with properly in git,
+and therefore not with dgit either.
.SH READ-ONLY DISTROS
Distros which do not maintain a set of dgit history git repositories
can still be used in a read-only mode with dgit. Currently Ubuntu
git has features which can automatically transform files
as they are being copied between the working tree
and the git history.
+The attributes can be specified in the source tree itself,
+in
+.BR .gitattributes .
See \fBgitattributes\fP(5).
These transformations are context-sensitive
the dgit git history contains the actual contents of the package.
(When dgit is manipulating a .dsc,
it does so in a private area,
-where the transforming gitattributes are defused (disabled),
+where the transforming gitattributes are defused,
to achieve this.)
-If transforming gitattributes used,
+If transforming gitattributes are used,
they can cause trouble,
because the working tree files can differ from
the git revision history
(and therefore from the source packages).
+dgit warns if it finds a .gitattributes file
+(in a package being fetched or imported),
+unless the transforming gitattributes have been defused.
-So dgit clone
+dgit clone
and dgit setup-new-tree
disable transforming gitattributes
by default,
-by creating a .git/info/attributes.
-When fetching or importing sources
-dgit warns if it finds .gitattributes file
-and the transforming gitattributes have not been defused
-(e.g. in the case of a tree not made with dgit clone).
-
+by creating a suitable .git/info/attributes.
See
.B dgit setup-new-tree
and
source format of the package. You can just make changes as you like
in git. If the package is a `3.0 (quilt)' package, the patch stack
will usually not be represented in the git history.
+.SH FILE EXECUTABILITY
+Debian source package formats
+do not always faithfully reproduce
+changes to executability.
+But dgit insists that the result of dgit clone is identical
+(as far as git can represent - see Limitations, above)
+to the result of dpkg-source -x.
+
+So files that are executable in your git tree
+must be executable in the result of dpkg-source -x
+(but often aren't).
+If a package has such troublesome files,
+they have to be non-executable in dgit-compatible git branches.
.SH FORMAT 3.0 (QUILT)
For a format `3.0 (quilt)' source package, dgit may have to make a
commit on your current branch to contain metadata used by quilt and