Assorted concerns about git repository

Matt McCutchen matt at mattmccutchen.net
Sat Nov 17 20:48:10 GMT 2007


Wayne,

I have a few more concerns about the git repository:

1. It looks like you retroactively removed all generated files from the
history.  This may inconvenience a user who seeks to an older version of
the source code and lacks the magic "configure" to help regenerate the
files.  You also removed "rsync.1" even from revisions before it became
a file generated from "rsync.yo"; can this possibly be intended?

2. I think it is a bad idea to have the rsync build system download
generated files from rsync://rsync.samba.org/rsyncftp/generated-files/ .
A user will get the generated files corresponding to the latest trunk no
matter what branch or point in time she has seeked to, with no warning
about the mismatch.  It would be better to offer a separate branch
containing the generated files, or if "./configure && make" really must
work on the default branch without autotools, use "*_shipped" files like
the Linux kernel source tree does.

3. It looks like you removed patches/ from the history.  I think it is
valuable to have the history of the branches from before they became
real branches.

4. Why do you recommend that people run "git-set-file-times"?  I would
like to see more explanation before I mess with my source files' mtimes.

5. How will you mark the revisions of the branches that were provided
with a particular rsync release?  (This is the "nesting" issue I
mentioned in my git slides.)  You could tag each branch at each release,
but that would result in a *lot* of tags and I think it would be cleaner
to have a single object representing the release.  One way to get that
is to make a tree object containing the commits for the trunk and all
the branches as children and then tag this tree object (echoes of
Subversion); git doesn't go out of its way to make this usage easy, but
it would work.

Matt



More information about the rsync mailing list