Added a comment: ACLs keep fighting back

removed

Added a comment: What is a recent enough version?

Added a comment: re: setkey

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

Added a comment: Maybe this is the problem...

Added a comment: Should there have been a combine step?

Added a comment: Can you give more details?

Added a comment: Oh yeah, use verbose flag too.

Added a comment: A possible solution

Added a comment: Thank you

add news item for git-annex 7.20191024

releasing package git-annex version 7.20191024

Added a comment

Added a comment: Thank you

added todo "warn of breaking changes same way git does"

Added a comment: Triggering which stage and when?

prep release

make git add only annex when configured by annex.largefiles

documentation for making git add only annex when configured by annex.largefiles

Code change should be trvial, but not yet implemented. This
significantly complicated the task of documenting how git-annex works.

I'm not sure how useful the annex.gitaddtoannex confguration is after
this change; seems that if a user has an annex.largefiles they will want
it applied consistently. But the last thing I want to hear is more
complaining from users about git add doing something they don't want it
to.

There's a pretty high risk users who got used to the git add behavior
and don't have annex.largefiles configured will miss the NEWS and
complain bitterly about their suddenly bloated repositories. Oh well.

Removed outdated comments about the old behavior to avoid confusion.
I don't know if I've found all the places that griping spread to.

Merge branch 'master' of ssh://git-annex.branchable.com

fix sql syntax

display sqlite error message when it crashes

avoid warning over name

Added a comment: Friendly bump to keep on the radar

Added a comment

Added a comment: right! forgot about log -S

update from comments

clarify

devblog

Merge branch 'master' of ssh://git-annex.branchable.com

annex.gitaddtoannex configuration

Added annex.gitaddtoannex configuration. Setting it to false prevents
git add from usually adding files to the annex.
(Unless the file was annexed before, or a renamed annexed file is detected.)

Currently left at true; some users are encouraging it be set to false.

shouldAnnex: check isInodeKnown

Renamed unlocked files are now detected, and will always be
annexed, unless annex.largefiles disallows it.

This allows for git add's behavior to later be changed to otherwise
not annex files (whether by default or as a config option), without
worrying about the rename case.

This is not a major behavior change; annexing is still the default. But
there is one case where the behavior is changed, I think for the better:

touch f
git -c annex.largefiles=nothing add f
git add bigfile
git commit -m ...
mv bigfile f
git add f

Before, git-annex would see that f was previously not annexed,
and so the renamed bigfile content gets added to git. Now, it notices
that the inode is the one that bigfile used, and so it annexes it.

This potentially slows down git add a lot in some repositories because
of the poor performance of isInodeKnown when there are a lot of unlocked
files. Configuring annex.largefiles avoids the speed hit.

horrible impementation of isInodeKnown

The only good thing about it is it does not require a major version bump
to improve the database. That will need to happen at some point though.

Potentially very very slow in a large repository.

Ugly use of raw sql.

Added a comment: configuring git add behavior

Added a comment: preventing `git add` from annexing new files

comment typo

Added a comment: searching by inode

comment

rename this so it does not start with a dash

remove unused function

fix formatting of inserted news

Merge branch 'master' of ssh://git-annex.branchable.com

sync: Fix crash when there are submodules and an adjusted branch is checked out

Reverse adjusting the branch uses treeItemToTreeContent, which was missed
when adding submodule support earlier.

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: can git add only annex already-annexed files?

start at analysis before dental appt

reproduced

no, sorry, you don't get to conflate issues

Merge branch 'master' of ssh://git-annex.branchable.com

followup

Added a comment: locking files before reverting to v5

comment

comment

comment

Added a comment: temporary manual downgrade of repos to v5 is possible

removed

Added a comment: temporary manual downgrade of repos to v5 is possible

Added a comment

Added a comment: +1 to the comments above

removed

Added a comment: comment 3

Added a comment: comment 3

comment

comments

Added a comment: check the 'git add' changes before upgrading

Added a comment: skipping dotfiles

Added a comment: different annex.largefiles setting for git add than for git-annex add

comment

Merge branch 'master' of ssh://git-annex.branchable.com

close a bug report redundant with an existing todo

copied over the dandi tag

updated the todo, as now that sameas is done it's unblocked

comment

comment

Added a comment: Tor and the UUID folder

comment

remove obsolete comment

remove recently added and unncessary cwd parameter

I later made Utility.Su change back to the cwd, so this parameter is not
needed.

response

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Deal with pkexec changing to root's home directory when running a command.

Wow, that's not documented anywhere, and seems like a major gotcha in
pkexec.

Broke enable-tor.

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

init: Fix a failure when used in a submodule on a crippled filesystem.

When the submodule's parent repo has an adjusted unlocked branch,
it gets cloned by git, but git checks out master. git annex init then
fails because it wants to enter the adjusted branch, but:

  adjusted branch adjusted/master(unlocked) already exists.

  Aborting because that branch may have changes that have not yet reached master

Note that init actually then exits 0, leaving master checked out.

This could also happen, absent submodules, if the parent repo has
an adjusted unlocked branch, but it is not checked out. In the more common
case where that branch is checked out, the clone uses the same branch,
so no problem.

The choices to fix this:

* Init could delete the existing adjusted branch, and re-adjust.
  But then running init inside an adjusted branch on a crippled filesystem
  would lose any changes that have not been synced back to master.
* Init could sync any changes back to master, but that would be very surprising
  behavior for it.
* Init could simply check out the existing adjusted branch. If the branch
  is diverged from master, well, sync will sort that out later.
  This mirrors the behavior of cloning a repo that has an adjusted branch
  checked out that has not yet been synced back to master.
  Picked this choice.

i always have trouble finding this