Assorted concerns about git repository

[Matt McCutchen]

Wayne,

Thanks for addressing the concerns.  I have some comments:

On Wed, 2007-11-28 at 15:33 -0800, Wayne Davison wrote:
> 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 [...]

That's reasonable.

> The latest code has been modified to only
> allow a build-farm system to [download the generated files ...]

Good.

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

That makes sense.

> This history can be accessed in the old
> CVS archive, which is going to remain available.

I would like to have it in my git repository.  Should I import it
myself?

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

I understand that git-set-file-times will achieve this CVS-like effect.
My question is, why do you care about the mtimes of two fresh checkouts
being the same?  I consider git's complete obliviousness to mtimes to be
a purity rather than a deficiency.

Finally, let me add another concern:

6. I notice that "support/patch-update" updates branches by rebasing.
This approach has a serious problem: when a branch with a long history
is rebased onto a new trunk, some of the intermediate revisions of the
branch may no longer make sense, and there is no good way to update the
branch while retaining a record of those revisions.

The obvious alternative, merging, is also deficient.  Suppose branch B
depends on branch A (e.g., detect-renamed-lax and detect-renamed);
naturally, B would be set up to track A.  Once B gets commits from A
woven into its history, there is no good way to remove the A-specific
material if the dependency later ceases to exist.  Simply applying the
inverse of the latest trunk->A diff will trip up anyone who later tries
to merge B with another branch that actually does require A.

In light of this, I admit (red-faced) that the directory of patches
actually seems to be better than anything git supports natively.  I
wonder if the git people have a recommended solution for projects like
rsync that have a trunk and branches with dependencies.  I have some
ideas about how a solution could be added to (or scripted around) git,
but I will let them mature before proposing anything.

Matt