Martin Husemann <martin%duskware.de@localhost> writes: > On Fri, Mar 18, 2016 at 10:57:51AM -0400, Greg Troxel wrote: >> Agreed that with git or hg it is straightforward to map existing >> practices. > > I disagree. At least is not a clear, single and non-controversial mapping. > Even with svn (where the mapping is nearly verbatim) we would have to > define branch/tag naming shemes. Yes, but I don't think that's hard. I am pretty sure We can use the same naming scheme we have now. But I realize it's not useful to talk abstractly about whether it's hard, so I'll try to be more specific and constructive. > And "current practices" have to include the releng workflow. Certainly; that's the hard part. So, here's a basic attempt at replicating what we have now in CVS, but using git. Define that a particular git repository on a TNF server is the the official repository. Optionally, set the social expectation that all clones will have content that matches the offical repo, for all branches and tags in the official repo. master (the default/main branch) is treated like CVS HEAD. Ask people not to put "git pull" merge commits on master, or progammatically avoid them, as is the rule and configuration in pkgsrc-wip. These aren't created with CVS or SVN, so this rule is arguably part of the default mapping. To create a release branch like netbsd-7, "git checkout -b netbsd-7" and push it. This matches the CVS semantics (with the nit that it doesn't record the branch name in commits, but that doesn't actually matter). To tag a release, use either git tag (simple tag) or more likely git tag -a (annotated tag). To pull up a commit on master to a release branch, while on the branch, do "git cherry-pick -x" and the id. Use git commit --amend if that's messy (due to a non-clean changeset), or to record other metadata. This is more or less like 'cvs up -j1.x -j1.y src/some/file.c; cvs commit'. Either make a separate commit with the CHANGES entry, or fold it into the actual change. Probably, for netbsd-7-0, cherry-pick commits from netbsd-7. To pullup via patch on a release branch, just make new commits. Or, ask the submitter to make them and have releng examine then and if acceptable put them in the official repo. Perhaps still do it via cherry-pick and levae the -x line referencing the original, or put the note in by hand. But this boils down to "make commit on release branch that makes the change you want and whose commit message has the right content", which is not different from CVS. Decide that master and e.g. netbsd-7, while having common ancestry at the branch point, will not be merged into each other. This means all changes that flow in either direction will be via cherry-pick. For vendor branches, call them vendor.openssl, etc. Create commits that put the first or new version on that branch. The first time, do a sub-tree merge to put that vendor branch in the right place in our tree (somewhat complicated, but very few people need to do it). For updates, just merge the updated vendor branch. I could of course be off about some releng issues. I've done basically all of the above in private projects, including one that imported all of netbsd and pkgsrc, and I'd do it again. I think that's a relatively straightforward and non-controversial mapping, and that most people familiar with existing NetBSD workflows and git would arrive at the above as the least-change default mapping, or at least one of the candidates for the default. I think other DVCSs would be pretty much the same. Certainly, there are further changes possible, such as: Ask people to write better commit messages, both in terms of actually describing the change and in having a 50-character summary line that works well with "git log --oneline". Ask people to make clean commits that only do one thing, to make the pullups easier, but this is really no different from now. The culture of 'while here, do $RANDOM_UNRELATED_THING' is unfortunate and I'm somewhat surprised releng hasn't asked people not to do that. Using temporary feature branches for non-trivial changes, and having them available for reviewing and testing before merge to master. Further, expecting those feature branches to be fixed up and rebased before merging, removing considerable short-term error/fix churn from the history. Expecting feature branches to pass build/anita before merging, perhaps by some automated process. but these are all beyond a mapping of current practice.
Attachment:
signature.asc
Description: PGP signature