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

Make the tool more flexible #42

Closed
wants to merge 41 commits into from
Closed

Conversation

woopla
Copy link

@woopla woopla commented Jun 4, 2022

I've added a few features to make tomono.sh more flexible:

  1. Ability to select the default branch name
  2. Support for commented-out lines in the input file
  3. Ability to use one of the repositories as the top-level (so it's path will not change once imported)

While I was editing the files I fixed a few whitespace and Shellcheck issues. It's still reporting a couple but I did not want to make more invasive changes :)

hraban and others added 30 commits January 11, 2016 20:35
Set to master and checkout working dir after run
* Support branch names that contain slashes

* Fix 'allow unrelated histories'
…n converting many projects into a mono repo takes a long time)
README: Explain parallel development and merging
Directly list branches from .git meta dir instead of using porcelain
commands. I would have preferred a plumbing command for this but I can't
find any.

Fixes hraban#11
Set monorepo name through envvar (default: "core")
This time I've really dunnit. This should really be it, finally. Finally
finally finally. No more madness with the branches.

Honestly though this was a regression and it might be time to add a
proper test suite :(

But that's for another time! #yolomerge.
Does what it says on the tin. Remote `foo` with tags `v1` and `v2` get
imported as tags `foo/v1` and `foo/v2`.
Add git version to requirements
@hraban
Copy link
Owner

hraban commented Jun 23, 2022

This PR got closed automatically as I pushed a rewrite to master with unrelated history.

I've added a few features to make tomono.sh more flexible:

1. Ability to select the default branch name

This is obsolete in the rewrite

2. Support for commented-out lines in the input file

Interesting, not sure if I'm super fussed about this since running a to-monorepo migration is not something I envisage people doing on the reg. The script is already quite hairy, I'm very keen to keep it as simple as possible. I'm inclined to think removing comments from stdin is something people can do themselves, if they really need it.

3. Ability to use one of the repositories as the top-level (so it's path will not change once imported)

This is really nice, but unfortunately not compatible with the new rewrite. And I don't know how I'd make that work with read-tree :/ I struggled for a bit but I'm not good enough with git to tackle this. I'll definitely keep it in mind though, if I ever come up with a solution I'll make sure to revisit!

While I was editing the files I fixed a few whitespace and Shellcheck issues. It's still reporting a couple but I did not want to make more invasive changes :)

Thanks, good instincts ;) it would've been obsolete.

For posterity's sake, the old PR diff is here: v1...woopla:more-flexibility

@hraban
Copy link
Owner

hraban commented Jun 24, 2022

3. Ability to use one of the repositories as the top-level (so it's path will not change once imported)

This is really nice, but unfortunately not compatible with the new rewrite. And I don't know how I'd make that work with read-tree :/ I struggled for a bit but I'm not good enough with git to tackle this. I'll definitely keep it in mind though, if I ever come up with a solution I'll make sure to revisit!

I found a way to do this! Ironically, that made me wonder: why not use that existing repo as the monorepo, and use --continue on that? Since it is, by default, already the top level repo then. Wouldn't that be a more elegant solution?

@woopla
Copy link
Author

woopla commented Jun 24, 2022

Yes that would be more elegant indeed! I went for "the shortest path to getting this working" rather than the "best long-term idea" on this one I'm afraid :p

@hraban
Copy link
Owner

hraban commented Jun 24, 2022

I can relate :) Thanks again for your contributions, I'll leave it at that then. All the best!

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

Successfully merging this pull request may close these issues.

8 participants