2017-02-17 18:04:43 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
|
|
|
- Copyright 2017 Joey Hess <id@joeyh.name>
|
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2017-02-17 18:04:43 +00:00
|
|
|
-}
|
|
|
|
|
2019-12-09 17:49:05 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
2017-02-17 18:04:43 +00:00
|
|
|
module Command.PostReceive where
|
|
|
|
|
|
|
|
import Command
|
|
|
|
import qualified Annex
|
|
|
|
import Git.Types
|
2017-02-17 19:21:39 +00:00
|
|
|
import Annex.UpdateInstead
|
2018-10-19 19:17:48 +00:00
|
|
|
import Annex.CurrentBranch
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
import Command.Sync (mergeLocal, prepMerge, mergeConfig, SyncOptions(..))
|
2017-02-17 18:04:43 +00:00
|
|
|
|
2017-02-23 22:37:02 +00:00
|
|
|
-- This does not need to modify the git-annex branch to update the
|
|
|
|
-- work tree, but auto-initialization might change the git-annex branch.
|
|
|
|
-- Since it would be surprising for a post-receive hook to make such a
|
|
|
|
-- change, that's prevented by noCommit.
|
2017-02-17 18:04:43 +00:00
|
|
|
cmd :: Command
|
2017-02-23 22:37:02 +00:00
|
|
|
cmd = noCommit $
|
|
|
|
command "post-receive" SectionPlumbing
|
|
|
|
"run by git post-receive hook"
|
|
|
|
paramNothing
|
|
|
|
(withParams seek)
|
2017-02-17 18:04:43 +00:00
|
|
|
|
|
|
|
seek :: CmdParams -> CommandSeek
|
|
|
|
seek _ = whenM needUpdateInsteadEmulation $ do
|
|
|
|
fixPostReceiveHookEnv
|
2017-02-17 19:21:39 +00:00
|
|
|
commandAction updateInsteadEmulation
|
2017-02-17 18:04:43 +00:00
|
|
|
|
|
|
|
{- When run by the post-receive hook, the cwd is the .git directory,
|
|
|
|
- and GIT_DIR=. It's not clear why git does this.
|
|
|
|
-
|
|
|
|
- Fix up from that unusual situation, so that git commands
|
|
|
|
- won't try to treat .git as the work tree. -}
|
|
|
|
fixPostReceiveHookEnv :: Annex ()
|
|
|
|
fixPostReceiveHookEnv = do
|
|
|
|
g <- Annex.gitRepo
|
|
|
|
case location g of
|
|
|
|
Local { gitdir = ".", worktree = Just "." } ->
|
|
|
|
Annex.adjustGitRepo $ \g' -> pure $ g'
|
|
|
|
{ location = (location g')
|
|
|
|
{ worktree = Just ".." }
|
|
|
|
}
|
|
|
|
_ -> noop
|
|
|
|
|
2017-02-17 19:21:39 +00:00
|
|
|
updateInsteadEmulation :: CommandStart
|
|
|
|
updateInsteadEmulation = do
|
|
|
|
prepMerge
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
let o = def { notOnlyAnnexOption = True }
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
mc <- mergeConfig False
|
2021-07-19 15:28:31 +00:00
|
|
|
mergeLocal mc o =<< getCurrentBranch
|