Support safely (read-only) syncing .git directories
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 32/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- git
- Lĩnh vực
- desktop
Hướng nghiên cứu
Bắt đầu bằng việc đọc issue #130 và xem xét thiết lập phiên file-sync hiện có cùng UI của nó. Xác định cách cấu hình chế độ đồng bộ hóa và các thư mục bị bỏ qua, sau đó xác định định hướng hướng đến người dùng và tài liệu cần thiết cho việc đồng bộ hóa .git chỉ-đọc, bao gồm cách quá trình hoàn tất sẽ truyền đạt hướng đồng bộ hóa và các đánh đổi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Git was not developed with bi-directional file syncing of the metadata in mind - it doesn't expect anything other than the local git process to modify its contents, be it the git config folder or the index. As such, Coder Desktop doesn't sync .git directories.
This is also explained in the Mutagen documentation: https://mutagen.io/documentation/synchronization/version-control-systems/
However, it's not uncommon or unreasonable to want git available on both machines.
On the local machine, the git metadata is obviously required to use Git IDE integrations, but on the workspace it may be required in build scripts, such as to populate version strings from Git tags. Or, it may be the case that the workspace is the only machine authorised to push to the remote.
Whilst we can't include the .git directory in the bidirectional sync session, Mutagen supports the one-way-replica sync mode, where conflicts cannot happen, and changes made to one side immediately replace the contents on the other. We can use this to mitigate these issues, but not without a few caveats:
- The
.git/indexfile is going to be deleted and recreated on the side it is being synced to each time a git operation is performed. On repos with a large number of files, this will affect the performance of git commands, as it first has to recreate that index.- We can work around this by ignoring
.git/index, but this doesn't change the fact that the staged/unstaged files will never be synchronised on both sides. (Though what's staged/unstaged on the side being copied to is irrelevant, this may be confusing to see).
- We can work around this by ignoring
- Whilst the Git metadata on the side being synced to will be read-only, the behavior when attempting to make changes on that side is undefined. In my testing I found that git just errors when attempting to switch branch or make a commit, as the file IDs stored in the config don't match those in the
index. Whilst this appears consistent, we have no guarantees this is always the case. - The user still needs to be conscious about which side of the file sync the repository is cloned to. If they need to be able to push from the workspace, they need to clone on the workspace (or perform a one time cut & paste of
.git, which is fine), and vice versa.
There's two ways we can approach this:
- Add a file sync checkbox to additionally create this
one-way-replicasync of the.gitdirectory excluding theindexfile. - Support configuring both the sync mode, and ignored directories when creating sync sessions (#130), allowing users to manually setup this workflow.
Supporting one-way syncs via either approach will also require an update to the UI to indicate which way the sync is.
Regardless of the method, there's a lot we have to communicate to the user about what's going on. They need to be aware of the tradeoffs of this approach, and inform them how to best set up their workflow. With the first approach, we'll likely need to link to documentation, and with the second we'll need to direct the user to documentation to learn how to set up their file-sync.
Unfortunately, there's no approach here that 'just works', that doesn't require the user to be aware of what's going on. For that reason I think the second approach is preferable, as it requires the user to be explicit about how they set up their workflow.
Sibling issue of https://github.com/coder/coder-desktop-macos/issues/164
- Ngôn ngữ chính
- C#
- Star
- 29
- Fork
- 12
- Merge trung bình
- 4 giờ 15 phút
- Pull request đã merge (30 ngày)
- 2
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của coder/coder-desktop-windows
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
coder/coder-desktop-windows#166 ·
-
CoderVPN Unsigned Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
coder/coder-desktop-windows#179 · 3 bình luận ·
-
bug coder-desktop networking
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
coder/coder-desktop-windows#177 · 2 bình luận ·
-
bug coder-desktop
coder/coder-desktop-windows#171 · 1 bình luận · 1 người được giao ·
-
bug github-sync
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
coder/coder-desktop-windows#170 ·
Tất cả issue của coder/coder-desktop-windows
Issue tương tự
-
core dependencies
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 80/100
-
bug frontend good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Down / Waiting for removal
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100