Commit graph

43196 commits

Author SHA1 Message Date
Joey Hess
83a3786851
comment 2023-03-01 15:58:47 -04:00
Joey Hess
54ad1b4cfb
Windows: Support long filenames in more (possibly all) of the code
Works around this bug in unix-compat:
https://github.com/jacobstanley/unix-compat/issues/56
getFileStatus and other FilePath using functions in unix-compat do not do
UNC conversion on Windows.

Made Utility.RawFilePath use convertToWindowsNativeNamespace to do the
necessary conversion on windows to support long filenames.

Audited all imports of System.PosixCompat.Files to make sure that no
functions that operate on FilePath were imported from it. Instead, use
the equvilants from Utility.RawFilePath. In particular the
re-export of that module in Common had to be removed, which led to lots
of other changes throughout the code.

The changes to Build.Configure, Build.DesktopFile, and Build.TestConfig
make Utility.Directory not be needed to build setup. And so let it use
Utility.RawFilePath, which depends on unix, which cannot be in
setup-depends.

Sponsored-by: Dartmouth College's Datalad project
2023-03-01 15:55:58 -04:00
Joey Hess
505f1a654b
avoid using Utility.Path.AbsRel in Utility.Path.Windows
AbsRel depends on unix, but Utility.Path.Windows will be used in some
libraries that are part of the setup-depends, which cannot depend on
unix.

The only reason that AbsRel uses getWorkingDirectory on unix is that
it returns RawFilePath. getCurrentDirectory returns FilePath and so
needs a conversion to RawFilePath. Looks like a newer version of
directory will fix that, by using OsPath, so eventually AbsPath should
be able to switch to using getCurrentDirectory on unix, and then the
small code duplication in this commit won't be needed.

Sponsored-by: Dartmouth College's Datalad project
2023-03-01 14:01:33 -04:00
Joey Hess
3c08af0da1
factor out convertToWindowsNativeNamespace into its own module
Gonna use this more widely.

Sponsored-by: Dartmouth College's Datalad project
2023-03-01 13:28:39 -04:00
Joey Hess
9417bdab14
comment 2023-03-01 13:04:18 -04:00
Joey Hess
bded62378a
close 2023-03-01 12:34:40 -04:00
Joey Hess
70d89456d2
close 2023-03-01 12:22:38 -04:00
Joey Hess
9c3c4c1712
deprecate git-annex status w/o runtime warning
As far as I can see, git-annex status was added to support direct mode, and
like other things added for that, it ought to be deprecated.

Behavior is similar to git status --short, though not identical in a few
cases eg renamed files.

I think datalad does not use this command, although it might have in the
past. Could not find any use of it in the current datalad code.

A deprecation warning at runtime would be the next step, probably will wait
and do that for all the deprecated commands together (except findref).
2023-02-28 16:34:31 -04:00
mih
3bf2d98e9c Added a comment: Update for git-annex 10.20230227-ga206cdddb4 2023-02-28 15:35:50 +00:00
Joey Hess
c569082cf2
devblog 2023-02-27 16:28:26 -04:00
Joey Hess
9fcaf27cba
done with adjusted view branches!
Well, perhaps it could be documented better, but it's a compositional
feature so users who need it will probably try it and be happy to find
that it works.
2023-02-27 15:55:31 -04:00
Joey Hess
80478cc145
support git-annex view in an adjusted branch
Rather than entering a view of the adjusted branch, enter an adjusted
view branch. This way, it's the same as first using git-amnnex view
followed by git-annex adjust, and everything already implemented to
support that works.

Sponsored-by: Nicholas Golder-Manning on Patreon
2023-02-27 15:48:58 -04:00
Joey Hess
bb54c8a633
support --hide-missing adjustment of view branches
I had thought this would not make sense to combine with view branches,
since removing files from a view changes metadata.

However, that's committing removal of files. With --hide-missing, the
files get removed when git-annex updates the branch itself, so there is
no conflict.

It does not seem likely to be very useful, but it does work! And that's
nice because it means all types of adjusted branches can be combined with
view branches.

Sponsored-by: Max Thoursie on Patreon
2023-02-27 15:39:58 -04:00
Joey Hess
1c4f4b449a
support --unlock-present adjustment of view branches
When generating the view, check if the key is present.

When syncing in a view branch with an adjustment, run adjustedBranchRefreshFull
the same as is done when syncing in other adjusted branches. This is
needed because the docs for git-annex adjust --unlock-present suggest
using git-annex sync to update the branch when annex.adjustedbranchrefresh
is not set.

Note that, with annex.adjustedbranchrefresh set, it just works! The
adjusted branch gets updated in the usual way and it doesn't matter that
there's a view branch underneath.

And of course, re-running git-annex adjut --unlock-present also works,
as suggested in the docs.

Sponsored-by: Erik Bjäreholt on Patreon
2023-02-27 15:37:57 -04:00
Joey Hess
7d839176c3
support generation of unlocked views
Just make pointer files rather than symlinks, easy.

As for the other adjustments:
--lock is the default for views
--fix happens automatically in views
--hide-missing probably does not make sense when combined with views,
because deleting a file from a view removes metadata
--unlock-present will need a bit more work
2023-02-27 15:07:36 -04:00
Joey Hess
f09e299156
rawfilepath conversion 2023-02-27 15:06:32 -04:00
Joey Hess
cc32e31161
understand adjusted view branch names
An adjusted view branch has a name like
"refs/heads/adjusted/views/master(author=_)(unlocked)", so it is a view
branch that has been converted to an adjusted branch.

Made Logs.View support such branch names. So now git-annex sync and
pre-commit handle updating metadata on commit in such a branch.

Much remains to be done to fully support adjusted view branches,
including actually applying the adjustment when updating the view branch.

Sponsored-by: Graham Spencer on Patreon
2023-02-27 14:57:58 -04:00
Joey Hess
2a966f49f2
overwrite old adjusted view branch
When git-annex adjust is run in a view branch, and the adjusted branch
already exists, overwrite the old adjusted branch with the new one
without being forced.

Usually overwriting an adjusted branch is avoided because it could lose
data. But when a view branch has been adjusted, there is no data to lose
in the adjusted branch, because the only changes that can be made of
significance are to move files between directories. Which changes
metadata on commit. And the old branch has already been committed.

Sponsored-by: Lawrence Brogan on Patreon
2023-02-27 14:35:27 -04:00
Joey Hess
9b1fe37818
improve adjusted branch name parsing to support adjusted view branches
An adjusted view branch has a name like
"adjusted/views/master(author=_)(unlocked)"
and so the adjustment starts at the last open paren, not the first open
paren.

Note that git-annex sync still does not do anything useful when run in
such a branch, because it does not realize that it is a view branch.
This is only groundwork for adjusted view branches.

This also fixes adjusted branches when the basis branch name contains
parens for some other reason, though that is not common in a git branch
name.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon
2023-02-27 14:09:05 -04:00
Joey Hess
df007925e6
add news item for git-annex 10.20230227 2023-02-27 12:24:03 -04:00
Joey Hess
a206cdddb4
releasing package git-annex version 10.20230227 2023-02-27 12:23:43 -04:00
Joey Hess
69d7f935d6
comment 2023-02-27 12:03:09 -04:00
Joey Hess
a5a23f0e9a
comment 2023-02-27 11:57:07 -04:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
d24914f2af Added a comment: Re: Weird behavior of git archive in combination with largefiles configuration 2023-02-26 18:45:31 +00:00
nadir
8716bd2ded Added a comment 2023-02-24 18:56:40 +00:00
nobodyinperson
f9b4b318c2 Added a comment 2023-02-23 22:59:49 +00:00
Joey Hess
195508fc65
Improve error message when unable to read a sqlite database due to permissions problem
Old message was:

sqlite query crashed: thread blocked indefinitely in an MVar operation

New message is eg:

sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open ".git/annex/keysdb/db".

The worker thread used to throw an exception. But before that
exception was seen by anything waiting on the worker thread to
finish, the takeMVar in queryDb would have crashed with
BlockedIndefinitelyOnMVar.

Sponsored-by: k0ld on Patreon
2023-02-23 15:28:22 -04:00
Joey Hess
338f28f3a6
comment 2023-02-23 15:14:32 -04:00
Joey Hess
595f5b8b1a
comment 2023-02-23 14:46:44 -04:00
Joey Hess
35f37ecb9a
Merge branch 'master' of ssh://git-annex.branchable.com 2023-02-23 14:40:38 -04:00
Joey Hess
d5ad74d14f
add m68k to arch lists for webapp build deps 2023-02-23 14:26:20 -04:00
Joey Hess
f24f96e018
move webapp build deps under Assistant build flag
git-annex.cabal: Move webapp build deps under the Assistant build flag so
git-annex can be built again without yesod etc installed.

Commit 78440ca37d got rid of the webapp build
flag to work around what was apparently a cabal bug. It moved the webapp
build deps to the main build-depends list. But that prevents building
git-annex when yesod etc are not installed.

Putting them under the Assistant build flag seems to not tickle that cabal
bug, and lets git-annex build automatically with the assistant disabled
when the webapp build deps are not installed.

I hypotehesize that the problem may have involved build-depends nested
behind two build flags. Also, cabal clean may need to be run in order
for cabal to find the right solution after this change, when building in
a directory where cabal configure had been run before.

Also moved 3 modules that are needed to build git-annex w/o the assistant
out from under the Assistant build flag.

Sponsored-by: Brock Spratlen on Patreon
2023-02-23 12:25:22 -04:00
Atemu
cfb396becf Added a comment 2023-02-23 08:59:28 +00:00
nobodyinperson
a268dbf401 2023-02-22 21:57:19 +00:00
hurlebouc
5b6202c973 Added a comment 2023-02-21 06:49:27 +00:00
Joey Hess
d1a0f0c7d1
comment 2023-02-20 15:19:31 -04:00
Joey Hess
8f2829e646
Revert "stack.yaml: Update to lts-19.33 and aws-0.24"
This reverts commit 648e59cac2.

Failed to build on windows, because

       In the dependencies for haskeline-0.8.2:
           Win32-2.11.1.0 from Stack configuration does not match >=2.1 && <2.10 || >=2.12 (latest
                          matching version is 2.13.4.0)

jkniiv did find a solution that builds:

-- Win32-2.11.1.0
+- Win32-2.9.0.0
+- Cabal-3.6.3.0
+- directory-1.3.7.1
+- process-1.6.17.0
+- time-1.11.1.2

But that is a quite old version of Win32 and risks bugs from it, and bumping
Cabal and directory to newer than lts-19.33 has seems also likely to be risky.

So, I've given up. aws-0.24 won't be able to be in the stack build until
there's a stackage lts (or nightly) that has filepath (>=1.4.100.0),
which will not happen until sometime after the next ghc release.
2023-02-20 15:15:06 -04:00
Joey Hess
326f01f5a3
response 2023-02-20 15:00:59 -04:00
Joey Hess
75a2fb9441
comment and close 2023-02-20 14:46:47 -04:00
Joey Hess
ab1dd317c0
comment 2023-02-20 14:38:22 -04:00
Joey Hess
16d3097a08
fix reversion in info, and add test case
info: Fix reversion in last release involving handling of unsupported input
by continuing to handle any other inputs, before exiting nonzero at the
end.

Sponsored-by: Dartmouth College's Datalad project
2023-02-20 14:31:37 -04:00
jg123h12jh3y12g3y
4199c457e2 2023-02-20 13:09:45 +00:00
yarikoptic
349f8afecb Added a comment 2023-02-17 21:50:19 +00:00
yarikoptic
36c76040e2 duplicating report here to possibly expedite resolution 2023-02-17 18:15:48 +00:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
804ea016d0 Added a comment: Weird behavior of git archive in combination with largefiles configuration 2023-02-17 09:46:34 +00:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
ff601ddc45 removed 2023-02-17 09:45:14 +00:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
5c4d53be19 Added a comment: Weird behavior of git archive in combination with largefiles configuration 2023-02-17 09:44:35 +00:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
d31e605b02 removed 2023-02-17 09:43:51 +00:00
arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12
4e83ff3bbd Added a comment: Weird behavior of git archive in combination with largefiles configuration 2023-02-17 09:43:20 +00:00
sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b
e8297e9cb2 Added a comment 2023-02-17 01:42:58 +00:00