> Am 19.03.2016 um 18:59 schrieb Greg Troxel <gdt%ir.bbn.com@localhost>: > > > 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". I agree to everything but that :) In several - public and non-public projects the "50-character summary rule" has been thrown away. Github etc. fuck them up - but "git log --oneline" behaves nice and sweat without any harms. In current $job I have to work on Yocto (and I learned how to bootstrap Java without downloading any pre-compiled binaries ... - hopefully find a tuit to hack that in pkgsrc), see poky or meta-openembedded commits to verify :) > 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. Best regards -- Jens Rehsack - rehsack%gmail.com@localhost
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail