github/atom
1
1
Fork 0
mirror of https://github.com/atom/atom.git synced 2026-04-06 03:02:13 -04:00
Code Issues Packages Projects Releases Wiki Activity

Add current decision to question about using git subtree in migrations

Browse Source
This commit is contained in:
David Wilson
2018-07-19 15:34:58 -07:00
parent 0006249c88
commit c40af11733
1 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/rfcs/003-consolidate-core-packages.md
View File

@@ -241,12 +241,14 @@ One alternative approach would be to break this core Atom functionality out of p
One concern here is that there exist projects which depend directly on these repositories for the TextMate syntax grammars they contain. Moving the code into `atom/atom` would require that we notify the consumers of the grammars so that they can redirect their requests to the `atom/atom` repo.
- Should we use `git subtree` to migrate the entire commit history of these packages over or just depend on the history from a package's original repository?
For now, we won't use `git subtree` due to the possibility that bringing over thousands of commits could cause unknown problems in the Atom repo. We may try this for newly consolidated packages in the future if we decide that not having the package commit history is a sufficient impediment to problem investigations.
- What are the criteria we might use to eventually decide to move larger packages like `tree-view`, `settings-view`, and `find-and-replace` back into `atom/atom`?
- Will we be losing any useful data about these packages if we don't have standalone repositories anymore?
- Should we use `git subtree` to migrate the entire commit history of these packages over or just depend on the history from a package's original repository?
- Should we use this as an opportunity to remove any unnecessary packages from the core Atom distribution?
[about]: https://github.com/atom/about