> Am 13.05.2020 um 05:55 schrieb Greg A. Woods <woods%planix.ca@localhost>: > > At Tue, 28 Apr 2020 08:50:55 +0000, maya%NetBSD.org@localhost wrote: > Subject: Re: github.com/NetBSD/src 5 days old? >> >> As a reminder, hg/git offer far better interoperability (than CVS). >> Much of my own NetBSD work is done on Git, and even if I don't stop >> doing this, I would be happier if the backend was Mercurial. > > So I've still not found any discussion explaining the reasoning behind > Mercurial vs. anything/everything else. > > For me as I work independently on NetBSD it doesn't really matter what > the back-end is so long as I can use Git for my day-to-day work and to > keep better track of my local changes. (That, btw, is still very much > just a work in progress for me -- I've been unable to use the current > repo on github as it breaks after updates far too often, i.e. whenever > the conversion is unstable somehow.) I seriously had kind-of trouble managing local changes vs. pushed (cvs committed) changes and therefore I don't do much at the very moment. As I'm doing it in spare time (shared with at least 5 time intensive other hobbies), the conflict resolution time almost eats up all slices. This is bad, since I would seriously like to prepare some things to be sent to pkgsrc just like old times :D > However it would seem to me to be better and easier, for me, to be able > to publish those of my changes that I would hope to feed back to the > main NetBSD repository via Git, and in such a way that my original > commit metadata does not get lost or squashed or rewritten in any way. > As-is this has been a major stumbling block for me w.r.t. feeding back > some of my changes and fixes in terms of sending patches, etc. while > NetBSD still uses CVS. Well - most hosters and services support just git meanwhile. Atlasssian dropped mercurial support, public available CI services as Travis or Circle CI do git only - that get's longer and longer. > Not knowing Mercurial myself, nor how it interoperates with Git, I'm > unsure of whether this is possible or not, especially given whatever > workflows the NetBSD core team comes up with. > > However I recently encountered this essay by Jeremy Kun which has > presented some of my less-well formed thoughts in a more concrete way, > and in particular one of his replies to a comment that was posted about > his essay: > > "The Communicative Value of Using Git Well" > > https://jeremykun.com/2020/01/14/the-communicative-value-of-using-git-well/#comment-110432 > > For one, Mercurial has no staging area. That removes one level of > the three-level hierarchy from my toolset. It’s hard to identify > exactly when in my workflow this causes issues, but I’ve started to > notice it. For example, it’s not possible to commit a hunk from my > editor like I can with git and vim-gitgutter. > > I do the same with magit -- the staging area is a supreme benefit! I fully agree to Joerg Sonnenberger here. > I guess that it wouldn't matter if one used Git for day-to-day work and > the back-end was still Mercurial, but that very much begs the question > of just what benefit Mercurial can possibly bring in the long run. > > Mercurial also collapses all changes within a pull request > (changeset) into a single commit. That removes the meaningful > difference between the top level (pull request) and the mid level > (commit) that I find helpful to narrate. There is some ability when > working locally to create a bunch of commits like I would in git, > and then later squash them all using hg histedit. But my reviewers > can’t see the individual commits, nor can they be seen or reverted > individually in the long term project history. > > If this is the case it would also seem to be a major drawback to > Mercurial. There are further comments that suggest this may not be > quite so bad as Kun makes it sound, and indeed that part of his problem > might actually be specific to the workflow that his employer forces, but > there's also some ongoing doubt about this. This is very likely a frontend issue, I don't know what Kun refers to. OTOH - pull requests (or development-branches ...) should have a topic, e.g. 'Upgrading Perl5 to 5.32' which contains the p5 core upgrade, revision bumps of p5-* and some dependency patterns updates based on new core-modules. There will be now reason to revert just one of those commits - all of them or not. If parts of such a PR can be reverted, it's unfortunately assembled. Cheers. -- Jens Rehsack - rehsack%gmail.com@localhost
Attachment:
signature.asc
Description: Message signed with OpenPGP