point to active repo? about git-remote-hg HOT 10 CLOSED

For some reason, people have been using felipec/git-remote-hg instead of the original (and active) mnauw/git-remote-hg as the canonical source of git-remote-hg.

Maybe the reason is that I am the author. My version is the canonical version. Since I wrote the thing.

For that reason it has accumulated issues and pull requests that belong at mnauw/git-remote-hg

No they don't belong there.

I'd argue that since @mnauw is the cannonical repo...

It is not.

First things first. I started the project in 2012 in the Git repository, and as of now I have committed around 400 commits, and of those 100 in the Git core, as many changes where needed. Any fork of this project would have benefitted from those patches, aso would any other transport helper.

Even in the fork you mention I am the author with most commits:

    174 Felipe Contreras
     73 Mark Nauwelaerts

And If you do a git blame you would see most of the lines of code came from me:

   4165 Felipe Contreras
   3001 Mark Nauwelaerts

So no, I am the author, and this is the canonical repository.

from git-remote-hg.

Very sorry about the mistake : /

I hadn't checked the blame record. I made that assumption because github indicates your repo was forked from @mnauw:

Thank you for creating this and for all the work you put into this!

Since the mnauw fork is in active development and the source for the pypi package, might it still make sense to point to that?

https://pypi.org/project/git-remote-hg/

from git-remote-hg.

Already you are not right.
If I remember well, there was time ago discussion about to setup the new official upstream because of inactivitivy here, same as @felipec was not responding to anyone (and was inactive for more then year on github - from 2019 Jan 25 to 2019 April 12) - @felipec correct me if I am wrong and you answered to people. So even when @felipec is original author, the official upstream is now moved to @mnauw and was already accepted by various projects, as this one was broken more than 1y and people wanted to use the utility. v0.4 was released a time ago and was accepted. Nowadays the official latest release is v1.0.1.

To prevent confusion, I would suggest to create new repository completely where will be more people with write permission (@mnauw, @felipec) or continue with the one that's already accepted. Definitely would be nice guys if you cooperate, as project can have only one upstream and v0.4 was long ago provided in various projects. The new v0.4 release here is already too late.

from git-remote-hg.

I hadn't checked the blame record. I made that assumption because github indicates your repo was forked from @mnauw:

Yes, GitHub is wrong, I wonder why that changed. Anyway, I contacted support to fix that.

Since the mnauw fork is in active development and the source for the pypi package, might it still make sense to point to that?

Yes, probably. I'm still not sure what I'm going to do about mnauw's fork. I'll probably rebase all his changes on top of mine, and see how best to sync both projects. It will take time though

from git-remote-hg.

Already you are not right.

Where am I not right?

a) I am the original author, b) I am still the main author, c) @mnauw's is a fork, this is the original repository. Those are facts.

If I remember well, there was time ago discussion about to setup the new official upstream because of inactivitivy here, same as @felipec was not responding to anyone (and was inactive for more then year on github - from 2019 Jan 25 to 2019 April 12) - @felipec correct me if I am wrong and you answered to people.

Yes, I became inactive because I lost motivation in open source projects, specially due to the attitudes of some people in power.

But my code worked. In fact, it's almost miraculous how well it worked. At the time I started the project in 2012 all that was available was a fast-export script that more or less worked, and no way to push changes.

It was my idea to create a transport helper, so it was transparent to the user. I spent many many hours developing this just because I didn't want to use Mercurial to work with Mercurial repositories even though I didn't work with Mercurial repositories.

In order to make it truly transparent I had to familiarize myself with the internals of Git's core, and find areas of opportunities, and in order for Git developers to accept my patches I had to send many versions, and sometimes fight them over the need for those changes. I eventually created a second project called git-remote-bzr just so developers saw that these changes where for all remote helpers. I also created a git-remote-testgit helper to make sure the changes are not specific to git-remote-hg.

There were about a hundred of changes to the core to arrive to the point we are now.

Just to give you and overview to the kind of work that was needed for the Git core:

• Patch series (list of 16)
• Patch #15 (7 versions)
• Thread of patch 15 v5 (24 mails)
• Message #8 (1544 words)

This is only one patch series, and to even count the amount of mails I sent is actually a lot of work. Can you imagine the amount of work it took to write them? To think about them? To run tests to make sure I was telling the truth?

And of course, actually writing the code. But the git.git project has such high standards that writing the code is often the easy part; the commit message and the follow up mails are more important.

That is the story of one patch out of hundreds, but all users of git-remote-hg (and other remote helopers) benefit from that, even mnauw's fork benefits from that.

But all people saw was that git-remote-hg worked essentially flawlessly; it was a true transparent bridge.

You don't know the drama behind the reasoning why git-remote-hg became an independent project outside of git.git, but it doesn't really matter, what matters is that I was disappointed as a result.

For many years I didn't receive any support, only the occasional patch that I basically had to rewrite because it didn't match my standards. But git-remote-hg worked, and it was good, everybody liked it.

