This project is read-only.

Orchard's Source Moving To Git

Topics: Announcements
Aug 1, 2013 at 7:29 PM
Edited Aug 1, 2013 at 7:31 PM

Orchard's Source Moving To Git

By August 5, we’ll be moving the Orchard sources hosted on CodePlex from a Mercurial repository to a Git repository. This won’t impact or affect Orchard's users, but Orchard's contributors might need to act before this move.


All of the current forks on the CodePlex website relative to Orchard will be deleted as part of this move. If you have forked Orchard, and you need to keep that fork, you can clone the fork and keep it locally or you can find somewhere else to push it. Alternatively we are doing a backup of all of them as of today's state, which you can request later on if you were not able to clone it in time. We will keep this backup for a few months only.

Pull Requests

The Orchard team will decline all the currently active pull requests before we move to Git. The result of this action is that you will receive a notification, and will have to recreate it once we have completed the move. We will not be accepting any new pull requests until this move is complete. Please wait to initiate new pull requests until that time.

Commit History

Orchard's commit history will be preserved. Including branches. If you’ve contributed to Orchard, your contributions will still be included in the commit history.

CodePlex Project

All other areas of the Orchard CodePlex project (the URL, issues, discussions, etc.) will remain as they are.
Aug 3, 2013 at 1:45 PM
I'm wondering why / when was this decided?

We have trained people to use mercurial, we've setup our infrastructure and build system to be based on hq. All the time invested seems to be nuked now - without any obvious reason or benefit and with just 5 days of warning time

