summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-05-31 17:08:22 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-05-31 17:08:22 -0400
commite3d29d2f17e8b651bf215de3461d5f5aa0fe6240 (patch)
tree65d75d061cc2cf1d8b689db4f6d8718e44eb00ec
parentb5fa37cb1b4b271f2b87f6fadfce2dcbfd989330 (diff)
parentc4fad2a207dd20fef17aec3e72d1865cdbfe69db (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Adding_metadata.mdwn18
-rw-r--r--doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn6
-rw-r--r--doc/git-annex-group.mdwn2
3 files changed, 25 insertions, 1 deletions
diff --git a/doc/bugs/Adding_metadata.mdwn b/doc/bugs/Adding_metadata.mdwn
new file mode 100644
index 000000000..1869baeb4
--- /dev/null
+++ b/doc/bugs/Adding_metadata.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+This is less of a bug and more of a feature(?) request. Currently, when assigning metadata to a datafile, git annex (v5.20150710-g8fd705) will produce no error or warning message if the file entered does not exist. This can be a tad confusing to users who might expect to see some output if they typed their path wrong. A successful `git annex metadata <filename> -s tags=best` will produce output acknowledging the change, but a failure produces no output at all. A quick check if the file exists, and a `File does not exist` error message if not, would be easy implement and helpful to new users.
+
+### What steps will reproduce the problem?
+
+git annex metadata <filename> -s tags+=atlas
+
+Where <filename> does not exist.
+
+### What version of git-annex are you using? On what operating system?
+
+v5.20150710-g8fd705
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+We use git-annex for our open-source !FreeSurfer software and find very helpful indeed. Thank you. https://surfer.nmr.mgh.harvard.edu/
+
+
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn
new file mode 100644
index 000000000..5c9b8f511
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn
@@ -0,0 +1,6 @@
+Hi,
+I'd like to know if there's an easy way to control how "git annex sync" resolves conflicts. I use git annex (with wrappers I have written) to manage repos full of debs. The debs themselves never conflict, but the metadata does. So far this works great if people check out the repo, add some debs in, regenerate the metadata from the debs (using external scripts), and then shove it back into the central repo. Many people can do this for our shared project.
+
+This doesn't work well if two people have the repo checked out at the same time; when they "git annex sync" to shove the data back up, annex detects the merge conflict in the metadata and renames the files.
+
+What I'd like is a flag saying that while pushing the changes upstream, the sync will only perform fast-forwards and fail if that doesn't work so my wrappers can abort the user's workflow. Any advice would be appreciated.
diff --git a/doc/git-annex-group.mdwn b/doc/git-annex-group.mdwn
index 3b6bac109..8a7455d82 100644
--- a/doc/git-annex-group.mdwn
+++ b/doc/git-annex-group.mdwn
@@ -4,7 +4,7 @@ git-annex group - add a repository to a group
# SYNOPSIS
-git annex group `repository groupname`
+git annex group `repository [groupname]`
# DESCRIPTION