10

I'm currently working on a my own neuroimaging toolbox that runs under MATLAB / SPM8 and most program files in my repository are MATLAB *.m files. I have different feature branches and one analysis branch, that I use for ongoing analyses using the current version. At the same time I am developing the code in master and feature branches, that are then constantly merged to master branch.

Now the problem is that, the analyses I'm running in analysis branch do take a lot of time (even days), and during that time I'm not able to git checkout master or git checkout new-feature. This limits my productivity seriously.

So, as it's not possible to keep several branches open at the same time simultaneously, I'm thinking to move the analysis branch out of the development repository to its own repository. The question is, that if I git init a new repository based on the current analysis branch, is there a way to somehow git merge every now and then from current master branch (of the development repository) to be able to use newly developed code of my development repository in the new analysis repository?

nrz
  • 10,435
  • 4
  • 39
  • 71
  • 3
    Actually, you *can* keep several branches open at the same time simultaneously: [git working on two branches simultaneously](http://stackoverflow.com/questions/2048470/git-working-on-two-branches-simultaneously) – sleske Jun 29 '12 at 10:37

2 Answers2

9

If you git clone your existing repository into a new repository, you can then git push or git fetch from one to the other to match up the refs (branches) you've changed; no merges are involved. The contents of the repository will be automatically hard-linked to save disk space.

If you use the --mirror option to git clone and git push, you will omit having remote-tracking branches and just have the same branches in both, which is simpler and more symmetrical, but less of a conventional use of git. For maximal "follow the tutorials" simplicity, instead arrange a third "central" repository (which should be created --bare) which both of your working repositories are clones of.

No merges (other than "fast-forward merges" which aren't really merges, but replacing an old branch head with a newer descendant of it) should be required, because you are working on the same branches; you just have two copies of them. When your analysis is complete and you are able to update the analysis branch, just git merge --ff-only master while in analysis; you can do this in whichever repository is convenient, but don't forget to sync the changes back with a git push other-repository.

Another option (since Git version 2.5) is the git worktree command, which allows multiple independent working trees in which you can git checkout, etc., independently. The difference between this and the above option of making a clone is that here there is only one set of branches.

However (as of version 2.8) this is still considered an “experimental” feature, and I have not personally used it to comment on its reliability and usefulness.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108
  • This seems to be a good idea. If I `git clone` my repository (without `--mirror`, because I use Dropbox as a private remote-tracking repository, as explained [for example here](http://michael.otacoo.com/linux-2/setting-a-git-server-with-dropbox/)), can I still create new branches and sync them? If I create a new feature branch, should I create it with the same name in both my `original` repository and in the new `analysis` repository? Or is it enough to create it only in `original` repository if I always merge only `master` branch of the `original` repository to new `analysis` repository? – nrz May 19 '12 at 20:03
  • 1
    If the only thing you ever do to the `analysis` branch is merge from `master` to `analysis` then yes, that branch does not need to live anywhere but the analysis repository. In fact, it does not need to be a considered-separate branch: it is just the one and only branch in that repository, with `origin/master` as upstream. Every merge you do to it should be fast-forward. – Kevin Reid May 19 '12 at 20:58
  • Merging from old (development) repo (`origin/master`) to analysis repo: in the new `git clone`'d repository (without `--mirror` or any other special flags) `git merge master` (with or without `--ff-only` flag) fails: `fatal: 'master' does not point to a commit`, while `git merge --ff-only origin/master` gives `fatal: Not possible to fast-forward, aborting.` (I think `--ff-only` fails because the `analysis` branch also has it's own commits related to analysis parameters etc.), but anyway `git merge origin/master` works nicely, using 'recursive' strategy for merge. – nrz Jul 05 '12 at 06:21
2

As an alternative to cloning the repo as explained by Kevin Reid, you could also just use git-new-workdir to create a second working copy for your repo. That way, both working copies will always automatically see the same branches, because they share one git repo.

The advantage over cloning the repo is that there's no need for any manual synchronization/merging. The moment you commit in workdir A, the commit will be visible in workdir B (e.g. git log).

Only caveat: When you change the repository (commiting, rebasing, resetting a branch etc.), you should not have the same branch checked out in the other workdir - otherwise git will get a bit confused (see git-new-workdir: Commit in working tree A causes bogus changes in tree B ).

See: git working on two branches simultaneously

Community
  • 1
  • 1
sleske
  • 81,358
  • 34
  • 189
  • 227