"Go directly to git; do not pass go, do not collect a ROI." :-(

It's probably just me, but from a community driven project I'd expected to see some discussion about the reason or benefits of such a change or at least some more time to prepare internal processes before such a major change in the infrastructure happens ...
Aug 3, 2013 at 2:28 PM
I just joined the project about three weeks ago, and I was overjoyed that it was on Mercurial. So I have to second IntranetFactory: why move? Code repository SaaS provider Beanstalk is also dumping its Hg repositories in favor of git, causing our company to move to another provider rather than give up our massive training investment.

I understand this is a CodePlex decision, and their connection with Microsoft (and Microsoft's embrace of Git over other DVCSs) has a lot to do with it. But still: was there any warning before two days ago?
Aug 3, 2013 at 4:39 PM
Hi All, the decision was made by the community months and months ago. We were meant to do it for 1.7 but focused on other things.

We discussed it many times on the community meetings that are online on the Youtube channel.

In terms of using GIT or mercurial, I loved Mercurial (still do) and when I started using GIT I got frustrated, but as they say practice makes perfect and now I can use both and actually prefer GIT, the branching strategy for me is a lot more fluid.

Also you guys dont need to move off of Mercurial at all!! you can still use Mercurial internally, and use hggit to pull the changes from the repo in to your stuff. Trust me guys, there are ways of making it all work. :)
Aug 3, 2013 at 5:31 PM
I've to admit that I didn't know hggit - thank you for mentioning this. So if it allows to pull the ongoing changes into an existing mercurial repo then I'm happy that we don't need to rework our infrastructure.

I'm probably old fashioned - but instead of having to watch hours of videos I'd like read the results somewhere. Maybe even better: I'd like to suggest to discuss pending decisions in a post here before the decisions are finally made ...
Aug 3, 2013 at 6:27 PM
Edited Aug 3, 2013 at 6:27 PM
Yeah give hggit a go. It can be tricky to setup, but that might have just been my machine!!!

As with all the community meetings a typed up meeting summary is always available on the site.
Aug 4, 2013 at 4:12 AM
Isn't it a way to have codeplex rep sync with git for some weeks ?
Aug 4, 2013 at 4:54 AM
If someone wants to maintain a hg version of the repo, I don't think anybody would see anything wrong with it, of course.
Aug 4, 2013 at 5:01 AM
I was thinking there was a way to have git automatically pushing to codeplex ?
Aug 4, 2013 at 5:03 AM
I don't understand.
Aug 4, 2013 at 5:26 AM
I see.
isn't it possible to have codeplex repo as a remote for master repo on git ?
Aug 4, 2013 at 5:41 AM
I think I should clear some confusion here: we are not moving to Github, we are staying on CodePlex, but switching from Mercurial source control to Git.
Aug 4, 2013 at 8:17 AM
I was totally confused, sorry for disturbing.
Now I don't understand the interest of this move, is it codeplex which incitates to this ?
Aug 4, 2013 at 8:36 AM
No, it's that we want to move to Git. No conspiracy here.
Aug 4, 2013 at 9:20 AM
Edited Aug 4, 2013 at 10:11 AM
So I agree with @InternetFactory remarks.

The tool to use now is ? hggit ???
A rapid googling gives me dozen of tools, from Atlassian/SourceTree, GitHub, SmartGit, GitExtensions for VS, TortoiseGIT, etc.
( )

which to choose when you have been using Turtoise for years without been accomodated to console interface commands ?
Aug 5, 2013 at 1:34 AM
SourceTree is not bad at all, ExtGit works fine too. The command-line is preferred by some.
Aug 5, 2013 at 6:35 AM
I personally use GitExtensions as it is very similar to TortoiseHg. The process is exactly the same as with hg, so moving from hg to git is really simple.
Aug 5, 2013 at 11:14 PM
This may be a silly question...if we have the latest source from 1.X locally from mercurial with local uncommitted changes. Can this local copy be changed to work with GIT after the server move has completed, or do I need to track all my local file changes, then get the latest from the new GIT repo then copy/replace modified files to the new GIT local copy?
Aug 5, 2013 at 11:38 PM
No, that's actually a great question. The way I manage my own projects is that I have a private repo for each, with two sources: CodePlex to get latest changes from the core team, and Bitbucket for the private repo. The way I'll manage the migration, I think, is that I'll move my private repo to git, first, after getting the latest from CodePlex merged. Then I should be able to start getting new core changes from CodePlex w/git pretty much the same way I was doing it with Mercurial.
Aug 5, 2013 at 11:44 PM
I see the git repo is already accessible, but there's no 1.7 branch or tag it seems. Is the master branch going to be the stable branch?
Aug 5, 2013 at 11:51 PM
You should probably wait a bit.
Aug 6, 2013 at 12:15 AM
It's available now. The master branch is the old default.
Aug 6, 2013 at 7:25 AM
Is there a way to transform our local hg repositories in git ?
Aug 6, 2013 at 9:21 AM
Did you try to clone, copy the git folder and files from your clone, merge?
Aug 6, 2013 at 7:50 PM
Thanks! I don't think we want to advertise installing a Ubuntu VM as the default way to migrate a repo, but for those of us who are running Linux, that may be helpful ;)
Aug 9, 2013 at 12:11 AM
Edited Aug 9, 2013 at 12:25 AM
We've installed the latest version of hg and hg-git. hg-git itself works - but when I try

hg --repository C:\Test1 pull --verbose git+

to update an existing hg repository hg crashes with "Unknown exception encountered".

I'm wondering if we are the only ones with a destroyed development workflow?

Did anybody get hggit to work? Are we using hg-git not correctly?
Aug 9, 2013 at 12:29 AM
I also received this same error and gave up
Aug 9, 2013 at 12:48 AM
We also tried:
  1. to clone the git repo: with hg clone git+
  2. to pull the changes into a new repo:
    hg init
    hg pull git+
Both worked (so I think hg-git itself works) - but in both cases

c:\new>hg log -r 0
changeset: 0:bdabe6b34969

returns the same changeset id - which is different from the one we have in all clones of the original repo: changeset: 0:685bb4c20807 So these repos also can't be used to pull changes into an existing repo as when trying we only get:

abort: repository is unrelated

(which is not surprising as the 0:changeset id is different)

We're running out of ideas how we can reconnect our infrastructure with the central repo. Are we missing anything obvious?

That's so frustrating :-( Having to fix something which wasn't broken, without knowing any reason why this change was made at all.

Didn't anybody think or care about these potential problems before?
Aug 9, 2013 at 1:02 AM
Sorry you're being frustrated. We do care, we thought about it, and provided the reasons why we wanted to move to git. This shouldn't have been a surprise. How about moving to Git, rather than try to maintain two different VCS?
Aug 9, 2013 at 1:12 AM
Edited Aug 9, 2013 at 1:25 AM
I didn't find any mentioning of the decision to move to git before the surprising announcement. Where should I've seen the decision? Would you mind to send me the link to the reasons for that move?

We've an ongoing project, with several repos in different development stages, in different locations, with 20+ sub repositories, with different access permissions and scripts automating the build process. We've developers we trained to use hg, but nearly nobody knows git.

Moving this all to git with just some days of warning is not what I understand when I read "won’t impact or affect Orchard's users" - this switch costs me thousands of dollars. I would call this a severe impact. I'd preferred to contribute developer time to the project (like getting the 4.5 migration done) - but know we can just run in circles :-(
Aug 9, 2013 at 1:28 AM
Edited Aug 9, 2013 at 1:30 AM
It was in the meeting notes and video for 7/30/2013, 7/9/2013, 6/25/2013, 1/8/2012 (those notes contain a summary of the pros and cons discussion that took place a year ago, and mentions "shortly after 1.7" as the time to do the migration). All those meeting notes and videos are available from the Orchard home page, every week.

One of my customers is in the same situation of having to move all their subrepositories to Git. It would be great if they could chime in and share their experience. I'll ask them.
Aug 9, 2013 at 1:44 AM
May I suggest to post the meeting notes also here - so that they are included in the email notifications in the future and giving users an option to contribute or provide feedback?

The only discussion I found is from 1/8/2012 (and no mentioning that it was a already a decision):

a. Github is very innovative
b. Could have the gallery depend on Git repos

I think b. can be ignored - as that would also work with hg.

So seriously the only real reason was - "Github is very innovative" !?

I assume it's to late to start a petition to revert this decision?
Aug 9, 2013 at 1:52 AM
We always took care about saying we are not moving to Github. Just Git. We did it for branching capabilities. As a matter of fact some users will migrate to Git and maybe to Github, and some appreciate it.

Now with git we are no more afraid of creating new feature/taks/issue branches, as they can be deleted. With mercurial we couldn't, and we had to see these old branches for ever. Contributors can also have only one fork and do all their contributions on separates branches, instead of creating a fork for each contribution.

Also, please note that you can still have your project on Mercurial, copy the Orchard source code drop, put it in a mercurial repository and you are good to go. I don't assume a lot of people are using the live 1.x branch changes and not use git.
Aug 9, 2013 at 2:02 AM
Sure, that's a good idea. In turn, I'll suggest subscribing to the RSS feed for the Orchard home page, which will give you some pointers to useful recent blog posts in addition to those notes.

The notes are not a transcript of everything that's said in the meeting. The other meetings I mentioned also discussed the issue in details.

I explicitly didn't want to justify again the decision in this thread, because it's been extensively discussed, voted and decided by the steering committee, and rehashing the discussion is not very productive. This thread should be about assisting you in achieving a successful migration, not about justifying the decision. But since you missed those discussions, I'm happy to answer your questions.

Yes, seriously, Git is evolving, especially when you compare it to Hg, as do the array of tooling revolving around it. The flipside is that Hg is slowly dying. It's a losing and increasingly irrelevant proposition. We don't want to be in the position of using a tool that has become obsolete and that fewer and fewer people know and use every day. Git has won, Hg has lost, it's plain to see throughout the industry. At least, that's been our assessment of the situation for more than a year.

Yes, it is too late, and if a vote was held today, rather than a petition, I'm not sure you'd like the results (the vote, of course, has already happened) but as has been mentioned before, if a group of people wants to maintain a Hg repository and keep it in sync with the Git repository, that's perfectly fine. We are not going to maintain such a repo ourselves however, because we don't have the resources for it.

I would help with hggit if I could but I don't have any expertise on it. I can share my experiences migrating my own repo if people are interested.
Aug 9, 2013 at 8:25 AM
We have a significant amount of developers, qa, release staff, with repos, high-traffic, and high-profile sites at Onestop. We have spent thousands of man hours managing our dozens of Orchard repos, forks, patches, and builds through Tortoise Hg with Bitbucket and Codeplex over the last 18 months.

This was not a surprise announcement. It was discussed significantly and the target time has always been after the release of 1.7. We're happy with this change. It's progress. Long term, I agree with Bertrand's sentiments that, simply, Hg is dying, and Git is evolving. So we bite the bullet now, suffer a little pain, and we have a DVCS that's going to scale with us over the next 2 to 5 to 10 years. I can't see us limping along on Hg anymore. We actually used to have everything in TFS, before we moved to Hg. It was a couple of days of disruption, but the payoff was great, and when we were done, we took to the streets and celebrated like it was Festivus.

We have some work to do porting our forks to Git as well. For now we'll use hggit and port changesets over manually. We're all happy to learn new tools and new skills at Onestop.

Myself and a few other developers on our project have been using SourceTree, which works pretty well with both Git and Hg repos.

Think of Git like an upgrade of an OS. You can stay on Windows XP / Windows Server 2003, which work just fine, but really, would you want to? We're all technologists here - latest and greatest is always better.
Aug 9, 2013 at 8:33 AM
Edited Aug 10, 2013 at 7:42 AM
I also would appreciate that the summary of each committee meeting supports annotations, posting here is a solution, it would be a positive point (even for a french guy :) ), I have not the opportunity to assist to live meetings which have a hard time constraint but regularly read the videos (accelerating some 'technical passages' on sharing screen)
I am a little disappointed that we had not moved to GitHub (my misunderstanding of Orchard english) I am getting day and day more used to, but understand the reasons why.

