[Documentation] Howto create a private fork that still tracks emacs.g?

[moesasji]

I like to keep my emacs-config in a private repository as it contains email signatures and the like. For that reason I was trying to fork emacs.g to a private fork that still follows upstream for the master and various branches. This to be able to keep my own config in a separate branch in my own fork that I can push to, while being able to pull from here.

Despite having tried various git clone --bare or git clone --mirror approaches I unfortunately can't seem to get this working at all.

I assume that I am not the only one that would want to use emacs.g in this way. Would it be possible to give some hints on how the average user would be able to use emacs.g this way for their private repositories?

[tarsius]

I am not sure what you are asking.

I was trying to fork emacs.g to a private fork

Github does not support creating private forks of public repositories I believe. So the first step is to create a new independent repository on Github.

Despite having tried various git clone --bare or git clone --mirror approaches I unfortunately can't seem to get this working at all.

But this sounds that creating a fork on Github is not what you are having issues with.

After creating the repository on Github do this:

git clone git@github.com:emacscollective/emacs.g.git
git remote add moesasji git@github.com:moesasji/emacs.g.git
git config remote.pushDefault moesasji
git push moesasji master

Then proceed with the initial setup as documented.

[moesasji]

Thanks for the quick response. The reason I asked is that I am at the moment just genuinely confused how to work with emacs.g in combination with wanting to use a private repo.

One of the reasons for this confusion might be that I made the mistake to go for the "importing repositories" link, see: https://github.com/new/import This did give me a copy (clone?) of the repository including all branches, but with that it was really not clear to me at all how to track your changes. After that I went in the rabbit-hole of looking for the wrong thing (git clone --bare or git clone --mirror).

Your approach (using remote.pushdefault not with a capital) seems to be the step that I was missing although that way I can not see the branches in the github GUI until I explicitly check those out first.

The key-question is probably whether it is worth having a clear set of instructions like your above code-steps on how to set up a private repo that can track changes in emacs.g

[tarsius]

One of the reasons for this confusion might be that I made the mistake to go for the "importing repositories" link, see: https://github.com/new/import This did give me a copy (clone?)

This created what is commonly known as a fork. I.e "a copy of a repository". Both the upstream repository and your fork are actual repositories, but they live on Github servers not your machine.

The tem clone commonly refers to a copy of a repository on a machine where you can directly interact with the repository, using your editor of choice and commands as git add.

The above process did involve such a clone, but in the last step it was removed. Also was a "bare clone"; a repository that did not contain a working tree. So you would not have been able to easily edit files and create new commits using that clone.

The sole purpose of that clone was to create "Github fork" of a "Github upstream", something that should be possible without this intermediate copy, but for no good reason Github disallows the creation of private forks so you had to jump through those hoops. Think of it as a complicated way of clicking on "Fork" on the Github website.

---

(using remote.pushdefault not with a capital)

remote.pushDefault (or remote.PuShDeFaUlT for that matter) work too.

Your approach [...] seems to be the step that I was missing although that way I can not see the branches in the github GUI until I explicitly check those out first.

Why do you even want to look at branches using github GUI (which I assume is the github webpage)?

All of this making sure all the branches exist everywhere seems completely unnecessary to me.

(1) git clone git@github.com:emacscollective/emacs.g.git
(2) git remote add moesasji git@github.com:moesasji/emacs.g.git
(3) git config remote.pushDefault moesasji
(4) git push moesasji master

(1) alone gives you a local copy of all the branch already. They just live in the refs/remotes/origin/* namespace instead of in refs/heads/*. These are called remote tracking branches. You also got a "real local copy" of the master branch (i.e. refs/heads/master). If and when you want to make changes to one of the other branches, then you can create your local copy using git checkout <branch>, which automatically creates refs/heads/<branch> from refs/remotes/origin/<branch> if necessary.

It seems that you additionally want to have a copy of every branch from emacscollective/emacs.g on moesasji/emacs.g. I see no need for that, but downsides. These copies will quickly be outdated and keeping them up-to-date will be complicated. (But if you insist on having a copy, then the instructions you linked to are the way to go.)

I would recommend that you only push branches to your fork that you yourself have actually created new commits on.

---

This is all just generic Git stuff, advanced Git stuff maybe, but generic never-the-less. I do not think this should be documented here and if you struggle with these things, then maybe you are not ready to use borg and emacs.g yet.

[moesasji]

The confusion indeed results from not being able to use the forking through the Github GUI as allowed when both repos are public. If you consider this something that users of emacs.g should be able to figure out that is perfectly OK, so request closed.