> Am 13.05.2020 um 05:55 schrieb Greg A. Woods :
>
> At Tue, 28 Apr 2020 08:50:55 +, m...@netbsd.org 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 - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
