Assorted concerns about git repository

[Wayne Davison]

On Sat, Nov 17, 2007 at 03:48:10PM -0500, Matt McCutchen wrote:
> 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.

The main purpose for the generated files being in CVS and/or git
(including the magic "configure" script) is to make the build farm work.
When a human checks out the files from git, I see no problem requiring
them to build the generated files themselves -- an initial run of the
./prepare-source script will take care of it (or manually running
autoconf and autoheader if prepare-source isn't around).  I have updated
the download page to mention this preparatory step.  Each release tar
will still include generated files, as usual.

> You also removed "rsync.1" even from revisions before it became
> a file generated from "rsync.yo"; can this possibly be intended?

That was a mistake that I am going to try to correct at some point.
Thanks for pointing that out.

> 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/ .

That copy is for old build-farm systems that don't have what it takes to
build the configure.sh file.  The latest code has been modified to only
allow a build-farm system to execute that, since (as you noted) those
files only pertain to the very latest release.  Folks without the
necessary autoconf/yodl tools can also decide to make use of this dir
when grabbing the very latest dev version, but they'll need to run the
rsync manually.

> 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.

I didn't want all the patch (side-branch) commits cluttering up the
master branch's release log.  This history can be accessed in the old
CVS archive, which is going to remain available.  It would be nice
to create a script that could translate the CVS commits to the patches
into branch commits in a git branch, but I haven't tried to look at
that.

> 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.

The web page mentions that it sets the file times to their time of last
modification.  I want an INITIAL checkout (clone) to always set each
file's time to the time of its last change (not the checkout time), and
this script works-around git's deficiency in this area.  This makes a
fresh checkout the same no matter when it is cloned (though two
checkouts would diverge in their mtime settings as they are
incrementally updated after that point).

> 5. How will you mark the revisions of the branches that were provided
> with a particular rsync release?

I haven't fully worked out everything pertaining to the git handling of
the patch branches for a release.  I'm currently putting the set of
patch diffs that represent the state of each patch branch at the time of
a release into a separate patch tar file.  The patches for the dev
version are also available as diffs at this URL:

    http://rsync.samba.org/ftp/rsync/patches/

How the branches get tagged in git I'll need to work out a bit more.
Thanks for your tagging suggestion.  I'll look into it.

..wayne..