e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
52 lines
1.5 KiB
Markdown
52 lines
1.5 KiB
Markdown
### Please describe the problem.
|
|
|
|
From the description of `sync` in the man page I assume it should be able to push all the branches it needs:
|
|
|
|
> The sync process involves first committing all local changes, then fetching and merging the `synced/master` and the `git-annex` branch from the remote repositories, and finally pushing the changes back to those branches on the remote repositories. You can use standard git commands to do each of those steps by hand, or if you don't want to worry about the details, you can use sync.
|
|
|
|
However this does not seem to be the case if one starts from an empty repository.
|
|
|
|
### What steps will reproduce the problem?
|
|
|
|
The following script (from <https://gist.github.com/gioele/d4e0905a3570f097fb0b>) will reproduce this problem:
|
|
|
|
#!/bin/sh -x
|
|
|
|
set -e ; set -u
|
|
export LC_ALL=C
|
|
|
|
d=$(pwd)
|
|
|
|
# cleanup
|
|
chmod a+rwx -R REPO pc1 || true
|
|
rm -Rf REPO pc1
|
|
|
|
# create central git repo
|
|
mkdir -p REPO/Docs.git
|
|
cd REPO/Docs.git
|
|
git init --bare
|
|
cd $d
|
|
|
|
# populate repo in PC1
|
|
mkdir -p pc1/Docs
|
|
cd pc1/Docs
|
|
echo AAA > fileA
|
|
echo BBB > fileB
|
|
|
|
git init
|
|
git remote add origin $d/REPO/Docs.git
|
|
git fetch --all
|
|
|
|
git annex init "pc1"
|
|
git annex add .
|
|
git annex sync
|
|
|
|
find $d/REPO/Docs.git/refs
|
|
|
|
# there should be some branches inside refs
|
|
|
|
### What version of git-annex are you using? On what operating system?
|
|
|
|
5.20140412ubuntu1 from Ubuntu 14.04.
|
|
|
|
> Documentation fixed, so provisionally [[done]] --[[Joey]]
|