Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
3f89b6bd3f
5 changed files with 58 additions and 0 deletions
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="CandyAngel"
|
||||
avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
|
||||
subject="comment 6"
|
||||
date="2019-10-22T08:18:31Z"
|
||||
content="""
|
||||
> unwarranted and unhelpful to drag discussion of it into a question like this
|
||||
|
||||
*..what?*
|
||||
|
||||
This sort of question is *exactly the right place* to warn a user the thing they are asking about is an *irreversible change* that fundamentally changes how their annexes will work when interacted with, even when not using `git-annex` commands.
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="locking files before reverting to v5"
|
||||
date="2019-10-22T18:25:11Z"
|
||||
content="""
|
||||
\"It is entirely reversable by undoing the git config changes\" -- just to note, before undoing the git config changes, you'd want to [[lock|git-annex-lock]] any unlocked files (after first committing any pending changes to them).
|
||||
"""]]
|
|
@ -0,0 +1,20 @@
|
|||
[[!comment format=mdwn
|
||||
username="irieger"
|
||||
avatar="http://cdn.libravatar.org/avatar/83622f3c2fedea51e69f9a3986f95d73"
|
||||
subject="comment 3"
|
||||
date="2019-10-22T06:54:43Z"
|
||||
content="""
|
||||
Hey, thank you for those comments.
|
||||
|
||||
Tried your example joey and it seems to do exactly what I was thinking of. Now I have the roadmap I will adapt my tool to.
|
||||
|
||||
Just a few more small questions:
|
||||
|
||||
1.) How can I trigger the *(recording state in git...)* after throwing in files with *git -c annex.verify=false -c annex.alwayscommit=false annex setkey ...*?
|
||||
|
||||
2.) Can setkey be used on multiple repositories for the same file and then have the file exists in multiple copies after this without an *annex copy*? (Of course only one symlink generation and *git add*)
|
||||
|
||||
So thanks again for the fast replies.
|
||||
|
||||
-- Ingmar
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="leej"
|
||||
avatar="http://cdn.libravatar.org/avatar/eb1c6bd57680f694fb4658388e6de4ed"
|
||||
subject="+1 to the comments above"
|
||||
date="2019-10-22T07:21:31Z"
|
||||
content="""
|
||||
Git Annex has been and is a terrific tool. And, I would, very respectfully, like to +1 the comments above. I agree with spwhitton that v7 `git add` behavior would benefit from being off by default, with a way to turn it on as required. Both from a migration safety/friction-reduction standpoint, but also from the least invasive integration with Git principle that amindfv and others have so well articulated.
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="temporary manual downgrade of repos to v5 is possible"
|
||||
date="2019-10-22T16:40:32Z"
|
||||
content="""
|
||||
Related: until the v7 issues are resolved, one option is to manually [downgrade](https://git-annex.branchable.com/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/#comment-e1a252807a2200a7c737696abd08d38b) the repos to v5 (turns out it only involves changing a few git config and gitattributes settings) and use an [[pre-7.20190912|news/version_7.20190819]] git-annex version.
|
||||
|
||||
Just to reiterate, I much appreciate @joeyh's work on v7 and [[think|forum/lets_discuss_git_add_behavior/#comment-ffd69d3a710beeac091ef4173b122cdc]] it's an important advance. The v5 downgrade is just a temp option to keep old workflows working, until they can be adapted to v7, which won't be hard to do once the issues discussed above get addressed.
|
||||
"""]]
|
Loading…
Reference in a new issue