What may have been missed in this story is a published and official Orchard Roadmap (a real one with dates of events): Git, v4.5, RavenDB (:) ), looking in forums I realized that the v2 has been subject of announcements...more than one year ago.

Again let's mention that I am totally satisfied by committee action and skills (even if sometimes surprised) and puzzled about the fact that some Elements could go and manage something else inside the Big Company...I have been working years on risk manangement and business continuity...solid community tools and structures are very important for continuity, especially in software.

Today I will try migrate my Hg repos ???
Aug 9, 2013 at 11:17 AM
Edited Aug 9, 2013 at 11:17 AM
Starting with this week's meeting, the notes and the link to the recorded video will be added to this discussion.
Aug 9, 2013 at 1:16 PM
Edited Aug 9, 2013 at 1:17 PM
Very Bad Trip IV with Git extensions.
I created a local Git repo with an existing Hg repo: tried to fill the ignore file using general paths as /src/orchard.web/Modules/Mymodule/. but it doesn't work, I had to select each group of files to ignore. Then take 1 hour to index. Discovered it puts all this in Master
After I try to make a Pull from Orchard, 1.x merging in my Master and here it became strange:
  • I add to delete some files in lib ????
  • then it discovered that the end of file was not the same as in my previous file and it started Kdiff3 for each file from codeplex, asking to press enter on each...with message 'Normal merge conflict' hit enter....
