git-repo-sync
git-repo-sync copied to clipboard
Preventing push/pull from only side_b
Hello! First of all - I'd like to thank you for this useful tool. I appreciate it's usefulness.
I'm using it in one of my hobby projects already successfully, but I have encountered special use case, where I'm not sure if existing configuration can solve it. I suspect side_X_conventional_branches_prefix
could be a solution, but I'd like to ask for your opinion about it - if I understand it correctly. Here is the scenario:
RepoA - hosted in primary location as single source of truth. RepoB - sitting on "other side" - I would like to allow guys on other side to experiment with as many branches they want, but only some branches with known prefix are important to be stored securely also in hosted site.
I wish, that all branches from RepoA are pushed to RepoB during sync, but only prefixed branches are pushed from RepoB to RepoA.
Is this exactly what side_b_conventional_branches_prefix
is for or am I misunderstanding it?
Thank you for your answer!
Hello @davesade, thank you.
Let me summarize. 1. All branches from A-repo are forcibly pushed to B-repo. All changes to these branches in B-repo will be completely ignored. All changes to these branches in B-repo will be overwritten in case of changes in A. 2. Some branches from B-repo will be updated from A and B.
Is it correct?
Wait a sec. :) The previous was slightly incorrect in terms of Git. Let me rephrase it during some time.
The new version. 1. Some branches are synchronized between our A & B Git repositories. 2. All other branches from A-repo will be forcibly updated in B-repo to their states in A-repo.
Yes, I think you got it perfectly right in last comment above. That would be desired result for my project.
Sorry git-repo-sync doesn't has the option #"2". I'll propose a workaround in the ongoing post.
This is interesting. I thought about it some time ago. But I see that it requires some additional rethinking. For example, someone could say "I want option #"2", but I need it to be restricted for few Git-branches", etc.
And this is a piece of work as I'd like to implement it in a reliable way. Sorry, for now I say no go.
Workaround.
-
run git-repo-sync periodically. Better quite often. Let's say once in 2 or at least 15 minutes.
-
Tune git-repo-sync to work in the mode described in #"1" above. I.e.: "Some branches are synchronized between our A & B Git repositories."
-
After running of git-repo-sync you have to run some "force-updating" script that updates forcibly all branches from A side to B side. It is better to do not run this code if git-repo-sync returns errors.
There are a decent number of such the scripts in the Internet, I believe. I saw such the code for one-directional updating and it was quite compact.
Let me mention one thing for myself.
Previously, git-repo-sync was called convention-over-git. There is an idea that two Git-repositories lives independently. But starting from some point, if people follow some naming convention for Git-branches then these branches will be synchronized simlesly.
As I see it, life is more interesting than that simple idea.