# Legacy experience and migration
This page is for projects that use the previous Git-based storage experience. If you are setting up a new project or have already migrated, see [Git repositories](working-with-repositories.md) for the current documentation. The following sections describe the previous force-push experience and steps to update your project.
## Legacy experience
### Source control and file storage (Legacy)
For projects requiring advanced version control, Amazon SageMaker Unified Studio allows you to connect your project to a Git repository where all project members can access, store, and collaborate on files. This option provides full version control capabilities including comprehensive commit history, branching, and merging.
When you choose Git-based storage, you need to specify a repository and branch during project creation. After the project is created, you can see the files that were created during repository bootstrapping directly from the project's home page.
**Important**
When you connect a project to a third-party Git repository, all users who can sign in to any domain in the account have read and write access to all repositories on that connection. This access is not limited to the project or domain where the connection was created. To enforce isolation between repositories, use separate AWS accounts. Do not store sensitive information in connected repositories unless all users in the account are authorized to access it.
With Git-based storage, you have access to full Git semantics regardless of whether you use space-based tools like JupyterLab or web-based tools like SQL Query Editor. This provides a consistent experience for team members accustomed to working with Git.
#### Key benefits of Git-based storage include:
+ Full version control with commit history, branching, and merging
+ Collaboration features like pull requests and code reviews
+ Cross-project sharing by allowing multiple projects to use the same repository
+ Integration with existing development workflows
### Performing Git operations (Legacy)
The JupyterLab IDE in Amazon SageMaker Unified Studio is configured with Git and initialized with the project repository when a project is created.
To access Git operations in the Amazon SageMaker Unified Studio management console, navigate to the Code page of your project, then choose the Git button in the JupyterLab IDE left panel.
This opens a panel where you can view commit history and perform Git operations. You can use this Git extension to commit and push files back to the project repository, switch your working branch or create a new one, and manage tags.
To fetch notebooks committed by other users, do a pull from the project repository.
**Note**
When you create and enable a connection for Git access and the user accesses this connection in the JupyterLab IDE in Amazon SageMaker Unified Studio, the repository is cloned. In other words, a local copy of the repository is created in the Amazon SageMaker Unified Studio project. If the administrator later disables or deletes this Git connection, the local repository remains in the user's IDE, but users can no longer push or pull files to or from it.
### Git operations in Code Editor (Legacy)
The Code Editor IDE in Amazon SageMaker Unified Studio is configured with Git and initialized with the project repository when a Code Editor space is created.
You can use Git operations after launching your Code Editor space. To launch your project, choose Open next to the space you want to open in the Spaces tab of your project.
When Code Editor is open, choose the Source Control icon in the left navigation. You can use this window to perform Git operations such as committing and pushing files back to the project repository, switching your working branch or creating a new one, and managing tags.
To fetch notebooks committed by other users, do a pull from the project repository.
**To pull changes in Code Editor**
1. Navigate to Amazon SageMaker Unified Studio using the URL from your admin and log in using your SSO or AWS credentials.
1. Navigate to your project.
1. In the **Build** menu, choose **Spaces**.
1. Choose **Open** next to the Code Editor space you want to open.
1. In the **Source Control** window of your Code Editor space, choose the three-dot menu. Then choose **Pull**.
**Note**
When you create and enable a connection for Git access and the user accesses this connection in the Code Editor IDE in Amazon SageMaker Unified Studio, the repository is cloned. In other words, a local copy of the repository is created in the Amazon SageMaker Unified Studio project. If the administrator later disables or deletes this Git connection, the local repository remains in the user's IDE, but users can no longer push or pull files to or from it.
### Managing storage resources (Legacy)
Creating logical subfolders helps organize your work, grouping related files together for easier navigation. Establishing and following consistent naming conventions for files and folders helps team members understand the purpose and content of resources.
Regularly moving completed work from local to shared storage ensures team access to important files. Removing unnecessary files periodically helps conserve storage space and maintain a clean, efficient working environment.
#### Working with files across multiple tools
Within Amazon SageMaker Unified Studio, a single file may be accessible via multiple tools. If you have the same file open simultaneously in different tools, changes made in one tool may overwrite changes made in another if not properly saved. You'll need to explicitly reopen files to see changes made through different tools.
When executing files from local storage, any resulting output files or artifacts automatically default to the same local storage location. For example, running a notebook that generates additional files will store these in local storage unless otherwise specified.
#### Transitioning between storage types
**Note**
This limitation no longer applies. Repositories are now additive and can be added to any project at any time without changing the existing S3 shared storage.
Currently, you cannot convert a project from S3 storage to Git-based storage or vice versa. If you need to change storage types, you must create a new project with the desired storage configuration, copy your files to the new project, and update any references or dependencies.
This limitation is important to consider when initially setting up your project, as the storage decision has long-term implications for your workflow.
### Limitations (Legacy)
+ For JupyterLab and Code Editor, large files over 15 MB cannot be directly uploaded to the shared folder. To upload large files, first upload them to any other folder (such as your local storage), then copy or move to the shared folder.
+ When uploading files using `putObject` API to non-existent folder paths in shared storage, folders created indirectly may display incorrect timestamps - January 1, 1970 in JupyterLab's file browser. In the CodeEditor, the file metadata also shows the time stamp as January 1, 1970.
## Migrating to the new repository experience
Migrating to the new repository experience requires a project update. The following sections outline how to update your project across all configuration scenarios.
The following table summarizes what changes when you migrate.
| Before (force-push) | After (repository tracking) |
| --- | --- |
| One repository per project, chosen at project creation | Multiple repositories, added to a project at any time |
| Every save in Query Editor, Visual ETL, and Workflows pushes directly to the remote | You choose when to commit and push |
| No branching from Query Editor, Visual ETL, or Workflows | Unlimited branches per repository |
| No commit messages from Query Editor, Visual ETL, or Workflows | Commit messages required on each push |
| Single collaboration model for all artifacts | Per-artifact choice to track in a repository or not |
| S3 shared storage OR Git repository (mutually exclusive) | S3 shared storage always active, repositories additive |
### S3-only projects (no Git connection)
No action is required. A Repositories page appears in the left navigation. If a Git connection has been configured by your administrator, you can add repositories at any time.
### Projects using the previous Git experience
These projects retain their previous behavior until you explicitly update them.
To update:
1. Open the Repositories page. A notification about the new experience is displayed.
1. Follow the guided steps to complete the update.
After the update completes:
+ S3 shared storage is added to the project.
+ The existing repository is cloned under the new model.
+ The repository experience activates.
If the clone fails (for example, because cross-account prerequisites are not met), the project remains in its previous mode until the repository is successfully cloned.
#### Cross-account considerations
If your project uses a cross-account configuration, your domain administrator must update RAM permissions before the migration clone can succeed. If the clone fails, contact your administrator to verify that the required permissions are in place.
#### If you choose not to update
The update is entirely opt-in. If you choose not to update, the previous behavior continues indefinitely. However, accepting any project update (whether service-initiated or admin-initiated) includes the Git transition. You cannot accept other updates selectively while excluding the repository experience change.
### Projects created from a legacy Git project profile
A legacy Git project profile is a project profile that was configured with a Git repository as its storage method. Projects created from such a profile remain in force-push mode (where every save pushes directly to the remote) until the user clones the configured repository from the Repositories page.