Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
I would be very happy if a decision would be taken in a timely manner. I prefer git over mercurial, but any of them is better than cvs. > Am 14.05.2020 um 17:27 schrieb Martin Husemann : > > On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote: >> I.e. the final repo DAG should contain all submitted commits, and all >> that history should be visible to those who look for it (just as is the >> case with merges from github "pull requests"). > > This is the case in our setup. In the "draft" phase you can revert, > rewrite, collapse and change a few things, but in the end you have > a line of changesets that on final push are made visible on the tip > of the trunk (still as individual changes). > > Martin
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote: > I.e. the final repo DAG should contain all submitted commits, and all > that history should be visible to those who look for it (just as is the > case with merges from github "pull requests"). This is the case in our setup. In the "draft" phase you can revert, rewrite, collapse and change a few things, but in the end you have a line of changesets that on final push are made visible on the tip of the trunk (still as individual changes). Martin
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 22:11:20 -0400, John Franklin wrote:
Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>
> Put another way, it’s nothing more than “please consider the changes
> in branch jqcoder/foo for inclusion in your project.” Any DVCS that
> can handle branches reasonably well can do something like a “pull
> request.” If you like it, `${DVCS} merge jqcoder/foo`. The way GitHub
> handles PRs, the branch lives in their private clone of the
> repository, not the main project’s copy. It prevents the master
> repository from getting polluted with dozens of pull request branches.
Yes, sort of.
Just to be pedantic though -- on githup "clones" are actually just
custom "views" of the same repository, storage-wise; and this gives
github the ability to quickly show all progress in all clones all at
once in one graph view.
My desire here is to see a (clean) history of branch commits be fully
imported into the NetBSD repository, complete with all its _original_
VCS metadata, but perhaps with the visible branch name removed.
I.e. the final repo DAG should contain all submitted commits, and all
that history should be visible to those who look for it (just as is the
case with merges from github "pull requests").
> It should be possible to go both ways. I’ve seen very clean pull
> requests of a few commits that should be merged including the full
> history, and some that were 300+ commits with one-third of the commit
> messages including the words “revert” or “undo” in them. (In some
> cases, the commit message was simply “revert”.) Following the chain
> was fruitless, only comparing the branch to the mainline was of any
> value, and a squash commit is the only way to handle such things.
Well, the point of what Kun was getting at, I think, and what I would
like to see for NetBSD, is that a reviewer should entirely reject an
un-clean commit history. Commit history that shows and documents the
intent and progress of changes is what's desired (and what makes review
easier for some/many reviewers), but of course a lot of false paths and
ugly hacks that are undone and tried again and again doesn't help tell
any real story about the final code or the path actually taken to get to
just that final result. Commit history is exactly that -- a history
meant to be read and remembered by the humans who come afterwards.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpcF6DD4_705.pgp
Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On May 13, 2020, at 17:56, Greg A. Woods wrote:
>
> At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote:
> Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>>
>> On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
>>> At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote:
>>>
>>>> I have no idea what the OP is talking about. Mercurial doesn't have pull
>>>> requests, neither does git BTW. So this is about some specific web UI or
>>>> review tool, but I don't even know which one.
>>>
>>> Consider "pull request" to stand in for _any_ kind of workflow and
>>> mechanism that third parties would use to submit changes along with the
>>> recorded existing metadata for those changes, to the upstream project's
>>> repository.
Put another way, it’s nothing more than “please consider the changes in branch
jqcoder/foo for inclusion in your project.” Any DVCS that can handle branches
reasonably well can do something like a “pull request.” If you like it,
`${DVCS} merge jqcoder/foo`. The way GitHub handles PRs, the branch lives in
their private clone of the repository, not the main project’s copy. It
prevents the master repository from getting polluted with dozens of pull
request branches.
> So thus the question remains: What will NetBSD's workflow be? Will it
> be compatible with merging a set of changes from a third party in much
> the manner of what's typically called a "pull request" in the Git
> (github, gitlab, etc., etc., etc.) world, and especially in a way that
> avoids squashing a branch into a single commit (thus losing commit
> metadata)?
It should be possible to go both ways. I’ve seen very clean pull requests of a
few commits that should be merged including the full history, and some that
were 300+ commits with one-third of the commit messages including the words
“revert” or “undo” in them. (In some cases, the commit message was simply
“revert”.) Following the chain was fruitless, only comparing the branch to the
mainline was of any value, and a squash commit is the only way to handle such
things.
jf
--
John Franklin
frank...@elfie.org
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote: > > At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: > > > > > I have no idea what the OP is talking about. Mercurial doesn't have pull > > > requests, neither does git BTW. So this is about some specific web UI or > > > review tool, but I don't even know which one. > > > > Consider "pull request" to stand in for _any_ kind of workflow and > > mechanism that third parties would use to submit changes along with the > > recorded existing metadata for those changes, to the upstream project's > > repository. > > The statement still makes no sense at all. Nothing forces you to fold > all incremental steps into a single changeset. Some workflows clearly do force squashing of commits into a single one (even in git-only projects or hg-only projects), else Kun wouldn't have written what he did, and I wouldn't be wondering as well. So thus the question remains: What will NetBSD's workflow be? Will it be compatible with merging a set of changes from a third party in much the manner of what's typically called a "pull request" in the Git (github, gitlab, etc., etc., etc.) world, and especially in a way that avoids squashing a branch into a single commit (thus losing commit metadata)? -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpnDI5pUiRCT.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote: > At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: > > > I have no idea what the OP is talking about. Mercurial doesn't have pull > > requests, neither does git BTW. So this is about some specific web UI or > > review tool, but I don't even know which one. > > Consider "pull request" to stand in for _any_ kind of workflow and > mechanism that third parties would use to submit changes along with the > recorded existing metadata for those changes, to the upstream project's > repository. The statement still makes no sense at all. Nothing forces you to fold all incremental steps into a single changeset. Joerg
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > The staging area is a general point of contention, even in the git > world. Interactive commits (commit -i) and incrementally amending > changes pretty much cover the general use cases without all the > cognitive load another level of changes has. Interactive commits that are driven by the tool are pointless as an alternative for my use case of the Git staging area -- they are, by definition, "interactive" i.e. not programmable. The way most Git users use the staging area with Git is in a way that can be considered programmable, and the way many of us actually use the staging area is indeed through other tools that drive Git programmatically, as is the case with the tool called Magit that I use from within Emacs. So, until/unless Magit (in my case) grows support for Mercurial, and/or something even more usable appears in the Emacs world as a front-end for Mercurial with similar capabilities, I'll continue using Magit and Git in order to capture my work and the metadata about it into a change management system. That's just my personal limitation, but I suspect it matches what other Git users, and especially Magit users, would prefer. The question I have is then whether, and how, I can share such changes and the captured metadata about them with the upstream project. That's done trivially with Git on both ends of course, but presumably Git can also push changes to Mercurial in some lossless way as well (or vice versa, Mercurial can pull changes, complete with their metadata, from a Git repository). > I have no idea what the OP is talking about. Mercurial doesn't have pull > requests, neither does git BTW. So this is about some specific web UI or > review tool, but I don't even know which one. Consider "pull request" to stand in for _any_ kind of workflow and mechanism that third parties would use to submit changes along with the recorded existing metadata for those changes, to the upstream project's repository. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZCTTBhVeGA.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 07:53:28 +0200, Thomas Klausner wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > > 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 disagree. Anyway, what git does here is "git add --patch" and the hg > eqivalent is "hg record" (which is not enabled by default; just add > "record=" in an "[extensions]" block in your .hgrc to enable it), so > the functionality is available for both tools. Since I won't ever be using Mercurial directly for day-to-day work (unless current circumstance that go far beyond my own control change very drastically), the question then turns to how will the moral equivalent to a pull request look once merged into the trunk/master branch, or whatever it will be called. The point I was trying to make by referring to Kun's essay is that the original commits should still exist in the DAG (even if the original branch name is removed from the master repo). I.e. that no commit metadata from the original submission ever be lost. The failure of CVS and using patches to submit changes is that _all_ of the commit metadata is entirely lost, and the failure of the workflow Kun describes with Mecurial (at Google) is that _most_ of this metadata is still lost. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpigu1kIdsHK.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
> 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
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > 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! The staging area is a general point of contention, even in the git world. Interactive commits (commit -i) and incrementally amending changes pretty much cover the general use cases without all the cognitive load another level of changes has. > 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. I have no idea what the OP is talking about. Mercurial doesn't have pull requests, neither does git BTW. So this is about some specific web UI or review tool, but I don't even know which one. Joerg
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > 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 disagree. Anyway, what git does here is "git add --patch" and the hg eqivalent is "hg record" (which is not enabled by default; just add "record=" in an "[extensions]" block in your .hgrc to enable it), so the functionality is available for both tools. > Mercurial also collapses all changes within a pull request > (changeset) into a single commit. That's just not true (as the next two comments in the thread clarify). Thomas
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
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.) 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZVBBmAGt5E.pgp Description: OpenPGP Digital Signature
