@@ -233,14 +233,30 @@ of refs, such that both sides end up with different commits on a branch that
233233the other doesn't have. This can result in important objects becoming
234234unreferenced and possibly pruned by `git gc` , causing data loss.
235235+
236- Therefore, it's better to push your work to either the other system or a central
237- server using the normal push and pull mechanism. However, this doesn't always
238- preserve important data, like stashes, so some people prefer to share a working
239- tree across systems.
240- +
241- If you do this, the recommended approach is to use `rsync -a --delete-after`
242- (ideally with an encrypted connection such as with `ssh` ) on the root of
243- repository. You should ensure several things when you do this:
236+ Therefore, it's better to push your work to either the other system or a
237+ central server using the normal push and pull mechanism. In Git 2.51, Git
238+ learned to import and export stashes, so it's possible to synchronize the state
239+ of the working tree by stashing it with `git stash` , then exporting either all
240+ stashes with `git stash export --to-ref refs/heads/stashes` (assuming you want
241+ to export to the `stashes` branch) or selecting stashes by adding their numbers
242+ to the end of that command. It's also possible to include untracked files by
243+ using the `--include-untracked` argument when stashing the data in the first
244+ place, but be careful not to do this if any of these contain sensitive
245+ information.
246+ +
247+ You can then push the `stashes` branch (or whatever branch you've exported to),
248+ fetch them to the local system (such as with `git fetch origin
249+ +stashes:stashes`), and import the stashes on the other system with ` git stash
250+ import stashes` (again, changing the name as necessary). Applying the changes
251+ to the working tree can be done with `git stash pop` or `git stash apply` .
252+ This is the approach that is most robust and most likely to avoid unintended
253+ problems.
254+ +
255+ Having said that, there are some cases where people nevertheless prefer to
256+ share a working tree across systems. If you do this, the recommended approach
257+ is to use `rsync -a --delete-after` (ideally with an encrypted connection such
258+ as with `ssh` ) on the root of repository. You should ensure several things
259+ when you do this:
244260+
245261* If you have additional worktrees or a separate Git directory, they must be
246262 synced at the same time as the main working tree and repository.
@@ -251,10 +267,11 @@ repository. You should ensure several things when you do this:
251267 any sort are taking place on it, including background operations like `git
252268 gc` and operations invoked by your editor).
253269+
254- Be aware that even with these recommendations, syncing in this way has some risk
255- since it bypasses Git's normal integrity checking for repositories, so having
256- backups is advised. You may also wish to do a `git fsck` to verify the
257- integrity of your data on the destination system after syncing.
270+ Be aware that even with these recommendations, syncing working trees in this
271+ way has some risk since it bypasses Git's normal integrity checking for
272+ repositories, so having backups is advised. You may also wish to do a `git
273+ fsck` to verify the integrity of your data on the destination system after
274+ syncing.
258275
259276Common Issues
260277-------------
0 commit comments