Configure gccemacs and emacs - do I need two local git repos to accomplish this?

Viewed 83

Git newb. I find Git amazing, but I don't fully understand it.

I've cloned the GNU Emacs repository locally (git clone https://github.com/emacs-mirror/emacs.git ~/src/emacs)

I see it has two branches - master and feature/native-comp.

I'm trying to build both the master branch (git checkout master && autogen.sh && make)

as well as the native-comp branch (git checkout feature/native-comp && autogen.sh && make)

Does git keep the compiled objects separated via the two branches - or - do I have to clone the emacs source code to two unique directories on my local system?

1 Answers

do I have to clone the emacs source code to two unique directories on my local system?

No, but you do need—or at least want—two working trees or work-trees (I like to use the shorter name, most Git documentation mostly uses the longer two-word non-hyphenated form).

Two clones will give you two working trees, so you can do it that way. Another way is to use git worktree add, provided you have Git 2.5 or later (preferably 2.15 or later).

Does git keep the compiled objects separated via the two branches ...

No. In particular, the files you're working with—both the ones extracted from some commit, via git checkout or git switch, and the ones created by your build process—live outside the Git repository proper. They are in your working tree or work-tree (two ways to say the same thing). These files are not actually in Git itself at all.

When you use git checkout or git switch to pick some commit, Git will:

  • make sure that the next few steps are OK; then
  • remove from your work-tree the files that went with the commit you checked out earlier, if any; and
  • add to your work-tree the files that go with the commit you're checking out now.

This remove-and-add is OK as long as you don't have unsaved work in the various files that Git will overwrite or remove, in the process.

Note that build products from some other, earlier checkout are simply untracked files: files that you, or some program you ran, put in your work-tree (it's yours, so you can put anything you like in it), that Git doesn't know anything about. They did not come out of some commit, and if you switch away from this commit to some other commit, they don't have to be removed,1 so they won't be.

If you want to work on/with two different commits "simultaneously", you need two different work-areas in which to work with the files extracted from those two different commits. Since one repository comes with one initial working tree (and one index aka staging area aka cache), you either need two repositories, or the git worktree add code that first showed up in Git 2.5. Using git worktree add, you can add a second index-and-work-tree pair, with a second HEAD that goes with it, and use that to check out some second commit.

There were a few nasty bugs in this that were not fixed until Git 2.15. If you're just going to take a quick look at some commit, the bugs won't bite. They bite when you make an added work-tree and do some work in it and let it sit around for two weeks or more. (I had this happen to me. Luckily I was actually done with the added work-tree, and was able to just remove it.)


1Note that there is an exception to this rule. Suppose you're on some commit c123456 or whatever. This commit does not have a file named README.md in it. You create your own README.md, so now it's untracked. Then you decide you'd like to check out commit fedcba9, or whatever, but that commit does have a README.md file. Git will complain that it will have to overwrite your untracked README.md file in your work-tree, in order to extract commit fedcba9.

Related