propigateAdjustedCommits in seekExportContent

push: When on an adjusted branch, propagate changes to parent branch before
updating export remotes.

This is a somewhat redundant call to propigateAdjustedCommits, since it
also gets called at pushLocal time. That other one needs to come after
importing from importtree remotes though, and seekExportContent has to come
earlier, so I don't see a way to avoid doing it twice.

Note that git-annex sync also manages to avoid the problem, it's only
git-annex push that had the bug.

Sponsored-by: Leon Schuermann on Patreon

doc/bugs/git_annex_push_fails_on_Windows/comment_2_d5c9fd2acdd5b320563a708889e82852._comment

@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-11T17:23:12Z"
+ content="""
+The same behavior can be observed on linux. I just ran `git annex adjust
+--unlock` after committing to get into the same state as on Windows.
+
+It's actually not supported to set annex-tracking-branch to an adjusted
+branch. Instead, you ought to set:
+
+	git config remote.push-win-remote.annex-tracking-branch main
+
+When pulling a new file, as in comment #1, that results in the change
+getting merged into main, and then the adjusted branch is automatically
+updated as well.
+
+When pushing a newly added file, I first had to run 
+`git-annex adjust --unlock` in order to update main. That was a 
+bug in `git-annex push`; it ought to update main for you in this case;
+it already does when pushing to a regular git remote. Fixed that.
+
+The "Not updating export to push-win-remote because adjusted/main(unlocked)
+does not exist" message is misleading. I've improved that to be 
+"Not updating export to push-win-remote because tracking branch name is not valid"
+which at least hints in the right direction.
+"""]]