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