Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preventing push/pull from only side_b #14

Open
davesade opened this issue Feb 20, 2023 · 7 comments
Open

Preventing push/pull from only side_b #14

davesade opened this issue Feb 20, 2023 · 7 comments

Comments

@davesade
Copy link

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!

@it3xl
Copy link
Owner

it3xl commented Feb 21, 2023

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?

@it3xl
Copy link
Owner

it3xl commented Feb 21, 2023

Wait a sec. :)
The previous was slightly incorrect in terms of Git.
Let me rephrase it during some time.

@it3xl
Copy link
Owner

it3xl commented Feb 21, 2023

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.

@davesade
Copy link
Author

Yes, I think you got it perfectly right in last comment above. That would be desired result for my project.

@it3xl
Copy link
Owner

it3xl commented Mar 2, 2023

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.

@it3xl
Copy link
Owner

it3xl commented Mar 2, 2023

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.

@it3xl
Copy link
Owner

it3xl commented Mar 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants