"No additions staged" when a new file is added

[jyn514]

$ git status -s
A  src/test/rustdoc/intra-doc/issue-66159.rs
$ git absorb
Aug 22 15:22:01.088 WARN No additions staged, try adding something to the index.

This is clearly not correct, I've added a new file to the index. I want it to go back and amend the commit that removed this file:

$ git log --stat -n2 --oneline
263d4f80298 (HEAD -> lazy-loading, personal/lazy-loading) Fix the bugs and add a regression test
 src/librustdoc/core.rs                                 |  1 +
 src/librustdoc/passes/collect_intra_doc_links/early.rs | 36 ++++++++++++++++--------
 src/test/rustdoc/intra-doc/auxiliary/pub-struct.rs     |  1 +
 src/test/rustdoc/intra-doc/extern-reference-link.rs    |  7 +++++
 4 files changed, 34 insertions(+), 11 deletions(-)
11d8075c12e Revert "Revert "Don't load all extern crates unconditionally""
 src/librustdoc/core.rs                                 | 43 ++++------------
 src/librustdoc/lib.rs                                  |  4 +-
 src/librustdoc/passes/collect_intra_doc_links.rs       |  3 ++
 src/librustdoc/passes/collect_intra_doc_links/early.rs | 63 ++++++++++++++++++++++++
 src/librustdoc/passes/mod.rs                           |  2 +-
 src/test/rustdoc-ui/auxiliary/panic-item.rs            | 17 +++++++
 src/test/rustdoc-ui/unused-extern-crate.rs             |  3 ++
 src/test/rustdoc/auxiliary/issue-66159-1.rs            |  2 -
 src/test/rustdoc/issue-66159.rs                        | 10 ----
 9 files changed, 98 insertions(+), 49 deletions(-)

It might be that it doesn't recognize that src/test/rustdoc/issue-66159.rs is the same file because of the rename, but it should at least say that instead of "no additions staged".

[tummychow]

right now git-absorb doesn't handle added or deleted files - period (this even dates back to my original commutation design https://github.com/tummychow/git-scripts/blob/master/git-absorb.md#interlude-patch-theory). it ignores all staged changes that are an addition/removal (hence the log) and doesn't know how to commute those changes, hence the todo "more commutation cases".

personally, i'm not sure the behavior of "adding a new file should absorb into the deletion of that file" is always what you want... i'd have to think about it more. i'm open to improvements to that log message though. if the index is entirely made of non-modification hunks, we should probably say that non-modification hunks cannot be absorbed

[LemmingAvalanche]

I was surprised that git-absorb 0.6.10 doesn’t handle moved/renamed files:

$ git status -s
R  …
$ git absorb --base develop
Jul 27 13:00:16.299 WARN No additions staged, try adding something to the index.

That’s conceptually more straightforward than adding a file that was previously deleted.

[tummychow]

where exactly do you want the rename to be absorbed? the problem with renames is that they commute with everything. that's not conceptually straightforward at all.

[LemmingAvalanche]

where exactly do you want the rename to be absorbed?

The last commit that modified that file.

The use-case is that these files are database migrations and the version number is embedded in the filename. So if upstream gets updates to the database then pending PRs need to bump their version numbers, i.e. change the filenames.

I thought that would be straightforward but I have no knowledge about the theory behind absorption. :)