Deleted files are not absorbed

[toy]

I tried the tool and noticed right away that it was not able to handle deletion of file, here are commands to reproduce

git init

# Create a commit with two files
echo 'hello, world!' > a.txt
echo 'Hello, World!' > b.txt
git add a.txt b.txt
git commit -m 'a & b'

# Just additional dummy commit
echo 'foo' > c.txt
git add c.txt
git commit -m 'c'

# Merge b.txt into a.txt
cat b.txt >> a.txt
rm b.txt
git add a.txt b.txt

# Addition into a.txt is commited, but not deletion of b.txt
git absorb

[blairconrad]

Duplicate of #46.

As an aside @toy, which version are you using? 0.8.0 should emit a clear message about this, including the phrase "Added, removed, or renamed files cannot be automatically absorbed.". Is this the case for you?

Apr 28 16:32:41.439 INFO committed, header: +1,-0, commit: 3057c13ab6cba0ffdf3b574796e0a614bde2ff84
Apr 28 16:32:41.441 WARN Some changes were not in-place file modifications. Added, removed, or renamed files cannot be automatically absorbed.
Apr 28 16:32:41.441 INFO To squash the new commits, rebase:, command: git rebase --interactive --autosquash --autostash --root

[toy]

I missed #46, as deletion only mentioned in later comment.

I understand that it may be a "dangerous" option, but I'd argue that at least if a file was only created on a branch (so no changes after creation) and then staged for deletion, then it would be nice to have an option to auto absorb. Same for creating following deletion as described in #46. Renames are probably handleable only if previous commit touching that file was also renaming it. Core git allows to shoot oneself in the foot, but also in most cases to get the previous version of that foot

Version wise I have 0.7.0 from macports

[tummychow]

yes, let's keep this as a duplicate of 46 please. and it doesn't surprise me that you don't have 0.8 yet, most distributions are probably catching up to that