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 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
