2

I have a directory for my work files which is under version control (Mercurial):

~/myfiles

In a subpath, I have a directory with Emacs packages for my org-mode setup:

~/myfiles/org-mode

As I said, the whole path is under version control and therefore "synced" with a Hg repository. The original source for the org-mode subdirectory is also a (git) repository in the internet (http://orgmode.org/cgit.cgi/org-mode.git/ ).

So it would be nice to be able to pull new versions of this directory directly from the official org-mode repository and then commit them to my personal repository to always have the version that works with my Emacs configuration.

For a programmer, this might be a very easy question - as I'm not a programmer, I'm not sure how to handle that, but I assume it must be a common problem.

Sure I could save the org-mode directory locally in another path and keep it out of my version control, but then I would not be able to restore the full working setup at a certain point of time easily.

3 Answers3

1

Using both hg and git, in the same tree, carries no inherent conflict; as those programs were developed independently, it stands to reason that they don't interfere with one another.

However, and in this case, hg superimposes itself upon git (another way to see it is that the git repository depends on the underlying hg directory structure). As such, consider the following example, where you already have org-mode cloned and there is a patch waiting to be pulled from the online repository.

This is what hg may look like before you pull the changes from git:

c:\myfiles> hg log -l 1
changeset:   123:da5f372c3901
tag:         tip
user:        John Doe <john@doe.com>
date:        Fri Jun 13 12:00:00 2014 -0500
summary:     Some change in the work files

You then pull the changes to the org-mode from git. What matters here most, though, is that the pull action doesn't immediately reflect to the hg repository.

You can test whether the newer org-mode patches work. If they don't work right off the box, you should run hg revert --all, which will restore the way the repository looked like at the time of the latest commit. If they do work or you don't find any problems, you should commit a change under hg reflecting that you pulled a set of changes to the org-mode.

c:\myfiles> hg com -m "Pulling changes in org-mode"

c:\myfiles> hg log -l 1
changeset:   124:da5f372c3901
tag:         tip
user:        John Doe <john@doe.com>
date:        Fri Jun 13 12:01:00 2014 -0500
summary:     Pulling changes in org-mode

If git stores its metadata regarding the repository under the org-mode folder (i.e. as hg does with the .hg folder in the repository's root), there shouldn't be a problem with rolling back the commit under hg (if by any chance you, after commiting, find that there is a problem with org-mode):

c:\myfiles> hg rollback
rolling back last transaction

c:\myfiles> hg log -l 1
changeset:   123:da5f372c3901
tag:         tip
user:        John Doe <john@doe.com>
date:        Fri Jun 13 12:01:00 2014 -0500
summary:     Some change in the work files

Also, as stated on my comments, you can do this regardless of whatever VCS software you run. If you have:

c:\my_repo
c:\my_repo\2nd_repo

There wouldn't be a problem, as in order to work with each repository, you would have to work whilst inside the directory where you are working.

1 - I adapted some code from here because, as stated, I don't have much experience in the subject

1

Sounds like you want org-mode to be a subrepo. And it seems git is supported as a subrepo. The documentation is clear on what to do next:

echo "http://orgmode.org/cgit.cgi/org-mode.git" >> .hgsub
hg add .hgsub
git clone http://orgmode.org/cgit.cgi/org-mode.git org-mode

That'll let to track your stuff locally, and pull changes from orgmode when they are available.

0

Your code depends on a 'vendor branch'. Each have their repository. No problem. Most version control systems allow an 'export' of the latest code, that is without metadata. If you commit that into your own repository then there is no collision. It is unlikely that you need to commit to both repositories. But if you need to, you can probably work it out. Search term: 'vendor branch'

bbaassssiiee
  • 1,525