I lost motivation, and I moved on to other things.

After a long time things started to break (Mercurial's fault), and some reported the issues (which I didn't see because I wasn't following github), and then suddenly people started to care. How true is that saying that you don't know what you have until it's gone?

But I was away. I didn't know it was completely broken, I didn't know there was a fork. Nobody posted fixes to GitHub, nobody posted fixes to the mailing list, nobody sent mails directly to me.

I have only two mails directly addressed to me, one is asking me what is the status, the other is telling me my fork should point to mnauw's original repo. The last one was five years ago.

And BTW, have you seen the README?

== Contributing ==

Send your patches to the mailing list [email protected] (no need to
subscribe).

Do you know how many patches were sent to the mailing list? One.

Yes, I neglected the project that had been working flawlessly for years thanks to my countless hours of work, before which there was nothing. But goddamn, have some perspective as to what makes git-remote-hg what it is today.

So even when @felipec is original author, the official upstream is now moved to @mnauw and was already accepted by various projects, as this one was broken more than 1y and people wanted to use the utility. v0.4 was released a time ago and was accepted. Nowadays the official latest release is v1.0.1.

Oh, that's the "official" release huh? According to whom?

Yes, I'm glad mnauw's stepped up and fixed the latent issues, but his is a fork, this is the official repository.

It's understandable that people are using his fork at the moment, since it's the only code that worked for a while, but I find it disturbing how inconsiderate people are; they don't care who made git-remote-hg happen, so who cares if distributions are not using the original repository that the original author spent thousands of hours working on.

Fuck the original author, right?

To prevent confusion, I would suggest to create new repository completely where will be more people with write permission (@mnauw, @felipec) or continue with the one that's already accepted. Definitely would be nice guys if you cooperate, as project can have only one upstream and v0.4 was long ago provided in various projects. The new v0.4 release here is already too late.

Well, this is the original repository, I don't care what other people have accepted. Get your definitions straight; this is the upstream.

Now, I have a lot of experience with forks (I maintain a fork of Git myself), so I have a lot of ideas of what to do moving forward, but this repository will still be maintained as the original, official and upstream repository.

It would be nice if @mnauw did the right thing in my opinion, which is to rebase his fork to my latest master, and send patch series to the mailing list to be reviewed, and applied. But that's probably not going to happen, and once again I will have to do all the work myself and synchronize both repositories, and probably send him patches so eventually we are both on the same page.

Or maybe a miracle occurs and somebody else does that work. Maybe you! Just joking, that never happens.

Hopefully his is going to be a friendly fork, but it's not the first time I've had to deal with forks. Have you heard of gitifyhg? Well, that was an unfriendly fork of git-remote-hg claiming to be "inspired" by it. Eventually I implemented the only real differentiator they had, but in much much better way. I sent them patches so their project would be more aligned with mine, but they didn't even reply. So now gitifyhg is no more; because there was never any need for a fork.

Oh wait, that's another chapter in the story of what made git-remote-hg so great today, but you are not interested in that, are you? All you care is that this is not the "official" repo... right.

And BTW, have you noticed that you can't pull tags after Git v2.20? Well, that's because there was a regression... If only there was a person with enough knowledge both of remote helpers and the internals of Git...

Wait! There is, and he already fixed it: PATH: fetch: fix regression with transport helpers.

from git-remote-hg.

@felipec I apologize that I made you upset by my comment. I didn't mean to degrade work you did by that. I just tried to summarize discussions of the last, ~6 months?, to point out what is the possible reason that your project is not marked as forked and why the discussions started. True it is, that more than year git-remote-hg was not working, as there have been a lot of changes in mercurial which made the code crashing constantly and nobody accepted any changes here. I do not remember there were issues because of git, but I am not focusing on this project so much.

And BTW, have you seen the README?

== Contributing ==

Send your patches to the mailing list [email protected] (no need to
subscribe).

To be honest, probably not or I have forgotten about that part completely. When I saw the upstream is marked to be here and you have been active from the start here, I expected to communicate everything just through the github environment. I agree that's my mistake, that obviously did a lot of other people, regarding your comment above.

Oh, that's the "official" release huh? According to whom?

Just from the practical point of view, that there are various projects outside that accepted newer versions as official (and you shoudl be able to find newer versions in pypi as well, regarding the discussion here). I understand that you do not agree with that, but in the world there are now already git-remote-hg installed as v0.4, v1.0.0 and probably v1.0.1 as well. Just from the point that two same versions for same-name project shouldn't point to two different sources. Just imagine that people will report bugs informing you about the version which will be about different code than you think. So from my point it makes pretty sense to continue bumping releases instead of generating confusion by creating new releases witch will appear for many people as downgrades.

from git-remote-hg.

Anyway, whatever you will decide in the end, would be nice if git-remote-hg in pypi would point to the same upstream in future. So in case this repo should be set as upstream, would be nice to take care about that in pypi. Again, would be nice if you guys (@felipec, @mnauw) cooperate on sync and just one repo will be set as upstream in world.

from git-remote-hg.

I apologize that I made you upset by my comment. I didn't mean to degrade work you did by that. I just tried to summarize discussions of the last, ~6 months?

It's not your comment that makes me upset, it's the whole stance of the community. I've lost count of the number of people that have said that my project is a fork.

But your comment is also not correct. I don't like people using loaded language; maye you like Mark's fork best, that's fine, but don't call it "official", or "upstream", because that suggests everyone should use that.

What most people use should be based on the merits of the project, not labels such as "official".

Now, I think you are missing a crucial part of the summary of the last months (I think it's years in fact); I never had a second in command. The whole time I worked on the project I never had an active contributor. Most people either reported issues, suggested impossible tasks, or contributed a sporadict patch or two.

So logically nobody was ready when shit hit the fan. I don't think Mark ever intended his fork to become official, but since mine wasn't working, everyone else rushed to knight his version as official.

That's fine, however, I would have done things differently. First, I would have kept two branches; a clean 'master' branch, based on my 'master', and a hacky personal branch. Secondly, I would have named it differently (I did that for my git-fc fork). And thirdly I would have used different versions (again, in my git fork I use v2.8.0+fc1).

Just from the practical point of view, that there are various projects outside that accepted newer versions as official (and you shoudl be able to find newer versions in pypi as well, regarding the discussion here).

I understand that, but accepting something as official doesn't make it so. It's not my fault Mark didn't use a different versioning scheme, such as v0.3+mn2 (or whatever).

Anyway, what is done is done, and in fact, I wouldn't recommend distributions to use my (I'm going to call it git-remote-hg+fc) v0.4, at least not yet. What I recommend is for people to test v0.4 and see if they see any issues compared to Mark's version (git-remote-hg+mn v1.0.1).

I looked at his repository and I see a bunch of changes that I definitely want to merge, but others not so much. Only after I go through each change carefully and I merge all the ones that are important would I recommend distributions to switch, and yes, I would probably would have to release a version higher than the last one Mark has (e.g. v1.2).

It would be nice if other people helped in this process, but I'm not holding my breath.

I think the least people could do is test my version v0.4, but so far I have not received any feedback.

from git-remote-hg.

That's fine, however, I would have done things differently. First, I would have kept two branches; a clean 'master' branch, based on my 'master', and a hacky personal branch. Secondly, I would have named it differently (I did that for my git-fc fork). And thirdly I would have used different versions (again, in my git fork I use v2.8.0+fc1).

For the record, the (major version) increase was on request of the previous owner/holder of the git-remote-hg pip package (see mnauw#13). If it were not for that issue (and alike) I would likely not have bothered with release(s) (and any version as such).

As any branch is but a 'moving label' in a directed tree (of commits), I feel it does not really matter what label points where at what time (as any other point is still there anyway). I am also not quite sure whether 'hacky' is an appropriate description of the amount of work and time that has been spent and that apparently has served well and without problems during this time. Let me forego further comments on how these latest events have been experienced and instead reminisce about some kitchen accoutrements.

from git-remote-hg.

For the record, the (major version) increase was on request of the previous owner/holder of the git-remote-hg pip package (see mnauw#13).

OK, but you could have asked him to increase the version epoch, so 1!0.4 becomes a higher version than whatever the old git-remote-hg had.

As any branch is but a 'moving label' in a directed tree (of commits), I feel it does not really matter what label points where at what time (as any other point is still there anyway).

Depends on the quality of the branches. Most branches in git are ephemeral; the commits inside them change all the time due to rebases, amends, squashes, etc. A quick reflog of my 'master' branch shows 15 amends, 3 rebases, and 5 resets.

Often when implementing a new feature I create a separate branch for that, and that branch gets reworked and reworked. For example for the latest check-versions script I ended created 6 versions of the feature branch:

* (check-versions) (3 commits, 4 resets)
| * (check-versions-5) (5 commits, 3 resets)
|/
| * (check-versions-4) (7 commits, 9 resets)
|/  
| * (check-versions-3) (7 commits, 6 resets)
|/  
* (sharness-output-dir)
* (check-versions-2) (13 commits, 3 resets)
* (check-versions-1) (18 commits, 1 reset)

Of course, the final version ended up quite clean: only 3 commits. Of course, that's just me, but I think something like that could have been done for example for the hg-helper, which could have lived in a separate branch for a while.

I am also not quite sure whether 'hacky' is an appropriate description of the amount of work and time that has been spent and that apparently has served well and without problems during this time.

I did not say all your work was hacky; I said you could have had a "hacky" branch (a hypothetical). This branch could be hacky, or extremely clean; it doesn't matter, it could have graduated to master squashing certain commits that are not necessary in the history, like mnauw/git-remote-hg@5999a10. New features usually benefit from brewing in a separate feature branch for a while.

Besides, we all make hacky commits, you yourself described on of yours like that: (mnauw/git-remote-hg@e19dd84).

from git-remote-hg.