tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)




> 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



Home | Main Index | Thread Index | Old Index