Re: gitifyhg

[Dusty Phillips]

Hi Jed, Max,

I'd been meaning to set up a mailing list, but it fell into that bucket
with all the other meaning to stuff. I don't have a google account, so
forming a google group was outside my options. Thanks for setting one
up, Max.

> * First off: I am quite glad that you two spend effort on this,
> thanks a lot!!! I've been waiting for at least two years for a really
> usable git-hg bridge, and it finally seems to be within reach. I know
> plenty people who want this, too, and I'll try to recruit some of
> them as testers, too.

I, too, am delighted by your contributions. The current version of
gitifyhg was basically my fourth attempt at the job, as you can see via
the complete failures in the git history. My initial goal was to get
something useful enough that people would want to contribute to it, but
to be honest, I didn't think I'd got that far, yet!

I use gitifyhg daily now, and haven't had to reclone from scratch or git
format-patch to rescue a broken push or pull for a while now. My
favourite part is when stuff I need to fix gets fixed by one of you!

> * Some time ago, dusty granted me write access to the primary repo.
> Thank you for the trust! I made some small commits directly, but for
> bigger changes, I think I'll prefer to use pull requests, to give you
> guys a chance to review what I do before it goes in. I made several
> silly mistakes in the past which luckily one of you noticed and fixed
> or reported to me, which I am grateful for and would like to continue
> benefiting from ;-).

Early development is allowed to be more chaotic, but now that we are
settling into a multiple contributors submitting patches for specific
bugs and features routine, I'd definitely like to see master always
stable. Pull requests work fine, or feel free to push new branches to
the main repository. Pull requests may actually be a better idea since
commenting on branches is not as supported in github. The only problem
is I can't write pull requests for you guys to review into my own
repository.

> * I tweaked the README a bit: Since I run OS X, I changed it to list
> that as explicitly supported. Jed, what do you use, perhaps we could
> mention that, too? I also changed "I" and "me" to "we" and "us",
> since multiple people contributed now. But overall, the README could
> stand a somewhat bigger overhauls. E.g. it refers to "7 expected
> failures" in the test suite... such references are prone to become
> outdated. So I'd rather stay more vague and refer to the tests
> themselves or travis or so... and also the issue tracker. Next, I'd
> merge "Dependencies" and "Supports" into a single "Requirements
> section. Perhaps also add a "Credits" section listing Dusty as
> principal author but also other contributors: Felipe (a lot of the
> code comes from him), Jed, Alex Sydell, Jason Chu, me, ... There are
> various other little things and streamlining that could be done,
> too.
>
> Anyway, if I find some time and inspiration, and hear no objections,
> I'll work on that. But please don't let that stop you folks from
> working on it, too *ggg*

All of these things are a great idea. Like I said, my initial pass was
to attract more coders, but that's changed now, and I think it's fair to
say gitifyhg is good enough for beta users.

I am personally a chronic documentor, so I can guarantee these things
and more will happen... eventually.

> * I spent some effort on taking the msysgit remote-hg and rebasing it
> on the latest git -- this require going through it all as there were
> lots of conflicts. Luckily I track the git mailing list quite closely
> these days, so in most cases I knew where this came from and how to
> address it. It was even possible to drop three of the msysgit
> commits, as equivalent code is now in git.git. If you are interested,
> you can find the code here:
> <https://github.com/fingolfin/git/tree/msysgit-remote-hg-rebased>. I
> tried running this against the gitifyhg test suite (after installing
> the msysgit remote-hg as git-remote-gitifyhg in a virtualenv). But
> there are tons of spurious failures due to design difference. (E.g.
> our tests except that notes are used and in *exactly* the way we use
> them... Perhaps we should move all notes related tests into a
> separate test_notes.py ?). So the results are not that useful right
> now :/.

I haven't looked at that remote, but I get the impression you considered
it to be one of the more advanced and usable ones of the various options
out there? Is it actively developed? Can we learn from it? Is it worth
joining forces?

Dusty

[Jed Brown]

On Sat, Feb 9, 2013 at 11:55 AM, Dusty Phillips <du...@buchuki.com> wrote:

Hi Jed, Max,

I'd been meaning to set up a mailing list, but it fell into that bucket with all the other meaning to stuff. I don't have a google account, so forming a google group was outside my options. Thanks for setting one up, Max.

Thanks for all the work, guys. I'm so thrilled to finally have decent local branch management after all these years of dealing with Hg rolling out new flawed branching models instead of treating their NIH syndrome.  ;-D

 

