Skip to content

Commit 1cb041f

Browse files
committed
Merge branch 'bc/doc-stash-import-export'
Update a FAQ entry on synching two separate repositories using the "git stash export/import" recently introduced. * bc/doc-stash-import-export: gitfaq: document using stash import/export to sync working tree
2 parents a7bbe90 + 02fc44a commit 1cb041f

1 file changed

Lines changed: 29 additions & 12 deletions

File tree

Documentation/gitfaq.adoc

Lines changed: 29 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -233,14 +233,30 @@ of refs, such that both sides end up with different commits on a branch that
233233
the other doesn't have. This can result in important objects becoming
234234
unreferenced 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

259276
Common Issues
260277
-------------

0 commit comments

Comments
 (0)