Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Typically someone using this setting would want to set > NO_CROSS_DIRECTORY_HARDLINKS, too, but that is not enforced, so you > can make $(bindir)/git and $(gitexecdir)/git into hardlinks to the > same inode and still make sure your tarball avoids the btrfs limits if > you want. > > Requested-by: Bastian Blank <waldi@xxxxxxxxxx> > Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > --- > Hi, > > See <http://bugs.debian.org/642603> for context. Sane? > > Makefile | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/Makefile b/Makefile > index 9afdcf2a..ab64ff4c 100644 > --- a/Makefile > +++ b/Makefile > @@ -226,6 +226,10 @@ all:: > # Define NO_CROSS_DIRECTORY_HARDLINKS if you plan to distribute the installed > # programs as a tar, where bin/ and libexec/ might be on different file systems. > # > +# Define NO_HARDLINKS if you plan to distribute the installed programs as a tar > +# that might be extracted on a filesystem like btrfs that does not cope well > +# with many links to one inode in one directory. > +# Hmm.... I would understand if the change were to eventually remove these "git-foo" anywhere from the filesystem perhaps after a large version bump in Git 2.0, but that is not what you are trying to do. Wouldn't your use case be better served with $ tar zcf dist.tar.gz --hard-dereference $list_of_files_to_tar_up instead? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html