I must have misbehaved and decided another strategy, clone Orchard the add my files.... and test a pull after... hope will succeed today ???
Aug 9, 2013 at 4:30 PM
Edited Aug 9, 2013 at 5:46 PM
I've been applying the second strategy, which is to copy my changes over a new clone, then pushing that to a new private repo. Worked fine.

Of course, I had to delete the .hg folders and .hg* files.

And it goes without saying... backup first!
Aug 9, 2013 at 4:59 PM
That's what I did too... took no time at all.
Aug 9, 2013 at 7:36 PM
This thread sent me down a rabbit-hole of arguments pro-Hg and pro-Git, and I think I see why Orchard switched to Git and why closed shops like ours will stick with Mercurial: open-source projects benefit from all Git's features and closed-shop developers benefit from the convenience of Mercurial.

As for why the OP generated all this controversy, my experience as a corporate stooge and consultant (stop throwing things) leads me to suggest that the steering committee might have considered over-communicating this particular decision. Switching to a new DVCS is a major change that affects everyone, something analogous to changing national currencies. It doesn't change the value or usefulness of anything, but it does impose significant costs on the community.

<trolling attitude="lighthearted">
To continue the analogy, for the benefit of the Git-is-10x-more-popular-than-Mercurial crowd: there are thirty times more people using euro than ever used drachmas, but was switching really the best choice for Greece?
Aug 9, 2013 at 7:38 PM
We have been talking about it for more than a year.
Aug 9, 2013 at 8:42 PM
Might be interesting to know what is your workflow for developing with Orchard:
  • Do you enlist to the source repository ?
  • Which branch ?
  • If 1.x, do you integrate ASAP ?
  • Do you make local changes and merge official ones ?
  • Do you have a local clone and share this clone between all developers ?
