Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am thinking on creating a Mercurial repository under a Git repository. e.g.

..../git-repository/directory/hg-repo/

The 2 repositories

Is it possible to manage (keeping your sanity)? How similiar is it to this?


I am a computer science student at University. I manage my work in Git, mainly as a distribution mechanism (after realizing that rsync fails when you have changes in more than one place) between my desktop and usb drive. I try use of Git as a VCS as I do work.

I have finished a semester where I did a small group project to prepare for a larger group project next year. We had to use Subversion, and experienced the joys of a centralised VCS (including downtime).

I tried to keep the subversion repository separate to my Git repository for the subject**, however it was annoying that it was seperate (not in the place where I store assignments). I therefore moved to using an Subversion repository inside my Git repository.

As I think ahead (maybe I am thinking too far ahead) I realise that I will have to try and convince people to use a DVCS and Mercurial will probably be the one that is preferred (Windows and Mac GUI support, closer to Subversion).

Having done some research into the whole Git vs Mercurial debate (however not used Mercurial at all) I still prefer Git.

Can I have a Mercurial repository inside a Git one without going mad (or it ruining something)? Or is it something that I should not consider at all?

(Or is it a bad question that should be deleted?)

** I think outside of Australia it is called a course

share|improve this question
1  
It sounds like you'd just be causing a lot more work for yourself by doing this. Keeping track of stuff in one source control system is enough overhead, why add another? –  Colen Nov 2 '11 at 0:02
3  
There is only one sane way to do it: You should move both repositories into a CVS repository... –  Yannis Rizos Nov 2 '11 at 0:51
    
Considered just putting all your various repositories in the location where you store assignments? –  user1249 Nov 2 '11 at 13:24
1  
possible duplicate of Having a Git repo and mercurial in the same directory –  JasonTrue Dec 2 '11 at 20:20
    
"We need to go deeper" –  Kemoda Sep 2 '13 at 12:25
add comment

4 Answers

For file transfer/synchronization/distribution, you might want to try Unison instead of git.

Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs:

  • Unison runs on both Windows and many flavors of Unix (Solaris, Linux, OS X, etc.) systems. Moreover, Unison works across platforms, allowing you to synchronize a Windows laptop with a Unix server, for example.
  • Unlike simple mirroring or backup utilities, Unison can deal with updates to both replicas of a distributed directory structure. Updates that do not conflict are propagated automatically. Conflicting updates are detected and displayed.
  • Unlike a distributed filesystem, Unison is a user-level program: there is no need to modify the kernel or to have superuser privileges on either host.
  • Unison works between any pair of machines connected to the internet, communicating over either a direct socket link or tunneling over an encrypted ssh connection. It is careful with network bandwidth, and runs well over slow links such as PPP connections. Transfers of small updates to large files are optimized using a compression protocol similar to rsync.
  • Unison is resilient to failure. It is careful to leave the replicas and its own private structures in a sensible state at all times, even in case of abnormal termination or communication failures.
  • Unison has a clear and precise specification.
  • Unison is free; full source code is available under the GNU Public License...
share|improve this answer
add comment

No need to maintain an hg repo under your git repo. When (if) the time comes to shift to hg, use hg's convert extension.

Implementation information can be found here: ConvertExtensionImplementation...

The Convert extension converts repositories from other SCMs (or even Mercurial itself) into Mercurial repositories, with options for filtering and renaming. It can also be used to filter Mercurial repositories to get subsets of an existing one.

The current release supports the following repository types as sources:

  • CVS
  • Subversion
  • Git
  • Darcs
  • Monotone
  • Bazaar
  • GNU Arch
  • Mercurial
  • Perforce...
share|improve this answer
add comment

Take a look at the hg-git extension for Mercurial, http://hg-git.github.com/. It allows you to access a Git repository (including pulling, pushing, and committing) using Mercurial. I use it to manage my projects on Github using TortoiseHg on Windows. Haven't had a problem with this approach yet.

share|improve this answer
add comment

I've done similar things when transitioning projects. I wouldn't particularly recommend it -- there is just always a landline to step on and it definitely takes some options off the table. I would just use hg for the project and transfer the final bit into git when it is done.

On the technical side make sure you ignore the .hg folder and other hg artifacts. That at least gives you a fighting chance.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.