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.)
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.
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 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.
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp5uycxH72LC.pgp
Description: OpenPGP Digital Signature