Aug 9, 2013 at 9:17 PM
@Sebastien: I've only just started digging into the project, but I plan to continually integrate the 1.x branch with private, local changes. I think it's going to take some time to learn the project well enough to make meaningful contributions. Generally, on projects like this, I pull the latest bits down before starting my own modifications, and keep pulling them at regular intervals.

@Bertrand, I understand from this thread that it's been talked about for more than a year, but when I enlisted in the Mercurial repo three weeks ago, there was nothing to indicate there or in any other obvious place that you'd soon be switching to Git. I'm not objecting to the switch; I'm merely saying that the communications around it weren't obvious to newcomers.

For example:

...would have been good places to post, in really big letters, "We're switching to Git soon, y'all."

(The "Contributing Patches" page still shows Mercurial, by the way.)

I can't speak for anyone else, but the apparent abruptness of the switch, and not the switch per se, has always been the issue for me.
Aug 10, 2013 at 6:22 AM
I agree in hindsight that we could have publicized this better, and I'm sorry for the inconvenience this is causing to some of you. We'll help you manage the transition as much as we can.
Aug 22, 2013 at 7:56 PM
We migrated 58 repos to Git this week. We used git-hg and it went quite well.

We wrote a PowerShell script to clone repos and add the repos as bookmarks to SourceTree. Devs ran it once on their local workstation.

We are officially off of Mercurial entirely.
Aug 22, 2013 at 8:42 PM
58, this is insane !!!!
Aug 23, 2013 at 5:36 AM
Reality can be.
Aug 23, 2013 at 7:30 PM
Brett, may I ask what the rationale behind the migration was? I mean what shortcomings of hg do you wanted to address by migrating to git?
Aug 27, 2013 at 8:35 PM
Well, the main reason to move to Git was to be in sync with the main Orchard project. The other reason is that Git has unquestionably become the "winning" DVCS in the market. Additionally, the branching is far superior. Finally, the tools being developed such as SourceTree seem to favor Git. We're happy to switch to it and take advantage of all the features. We're looking at GitFlow as a branching model as well.
Sep 18, 2013 at 1:11 PM
Edited Sep 18, 2013 at 1:12 PM
Does somebody could give me some indication on how to do a pull request using GitExtensions.
I clone successfully 1.x , have set my codeplex login name but as soon as I try to do a pull request I encounter a authentication failure, details here (sorry for double posting, but may be people here are more uptodate with codeplex Git ?)
Sep 18, 2013 at 5:10 PM
CSDANT, from what you showed here,
Are you trying to push your branch to the main orchard repo?, i believe you need special permissions for that (being a comitte member).
If you doing the above, you should fork, then clone the fork and push to the fork and make a pull request on codeplex ui.
By the way, i started using SourceTree and i´m very happy with it.
Sep 18, 2013 at 5:17 PM
nduarte wrote:
If you doing the above, you should fork, then clone the fork and push to the fork and make a pull request on codeplex ui.
Are you sure ??? It looks crazy, why not also going to mars ?
Sep 18, 2013 at 5:25 PM
I believe it has allways been like this, and its the correct way.
Contributions to orchard source (and almost every open source project) use the fork flow.
Imagine the chaos and risks inherent if every one could directly push code to the main repo, without any kind of supervision and aceptance from the community.
Sep 18, 2013 at 5:59 PM
Edited Sep 18, 2013 at 6:00 PM
Sure, I can imagine, but I was expecting the 'Request' part in 'Pull Request' was enough to allow a stack of push from codeplex registered users waiting validation by admins....

Sure I have more practiced since years VCSs in large projects than in 'Communities'.
I have totally misunderstood the various declarations of Sebastien and committee members about not forcing forks in Git, etc.
Sep 18, 2013 at 6:14 PM
If the process can be improved, I'm afraid it would have to be done by CodePlex and/or git. We're just users of the tools. There may be things we don't know, but it may be interesting to consult those guys.
Sep 18, 2013 at 6:18 PM
Anyway thanks for clarification, I am landing on earth now.