I use gitifyhg daily now, and haven't had to reclone from scratch or git format-patch to rescue a broken push or pull for a while now. My favourite part is when stuff I need to fix gets fixed by one of you!

Me too. I recloned recently to fix the author names, but things have mostly been working otherwise. The issue with remotes not advancing on push is mildly annoying and I don't know how to fix it.

  

* Some time ago, dusty granted me write access to the primary repo.
Thank you for the trust! I made some small commits directly, but for
bigger changes, I think I'll prefer to use pull requests, to give you
guys a chance to review what I do before it goes in. I made several
silly mistakes in the past which luckily one of you noticed and fixed
or reported to me, which I am grateful for and would like to continue
benefiting from ;-).

Early development is allowed to be more chaotic, but now that we are settling into a multiple contributors submitting patches for specific bugs and features routine, I'd definitely like to see master always stable.

Dusty also granted my write access. My usual policy is to use pull requests for anything that possibly warrants comments or that needs testing, but to push directly for benign things like doc fixes or in case an urgent bug fix is needed.

 

Pull requests work fine, or feel free to push new branches to the main repository. Pull requests may actually be a better idea since commenting on branches is not as supported in github. The only problem is I can't write pull requests for you guys to review into my own repository.

Yes you can, here's an example on my repo:

https://github.com/jedbrown/gitifyhg/pull/1

Just use the pull request button and use the owner drop-down menu.

 

* I tweaked the README a bit: Since I run OS X, I changed it to list
that as explicitly supported. Jed, what do you use, perhaps we could
mention that, too?

I'm also on Arch Linux.

  

I haven't looked at that remote, but I get the impression you considered it to be one of the more advanced and usable ones of the various options out there? Is it actively developed? Can we learn from it? Is it worth joining forces?

I'm also curious what they are doing differently. Max, did you run the test suite after your refactor to move the notes checking out?

[Max Horn]

Hi folks!

On 09.02.2013, at 20:36, Jed Brown wrote:

> On Sat, Feb 9, 2013 at 11:55 AM, Dusty Phillips <du...@buchuki.com> wrote:

>> I haven't looked at that remote, but I get the impression you considered it to be one of the more advanced and usable ones of the various options out there? Is it actively developed? Can we learn from it? Is it worth joining forces?

[For reference / list archive: talking about https://github.com/fingolfin/git/tree/msysgit-remote-hg-rebased resp. its msysgit source]

It sure would be nice to join forces instead of developing independently. But then again
a) the msysgit remote-hg has been stagnant for an extended period of time, its developers use it but don't really develop it right now
b) it currently relies on some changes to git itself. in my rebase version, some of those could be dropped, and the remaining ones may not be essential (though I am not sure); but this in itself poses somewhat of a barrier for new users.
c) I find the code to be somewhat ... confusing. They made some design decisions that I find questionable, such as subclassing mercurial classes, even though those tend to change a lot on the inside, which has caused various incompatibilities in the past. I tried to improve that a bit in my rebased version... but.. hm.
d) Error handling in it is... spotty. When I experimented with it, I got tons of exceptions and errors, some of which I documented on https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg

Also note that there was somewhat of a flamewar between its authors on the one hand and Felipe on the other hand on the git mailing list. I don't want to take sides on that issue, but in my eyes, neither party looked exactly good. I especially disliked how both sides boasted how good and superior their solution was over the other's, when in fact I was aware of several (IMHO) severe shortcomings in both... I think some modesty goes a long way towards attracting "competing" implementors to work together. Which is also why I still think we should tone down the README a bit, changing "This is the most robust and usable git to hg bridge currently available" to, say "This is the most robust and usable git to hg bridge currently known to us, and we work hard on improving that." or even weaker, lest the statement rubs somebody the wrong way. Besides, such a bold statement should be backed up by facts (a list of other implementations tested, and specific things were they fail that gitifyhg does better). Otherwise, it's best not to make such boasts in the first place... We do have our share of relatively basic workflows that do not yet work perfectly out of the box, too, after all :-).


Anyway: Right now I can't think of anything that strikes me as particularly useful, but it still would be interesting to see if it can do anything we can't do right now, and see how it does that. But for that, it would be best if we could get a common test suite running. Alas, that seems to be difficult:

> I'm also curious what they are doing differently. Max, did you run the test suite after your refactor to move the notes checking out?

Yes I did (this was after all part of my motivation for that refactoring). Unfortunately, there are still many spurious failures due to semantic differences. E.g. :

1) it uses "<none@none>" instead of "<unknown>" if the hg user has no email specified

