9

I'm working on a project which uses GIT as the main version control system for trunk, the official branches and most sub-projects/unofficial branches. As such, I want to make my own branch use GIT to allow the rest of the community to access my branch using the system they know.

However, I'm working on a part of the project which overlaps both official and unofficial branches, along with some patches which will never enter trunk - as such, I need to be able to keep my patches separate, allowing all to be used in my branch and selective patches to be taken for use in trunk. This naturally leans towards using mercurial queues.

Is there any reason that I can't use mercurial for my own local repository, but push the entirety to both GIT and Mercurial hosted repositories? Or rather, is there any good reason not to, I'm sure it's possible.

  • 2
    The only way I can see that working is if one is always the authorative copy and the other one is always generated from the first. This way there's no possible confusion. – Joachim Sauer Jul 31 '12 at 11:42
  • Thanks, that's what I was thinking - Git would just be a slave of Mercurial. Mercurial is used as normal for me, and then push from mercurial to Git to allow Git users to access my branch (without bells and whistles) – Jon Story Jul 31 '12 at 11:58
8

You shouldn't do this for the same reason you shouldn't have a variable which tries to track the state of another - you might lose track of which version is authoritative.

  • One would always be an authoritative copy - Mercurial, in this case, since it's the one I'm using myself to track changes, work with multiple patches etc. Git would just be a slave, a copy of the mercurial repository to allow members of the community who are familiar with Git but not Mercurial to get a copy of my branch. People who are interested in individual patches would have to use mercurial, obviously, but I'm trying to stay within the conventions of the project while making life easy for myself. – Jon Story Jul 31 '12 at 11:57
  • Thanks for the feedback. It wasn't entirely for this reason (I've also just decided I prefer GIT and can live without mercurial queues) but your answer made me realise redundancy is pointless if it can be avoided, which in this case it can. – Jon Story Nov 29 '12 at 16:43
2

I currently do this using git and svn. While there are reasons not to do it, there is no general rule. Git can do things svn cannot, I am used to those features so my workflow hence productivity increases when I can use git. Looking at the pros and cons in my situation, I would be stupid not to use both. You should look at your situation the same way. (btw the only cons for me are having to run a single tiny script to sync git with svn)

1

You can keep your patches separate in Git: do each one on its own branch, then merge them in selectively as desired.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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