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.

Sign up for GitHub

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

Update README to suggest running a git fetch and branch cleanup #57

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update README to suggest running a git fetch and branch cleanup #57

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
81388bd
Update README to suggest running a git fetch and branch cleanup
C-Howard Aug 15, 2024
d19c6f1
Update fetch / merge notes to mention the default branch
C-Howard Aug 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 33 additions & 2 deletions Readme.org
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,12 +49,43 @@ Concrete example:
$ cat my-repos.txt | /path/to/tomono
#+end_src

That should be all ✅.

#+begin_comment
Yes #uselessuseofcat but it is clearer than < > ! # $) &&*!&♨±⌘︎ to newbies.
#+end_comment

You are also recommended to fetch all git remotes in new repository to update your local state.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I understand this part--the script just did a full fetch, there should be no new changes incoming after running the script. After a while, yes, but not after you just merged. Does this actually change something for you?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See

tomono/tomono

Line 64 in 4ca8975

git fetch --atomic "$reponame"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it I am also confused why this step seems to be required. It should have fetched all the objects for the origins as part of the merging process and in theory should be up to date. As part of my personal testing the origins have not actually changed during the merge process either. I can however confirm it is the most likely cause of issues such as #21. My best guess is that the git repo thinks it is out of sync with the remotes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also seems to be specific to using remote repositories, if you use full git paths instead of local paths you can replicate the issues trying to rebase merged branches. I believe it should be easy to replicate but I can attempt to make some reproduction steps as well.

Your repos list has to use the full git urls such as the usage example. It seems like there are subtle differences in behavior between what happens when you use the full url vs merge local repositories such as your test scripts.

$ cat my-repos.txt
[email protected]:mycompany/my-repo-abc.git  abc
[email protected]:mycompany/my-repo-def.git  def
[email protected]:mycompany/my-lib-uuu.git   uuu  lib/uuu
[email protected]:mycompany/my-lib-zzz.git   zzz  lib/zzz
https://gitee.com/shijie/zhongguo.git     中国

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, although I should say the integration tests do use local paths: https://tomono.0brg.net/#tests and those seem to reinforce the documented behavior. If there is a difference there that would definitely be a bug of course.

thanks for hanging in there :) I'm still trying to reproduce the exact issue

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the record: are we talking about first doing a local checkout of a remote branch, and then using that as the remote for the actual tomono action? Because that is unsupported, and it would definitely explain the discrepancy. You wouldn't be the first person to bring that up so it's worth me adding a warning about this to the docs, regardless.

Copy link
Author

@C-Howard C-Howard Dec 30, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay in response. I am running it similarly to the examples to avoid needing a local clone of the repository. I don't have a good set of example repositories to test with currently but Ill try to see if I can track a few down. The text file I use is something along the lines of:

[email protected]:org/common-package.git Common
[email protected]:org/sdkA.git SdkA Sdk/A
[email protected]:org/sdkb.git SdkB Sdk/B

So I always pull the full repository every run. From what I know about Git I can't think of why this would be an issue when a fetch is part of the script. I just know that in my testing with several very merge heavy repositories it seems like Git is convinced it is missing some history after a merge.


If you used the default settings the folder will be named =core= otherwise it will be the value set for MONOREPO_NAME.

#+begin_src shell :exports code
$ cd core
$ git fetch --all
#+end_src

Fetching all remotes provides Git information required to merge or rebase branches if desired and ensures that when you try to pull in changes everything works as expected.

That should be all ✅.

** Handling Existing Branches

If you run the script with the full remote path you will notice the script pulled down several remote branches. As part of the merging process each remote's branches are fetched and attempted to be merged togther in the new repository.

This branch merging process specifically only occurs when merging in new repositories using the script and will not appear when pulling in changes from a remote.

However if you attempt to push these branches up to a Git host such a Github you will see the branches most likely will show several changes ahead and hundreds to thousands of commits behind depending on your repository size. This is expected and is simply due to the branch merging strategy.

To pull in changes from branches you have a few potential approaches:

1. [[** Pull in new changes from a remote instead][Merge branches upstream and merge the changes]]
This approach can be the easiest if you plan to gradually move to the monorepo. You can continue to make changes in the origin repository and treat the monorepo as a readonly copy until you wish to migrate if you wish.
You may wish to not push up the merged branches at all or delete remote branches from the monorepo that may have been pushed up as part of the merge.
2. Fetch origins and merge existing branches against the default branch
This approach is best when you have already pushed up branches that others may be working on. It will allow branches to be merged while having more branch commits.
3. Fetch origins and rebase existing branches against the default branch
This approach is best when you have branches that have not been pushed up. This approach will remove more commits but will rewrite history for others, please rebase responsibly.

The best approach to take depends on each project so there is no preferred approach. Please keep in mind that the more conflicting changes are made between the original repositories and the monorepo the messier it will be to clean up changes between the two.

** Custom name for monorepo directory

Don’t like =core=? Set a different name through an envvar before running the script:
Expand Down