Open jyn514 opened 3 years ago
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
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.
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.
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. :)
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:
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".