From the warning produced by "git add ." after removing a file with "rm":
> warning: You ran 'git add' with neither '-A (--all)' or '--ignore-removal',
> whose behaviour will change in Git 2.0 with respect to paths you removed.
> Paths like 'foo.txt' that are
> removed from your working tree are ignored with this version of Git.
>
> * 'git add --ignore-removal <pathspec>', which is the current default,
> ignores paths you removed from your working tree.
>
> * 'git add --all <pathspec>' will let you also record the removals.
>
> Run 'git status' to check the paths you removed from your working tree.
$ git status --porcelain
D foo.txt
$ git add --all .
$ git status --porcelain
D foo.txt
$ git --version
git version 1.9.1
The second pass is done after the first one. During the second pass,
an item is built in tree of files from all other items. It checks that:
* packages can be built in any order satisfying dependencies;
* a package can be rebuilt after its dependee.
For both cases, not only build status is checked but also two sets of
files are compared. Currently content of files is not checked, only
their existance in both passes.
See #1111
`git merge -s recursive -X ours` turned out to fail on binary
files. (I can't reproduce this behaviour in test repo, maybe
it is Git's bug.) So I switched to `checkout --ours`, which
worked in that case.
Result of build by previous commit:
https://gist.github.com/32309209c467853deedc
If a conflict happens, build-pkg should "resolve" it by selecting
one of versions. Git has a merge strategy "recursive" with an
option "ours" which does exactly what is needed but works only
for two heads. That is why multi-merge was replaced by multiple
merges of two heads.
check-requirements creates directories usr/<target> for all
targets. By default, MXE_TARGETS=i686-w64-mingw32.static, so
it creates a directory for i686-w64-mingw32.static only.
(Currently this doesn't affect history in usr/.git as git ignores
empty directories.)
The installation failed with the following note:
> Noting disappearance of mxe-requirements,
> which has been completely replaced.
Add an empty file mxe-requirements.dummy.$release
to prevent this.
Debian packages with "Depends: " do not work:
> Reading package lists... Error!
> E: Problem parsing dependency Depends
> E: Error occurred while processing mxe-source (NewVersion2)
> E: Problem with MergeList /var/lib/apt/lists/pkg.mxe.cc_repos_apt_debian_dists_wheezy_main_binary-amd64_Packages
> E: The package lists or status file could not be parsed or opened.
Boris Nagaev
Tony Theodore