2) in e.g. test_clone_linear_branch() we look for "origin/branches/featurebranch" but instead get "origin/featurebranch"

3) gitifyhg attempts to translate hg's default to "master" in git, msysgit's remote-hg does not so you get "origin/master" vs "origin/default" mismatches

4) of course the notes tests also fail, but at least they are centralized now.

These, esp. 2 & 3, causes *tons* of failures all over the place. There may be some real failures hidden among them, but I did not really bother to check that. For reference, here is the py.test summary:

test_author.py .F.F.F..F
test_clone.py .FFFFFxxFFFF.FFF.X...X.
test_notes.py FFFxF
test_pull.py .FFFx..xxFF
test_push.py .FFFFFFFFFFFFFx....xFFFFF
test_special_cases.py .FF


Regarding 3), I think we should actually consciously decide whether we want to perform this mapping at all, too. It causes for some nasty corner cases, and that the primary branch is named "master" is merely a convention in git, not mandatory (albeit a widely spread convention shared by 99.9% of all projects). I certainly do see points for establishing that mapping, too; just saying we should actively decide whether we want to perform it, and then document the decisions and our rationale.


Cheers,
Max

[Dusty Phillips]

On 11/02/13 03:57 PM, Max Horn wrote:

> It sure would be nice to join forces instead of developing independently. But then again
> a) the msysgit remote-hg has been stagnant for an extended period of time, its developers use it but don't really develop it right now
> b) it currently relies on some changes to git itself. in my rebase version, some of those could be dropped, and the remaining ones may not be essential (though I am not sure); but this in itself poses somewhat of a barrier for new users.
> c) I find the code to be somewhat ... confusing. They made some design decisions that I find questionable, such as subclassing mercurial classes, even though those tend to change a lot on the inside, which has caused various incompatibilities in the past. I tried to improve that a bit in my rebased version... but.. hm.
> d) Error handling in it is... spotty. When I experimented with it, I got tons of exceptions and errors, some of which I documented on https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg

b) would have been enough to keep me from trying it, and c) is the
reason I rewrote Felipe's version instead of forking it. I could EASILY
be swayed to switch to contributing to someone else's project -- it's
less work for me! But so far, I think we've got the easiest to hack on
implementation, even if it isn't the most robust. ;-)

> Also note that there was somewhat of a flamewar between its authors
> on the one hand and Felipe on the other hand on the git mailing list.
> I don't want to take sides on that issue, but in my eyes, neither
> party looked exactly good. I especially disliked how both sides
> boasted how good and superior their solution was over the other's,
> when in fact I was aware of several (IMHO) severe shortcomings in
> both... I think some modesty goes a long way towards attracting
> "competing" implementors to work together. Which is also why I still
> think we should tone down the README a bit, changing "This is the
> most robust and usable git to hg bridge currently available" to, say
> "This is the most robust and usable git to hg bridge currently known
> to us, and we work hard on improving that." or even weaker, lest the
> statement rubs somebody the wrong way. Besides, such a bold statement
> should be backed up by facts (a list of other implementations tested,
> and specific things were they fail that gitifyhg does better).
> Otherwise, it's best not to make such boasts in the first place... We
> do have our share of relatively basic workflows that do not yet work
> perfectly out of the box, too, after all :-).

Feel free to change it. I wasn't aware of msysgit's remote-hg at the
time. That line was inspired largely by Felipe's similar statement about
a project that did not work, and I knew my version was better. It's main
purpose was to attract early adopters who wanted to develop it, which we
have no.

I definitely prefer a conciliatory approach to any development. That
said, gitifyhg is the only tool I've found that actually works for *my*
workflow, which I think is one of the most commonly sought ones. Because
it appears to be no worse than equal to "competing" projects, and is
currently being actively developed, I hope to prove the boasts true soon!

> Regarding 3), I think we should actually consciously decide whether
> we want to perform this mapping at all, too. It causes for some nasty
> corner cases, and that the primary branch is named "master" is merely
> a convention in git, not mandatory (albeit a widely spread convention
> shared by 99.9% of all projects). I certainly do see points for
> establishing that mapping, too; just saying we should actively decide
> whether we want to perform it, and then document the decisions and
> our rationale.

The original rationale was that Felipe's code included the mapping,
although it was largely broken. After the effort I've put into making it
work, I think I would prefer to keep it. As with all abstractions, it is
certainly prone to leakage, but it's pretty tight overall. The
documentation should *definitely* be updated to mention it though.

Dusty