Please describe the problem.
After upgrading to git-annex 10.20230626, running git annex sync reports:
git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
which appears to be a barely documented change plan (at least I cannot find it in the git-annex dev blog, only in the latest change log).
From the little that is said in the 10.20230626 changelog, it appears the intention is to -- after 10 years -- fairly quickly switch from git annex sync just syncing metadata (allowing git annexes to easily hold partial subsets of content), to doing a full content sync bidirectionally (apparently not allowing git annexes to hold partial subsets of content without explicit countermeasures for this behaviour breaking change).
I can understand why users might want a git annex sync that syncs content. And even maybe why it might want to be the default for those users who expect, eg, "Dropbox like behaviour".
But changing the git annex sync default after 10 years seems extremely user hostile.
Especially so when changing it from something that does not copy much data (default git annex sync --no-content) to something which (a) potentially copies a lot of data (over what might be a slow/expensive link), and (b) will potentially fill up drives due to repopulating entire large annexes which have historically relied on having only a subset of the content available locally, if the change in behaviour (after 10 years) is not caught in time.
The idea that users should go around every single git annex (I have dozens, with copies of those on dozens of machines and a bunch of offline drives), and make sure each one has annex.synccontent set, or every script that runs git annex sync has git annex sync --no-content on it, just to restore the default of 10 years is a pretty rough transition, and not a great user experience.
I would really strongly suggest that you do not change the behaviour of sync in this way after 10 years. And if you want a full sync option for user friendliness, then create, eg, git annex fullsync which is an alias for git annex sync --content.
If you no longer want to support the user model of having "incomplete annexes" (ie, all copies of a git annex must contain local copies of all data except changes made since the last sync), then the deprecation should be explicitly documented with advanced warning.
At minimum this signficant behaviour breaking change needs to be communicated way better than a random change log entry, and suddenly appearing in git annex output as a warning the world is going to break. And it shouldn't be necessary to, eg, trawl through the git source history to try to find any context for a major planned change.
Some slight saving graces:
Fortunately
git annex sync --no-contentseems to be accepted at least back to git-annex 6.x, so at least it can be added into scripts without having to also check which git annex version is running; it's just a "no op" option in everything prior to git-annex 10.20030626.It looks like
git annex config --set annex.synccontent falsemight be carried with the repository (across syncs), reducing the number of places the new "override, back to the old default behaviour" setting has to be set (but it has to be set on every existing and new git annex, just to restore the 10 year historical behaviour)The git annex source commit has a tiny bit more context about there needing to be a "Debian Stable release" before the default changes, which doesn't seem to be documented anywhere else; if true, then since Debian Bookworm just released, with git-annex 10.20230126 then the change in behaviour is at least 2-3 years away, at Debian's normal stable release schedule. But this doesn't seem to be documented anywhere else.
If the plan is that this change in default behaviour will be, eg, in 2H 2025, then I'd suggest (a) putting that planned date in the warning being issued on every run, and (b) putting that date in the documentation for git annex sync which currently just says "will change in a future version of git-annex" (which is very vague, and could be next month or a decade away). However as stated above, I'd really really strongly suggest just creating a new command, like fullsync for the new default behaviour, and not breaking backwards compatibility in behaviour.
What steps will reproduce the problem?
Upgrade to git-annex 10.20230626, run git annex sync in a git annex repository, without having set annex.synccontent (i the git-annex config, or the git config).
Try to find documentation on this pending change; find nothing other than the changelog note foreshadowing a major change in behaviour after 10 years, and some comments in the source code.
What version of git-annex are you using? On what operating system?
git-annex 10.20230626, on macOS, installed from Home Brew.
ewen@basadi:~$ git annex version
git-annex version: 10.20230626
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
dependency versions: aws-0.24.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.4 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: darwin x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
ewen@basadi:~$
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)
Absolutely. I've been using git-annex since nearly the beginning; and use it extensively to maintain partial copies of large annexes on laptops/desktops (and other space constrained systems). Hence this foreshadowed sudden change in behaviour being extremely surprising, and somewhat alarming.
Thanks for writing git-annex. It's the reason I've been sponsoring you on Patreon for years.
Please don't break backwards compatibility. Even in the user experience 
Simultaneously, a new command
git annex assisthas been added that does basically a single step of the assistant, so roughlygit annex add;git add -A;git annex sync --content. That goes into the direction of yourfullsyncsuggestion.You can read more about the reasoning for
git annex syncsyncing content by default here, where I suggested to add a config togit annex syncthat would optionally add new files as well. That turned out to launch an avalanche of new commands and changes (git annex pull, git annex push, git annex assist, sync syncing conent, etc.). 😅IIUC, Joeys reasoning is that
git annex syncwas incomplete/inconsistent from the start and did too many configurable things.git annex assistsyncs the entire repo state - as the assistant. Preferred content expressions can be used to specify what files a repo wants. If you set that togit annex wanted REPO present, a content sync won't affect it anyway. I still think that a configurable default preferred content expression for new repos is very important, now that syncinc content by default might get the default: https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/Frankly, as a fellow user of "incomplete annexes" I also find it rather jarring that having gotten used to git committing my own changes on the command line and not relying on mere
syncto do that (or the assistant -- I haven't found a use for the assistant yet) but then also preferring to use invocations ofgit annex sync --no-commit(which I've abbreviated togit annex-syncby way of a git alias) rather freely to record my git-level changes across remotes, I would from here on out be forced to add the-gflag to all my invocations just to make sure that I don't get an annoying warning or my then current repo doesn't cause possibly huge content to flow across the remotes because I haven't remembered to setannex.synccontentappropriately. I know the ideal is to have preferred content settings for all annexes but not every git-annex user have an innate sense of all the intricacies involved in doing that and for them to be forced to do so is a bit too much, in my humble opinion.@Joey, I have a suggestion: instead of breaking the UX of
sync, why not do that on a lesser used commandmirrorand change it to sync git-level data in addition to files (ie. I suggest thatmirrorcould be a better/shorter name for OP'sfullsync). Then add a flag called--only-contenttomirrorto restore its old behavior. I bet that would have a smaller impact on git-annex's users than making us count our blessings with-gs and all.That's not a reason to break backwards compatibility for such a prominent command as
sync. Just no.I don't want to use the assistant -- or it's CLI alter ego assist -- I want my own manicured commit messages, puh-lease! The assistant is a whole another use case, just not mine at the moment.
Just give us our old
syncback. Rename it tosynk(or,sc/sk-- as in "sync for [k]urmudgeons") if you want but let us have it.Just for the record:
git annex assist -m MESSAGEworks, you can make own messages.git annex assisthas nothing to do with the assistant and can be used without. It's justgit annex sync --contentplus adding new files. A very important command for newcomers to 'just sync it'.To get 'the old sync' back, you have several options:
git config --global annex.synccontent falsefor your entire local machine, overrides the next optiongit annex config --set annex.synccontent falsefor all participants of a git annex repo (yes, it syncs between machines), still overrideable by users' local git configs abovegit annex wanted . present.git annex sync --no-contentIf you don't use preferred content expressions to decide which repo should get which files and you want only partial checkouts with some files, then I indeed don't see why you would ever need
git annex sync --contentas you probably manuallygetthe files you want. In that case one could argue thatsyncis a misleading word, you are actually only looking for a metadata sync (msync,metasync, ...?) strictly without content.I was also surprised that joey opted for introducing
assistinstead of teachingsynchow to (optionally) add new files as well and keeping the rest as it was. But I can understand the direction of his reasoning.Thanks for the pointer to the earlier bug discussing changing sync entirely @nobodyinperson; it's at least useful to have a reference for where all this breaking change suddenly came from given it's otherwise undocumented. I've added a back pointer comment to that bug pointing at this one, as they're clearly related discussion (and it wasn't obvious the other "sync" bug was at all related to the change).
I still strongly disagree with changing "sync" to do something pretty different from what it's done for 10 years being a good idea. But would certainly support there being another command that did a "Dropbox like full sync".
(Personally I'd really really prefer that "sync" stayed doing the same thing it's done for a decade: meta data sync, only. If we're going to have to run a new different command just to retain core "meta data sync" behaviour, I guess "git annex sync --no-content" is not much worse than any other command we'd have to remember to suddenly use instead starting version N + 1.)
Ewen
To echo @jkniiv's "preferred content settings for all annexes", as a git annex user for at least 8 years (the annex I found this issue in dates back to 2015), I've still never figured out how "preferred content settings" are supposed to help in git annex -- let alone for my use cases.
As an example, the git annex I spotted this new warning in is one I use for downloading/collecting podcasts. The downloads happen on my desktop, or sometimes a laptop. All content gets pushed to two of my NASes as soon as possible (for an "archival copy" -- immediately after download if I'm at home), and then once I've listened to the podcast I drop it from my desktop/laptop, so it's gone from the "to listen" queue (and historically, to recover space on smaller laptop drives). I don't want the files suddenly appearing again, unless I need to refer to it for some reason, then I do "git annex get ...".
There's around 300GB of podcasts in the annex (around 7000 files) on my NASes; but the checked out version on my desktop is 9GB (about 200 files). 300GB is more space than some of my laptop internal drives have in total; and definitely more free space than any of them had, which is one of the reasons for using git annex for this purpose.
The "preferred content policy" is "if I just downloaded it I want it until I drop it, then I don't want it unless I explicitly request it again, but the two NASes should always have copies". From setting git annex preferred content policy, and the preferred content policy syntax, AFAICT "present" is the closest thing to the "content policy" I want on my desktop/laptops, ie "trust the user, I know what I'm doing, don't automatically move files". But up to version "10.20230626 + N" that was also the default without a content policy, as file content didn't automagically move around unless some other policy was explicitly set.
Ewen
You might have missed it above, but
git annex assistis exactly that new command that does a 'Dropbox-like sync' (adding new files, adding changes, metadata sync, content sync) and as OP suggested withfullsync. It is there, it works, it's wonderful. I think we can put that part of the discussion to rest.Actually,
git annex syncisn't always just metadata sync. If you're in a repo where someone (anyone!) decided to rungit annex config --set annex.synccontent true, there flies your Terabytes of content around when you do yourgit annex sync, assuming it's metadata-only. At first I was a fan of teachinggit annex synceverything with flags and configs, but I think joey is right that this is inconsistent and leads to surprises.If we're at it, we could get rid of the ambiguous
synccommand altogether (this is what joey also proposed for the very long run) and introduce a metadata-only sync command (metasync?) that can't sync content. Not with a setting, not with a flag, it just can't. Then that's perfect for those who only want to sync metadata andgetfiles they want manually and without preferred content expressions (I suppose that's how you do it?).How about:
git annex assist(exists, works):git annex metasync(new proposal):git annex sync --no-contentthat can't ever sync content. No surprises through configs.git annex add|push|pull|etc..get|copy|move|...stuff manually and don't want to fiddle with preferred content expressionsgit annex syncwithout content syncing will eventually switch to this.git annex sync(exists, has many options and configs):Firstly, if
git annex assisthas been added to create the magical "Dropbox like experience", I don't see the need for changing the default behaviour ofgit annex syncat all. (For the record I'm gladgit annex assistexists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great. This is entirely about backwards incompatible UX changes in existing commands.)Secondly, your (@nobodyinperson) suggestion for "improving" the current situation seems to be:
git annex sync(entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); andgit annex metasyncwhich has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)Which, to me, is even more breaking the user experience of using
git annexfor the last 8 years, than is currently happening. AFAICT there would then be no way at all to get thegit annex"just sync metadata without other unwanted behaviour" that existed before. And it'd then require git annex version detection in scripts to tell ifgit annex metadata --no-add-really-just-copy-metadata-honestwas available or not, or if one had to fall back to an old version of the command, which is a really user-hostile way to "retain" existing behaviour. (FTR in my case at least there is zero chance thatgit annex syncwould suddenly encounterannex.synccontent=true, as it's just me, and I haven't set that; I don't need a "guarantees" it won't copy content option, except as a defense against the git annex defaults suddenly changing after 8 years.)My suggestion for preserving backwards compatibilty would be:
Move the behaviour change out of
git annex syncand intogit annex init(rationale: it's run once per annex/machine pair, not many times per day/week, and it makes the change "new annexes only" which is much closer to "opt in")From git annex version N + 1, have git annex automatically set
annex.synccontent=trueatgit annex initof a new repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) havegit annex initissue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is makingannex.synccontent=truethe user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).For any annex where
annex.synccontentis not set, assume it's an older annex, and use the backwards compatible, historical, default (false) without issuing any warnings about "this is going to change" (and never change that behaviour for historical annexes)Retain
git annex syncforever, with it obeyingannex.synccontent(default: false, but set to true in newly created annexes by default)Remove the newly added warning in
git annex syncentirely, and just keep the functionality of the version before 10.20230623This would:
Allow changing the
git annex syncdefault frommetadata onlytofull contentin a "new usage, opt in only" wayProvide a clear path to opt out, and a clear path to opt in existing repos to match
Avoid needing to issue warnings to users on every run of a very core command until they set config
Avoid breaking existing usage, and use cases
The git annex "meta data sync" dance (which effectively allows
git pushinto a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options. It'd be a shame to render that great functionality unreachable without unwanted "some users wanted this, so all users must have this" functionality.Ewen
PS:
git annex push/git annex pulldo not appear to be meta data only tools to replace sync; they appear to be very explicitly targetted at copying content, and to be one remote at at a time as well (where as sync is "all known remotes"). Historically it looks like my wrapper scripts usegit annex get ...to retrieve content, andgit annex copy --to=REMOTE ...to put content onto a specific remote (ie, aput, when there is noput).Fine with me to keep
git annex syncat its old behaviour. I'm happy aboutassist|push|pulland would also be happy with ametasync.These are all decisions that joey will have to decide himself. He has written this amazing piece of software that I'll be forever grateful for (Thanks joey!!). If he decides that
git annex syncsyncs content, so be it.Your idea with moving the content-syncing into
initsounds reasonable from a backwards-compatibility point of view. But I doubt joey will want to makeinit(or any other command) accumulate patchy stuff.@nobodyinperson, @ewen: Thank you for a balanced discussion! I'm not as elegant with words but here is my take on your ideas.
@nobodyinperson:
Yes, I understand the need for
assist-- not in any way opposed to it. However, I think bothassistandsyncought learn a new option called--edit(or,--edit-messagebut that's wordy) to be used in a similar fashion togit commit -m msg --edit, ie. it would open the user's preferred editor to edit the commit message.You mention that this command would be "Option-wise as 'dumb' as git annex assist" but I disagree: as a true replacement for
syncit definitely should have at least the--no-commitflag as an additional option so that those used to agit annex add; git commit -m foo [--edit]; git annex sync --no-content --no-commitworkflow could migrate to it. Also, no auto-adding (please!) if this is supposed be a replacement forsync --no-content.You mention that this command ought to be "deprecated eventually (in many years), with a big warning upon execution now already". Yes, I agree but only if we get a
metasyncwith a--no-commitflag for reasons above.@ewen:
I think you have a point there that the situation pre-10.20230626 would be preferable. But I can live with Yann's (@nobodyinperson) suggestions if there is some amount of compromising.
Yes, a replacement for
syncshould not in any case auto-add files. We want more control, not less.(continued...)
Please don't engage in unwarranted speculation about strange desires of mine to eliminate features that are crucial to git-annex. In general, avoid inflammatory language on this website. Thank you.
It's important that git-annex be able to make changes that make it better. Backwards compatability is not everything. Improvements can make git-annex more cohesive and easier to understand for new users. This kind of pre-warned transition is commonly used by git when making similarly impactful changes.
annex.synccontent can be set in your global git config. It can also be set with
git-annex configwhich will affect all clones of that repo. This will be a minor amount of work for most users to deal with.BTW, this transition plan actually started 6 years ago when I added annex.syncontent configuration and --no-content. b77903af48e650dbb777f29e98d0c7b388353ebd As you note, it's important that's already available in all commonly used old versions of git-annex.
(...continued)
@ewen:
Sounds good. I like the concept of an opt-in the way you laid it out. It's well thought out.
(Yes, that warning is annoying to say the least.)
I'm willing to accept some breakage to my workflows but I'd rather still see a separate
git annex add,git commit -m ...and "sync metadata with one command" workflow being supported. The name of that sync command is not that important for me but I understand why it is for you.I agree to the strongest degree. I'm not a very good git user, but the core parts of git-annex like
addandsynchave made me feel comfortable to a greater extent than the porcelain of core git. I'm sure I can adapt to newfangled ways of doing my routine things with git-annex but as on "old dog" I'd rather not adopt those new ways if I can avoid it.@joey (re comment 11): thank you for replying. I apologise if my tone sounded accusatory; in hindsight writing late at night after a stressful year probably wasn't the best idea.
I don't know what your intentions are here, which is part of the problem. From the outside, it feels like the git-annex assistant functionality is now the dominant use case which is guiding the development changes. (And that's understandable if it's most/all of your funding to work on the project.) That seems to be leading towards the "plumbing" low level commands being transitioned into higher level ("porcelain" in git terminology) commands, which do multiple things; and access to the low level functionality being decreased or removed.
Yes, git has done a few "UX breaking" transitions in the past. But in all the cases I can think of the change in functionality was accompanied with obvious documentation on why the change was being made, and how to adapt. For instance the git safe directory behaviour change (CVE-2022-24765) prompted a lot of documentation about why it was changed (eg, git config manpage), and specifically how users could restore the existing functionality where that was appropriate (and, eg, it gave an exact command to run in the warning output). I've been running into that problem repeatedly for a year (including supporting other users), but at least knowing why, and that the recommended "fix command" is the ideal solution, makes it quick to explain/fix/carry on.
In the case of this git-annex change to
sync(from a "just plumbing" meta data sync command, to a "porcelain" git annex assistant like command) there doesn't seem to be any clear documentation on why it is changing, or the recommended process to preserve (or recreate) the existing default functionality (meta data sync only), particularly in a backwards compatible way.The reference to the six year old commit which you see as "starting this change" adds some more context, but almost all of the "documentation" about this change appears to be scattered between some source code commits, some short changelog entries, and a bug that started being about something else. As someone who has followed your personal blog and the git-annex dev blog for years, the change of "sync" from a low level plumbing command (with optional "please do more") to a high level porcelain command (with optional "please skip most of the things you want to do) still seemed to appear very suddenly, without any foreshadowing it was going to change. And I remain unclear on the intended timeline for the (fairly fundamental, IMHO) change in default behaviour.
For my purposes I think from here on I'll be doing all of the following:
On any system I install git-annex, running
git config --global annex.synccontent falseto set my per-user, per-machine state to equivalent to nowOn any git-annex wrapper scripts I have that run
sync, explicitly callinggit annex sync --no-contentinstead of a baregit-annex syncas beforeOn any new git-annex repo that I set up, running
git annex config --set annex.synccontent falseOn the existing git-annex repos, as I interact with them again and remember, run
git annex config --set annex.synccontent falseto maintain the existing defaultOn new/existing git-annex repos, consider also running
git annex wanted . presentas well, since that seems to effectively match my current policy (ie, what is there is what is supposed to be there, because I put it there).(I appreciate that mostly any one of those "should be sufficient". But with a lot of existing git annex repos, spread across lots of machines/drives, some of which are offline, the risks of overlooking one or more of them later on is non-trivial. So belt and braces here.)
Ewen
Based on what, the changes in the last release?
You're seeing a pattern where none exists.
No such funding, not that I allow funding to determine overall direction of this project.
My current thinking is that when a repository does not have a preferred content expression, a content sync could avoid adding content to it.
This would avoid surprising behavior after the transition, except for repositories that did at some time have a preferred content expression set, but one that no longer reflects the use of the repository.
However, current users of
sync --content(or of annex.synccontent) do expect it to fill their repositories that don't have preferred content configured. So would a sync that defaults to content syncing then need to behave differently than an explicitsync --content? Or should changing behavior in that case also be part of the transition?Technically, that would make the default preferred content expression
presentinstead ofinclude=*, right? I'd like that. Less unwanted content after the initial clone when runninggit annex assistorgit annex sync --content. Goes into the direction of specifying the default preferred content expression. Users having freshly cloned a repo can then explicitlygetfiles or set up their preferred content expression.Many annexed repos will be huge in size and rarely one will want everything from it initially. Also great for DataLad datasets.
I would also be in favour of changing the default preferred content expression to be "present" at the same time as
syncwas changed to automatically sync content as well as metadata. The effective user experience of a user with the existing default out of box configuration would be basically equivalent (now:syncdoes not sync content by default; then:syncwill sync content if a policy to indicate desired content is set, but the default policy is "whatever is here is correct").If that change were made (default preferred content expression is "present") then:
I think the current warning on
syncwithout--no-contentcould be removed (as the effective default change from the historical defaults is small)There should probably be a warning on
git annex syncwith a preferred content policy explicitly set (other thanpresent, the new default), that thesyncwithout--no-contentwill "soon" automatically include that preferred contentThere should probably be a warning on
git annex sync --contentwhere there is no preferred content policy explicitly set, that the default preferred content policy is changing, and the user should set an explicit oneThat should result in "I do everything manually" users (who haven't set a preferred content policy, or set it to
present) having basically "no effective change". And the special cases of users (relying on the defaultsyncnot including their preferred content policy; relying on the existing default preferred content policy to work withgit annex sync --content) get a reminder they'll need a smaller tweak to their config.I'd also be fine if new git annexes (ie
git annex initafter new release) were to set an explicit preferred content policy to the current default (just leaving "no content policy set" as the impliedpresentsuggested above). So new annexes would still get the "gets everything by default" behaviour that it seems some users want. (I do not want everything by default as almost always I use annexes for content that is too large to keep on my laptop/desktop.)Thanks for considering reducing the size of the UX change here.
Ewen
The effect in term of file location will be the same after a
git annex symc(withpresentas new defsult - or let's call it fallback - preferred content expression) and agit annex sync --content. But: There's one thing that--contentalso changes in terms of UX: speed/runtime. In my large annex repos with many files (~5 figures), agit annex sync --contenttakes much longer, even if no content is eventually synced. Git Annex apparently needs to go through all files whether they want to be copied somewhere. Maybe a short-circuit path could be introduced here when all preferred content expressions effectively turn out to bepresent. Users might wonder whygit annex syncsuddenly takes so long now.In general, a progress bar or if that's impossible another indication of what's going on between metadata syncing and content syncing would be helpful. With this, I could agree that the warning can go away for a simple
git annex syncwith no preferred content expressions set.Changing the default preferred content expression to
presentrather thananythingwould affect other things likeget --autoand the assistant. I don't think that is a good idea.My idea in comment #15 is a special case for sync and not a wider change.
It will have a special case either way. The current special case means that users who have set preferred content need to remember to use
sync --content. The new special case will only manifest as a difference in behavior betweensyncandsync --content(andget --autoetc) for users with no preferred content configured.I do think that's a valuable narrowing of the special case.
Gone ahead and changed the warning.