0

I have an edited file in my git repo and want to add some of the changes to the staging area by using git add -p.

There is an unsplittable hunk, that contains two added lines of which I want to add the second, but not the first. So I tried to remove the line I don't want to stage by editing the hunk:

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1,5 +2,7 @@
 mod vec2;
 #[cfg(test)]
 mod vec2_tests;
 pub use self::vec2::Vec2;
+pub use self::vec3::Vec3;
+use std::ops::{Add, AddAssign, Sub, SubAssign, Mul, MulAssign};

# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.

I removed the first added line: +pub use self::vec3::Vec3;, saved and quit the editor. Git tells me:

error: patch failed: src/geo/mod.rs:1

error: src/geo/mod.rs: patch does not apply

I don't get why that doesn't work. What's wrong here? How can I stage the second line, but not the first?

David
  • 1,672
  • 2
  • 13
  • 32
  • Try also changing the line range of the second file : `+2,7` -> `+2,6` – LeGEC Jul 14 '20 at 13:46
  • Doesn't work :( – David Jul 14 '20 at 13:49
  • Editing patch hunks by hand is not very convenient, though, this is one of the cases where you would want to edit the file to what you actually want, and run a plain `git add` – LeGEC Jul 14 '20 at 13:50
  • But then the changes, that I dont want to put into the next commit, but after would be lost. I could save the whole thing to a temporary file and then edit the actual file to what I want to commit. I just thought I could do that kinda stuff with git, instead of fiddling around with the changes on my own. – David Jul 14 '20 at 13:55
  • The `2` in `2,7` would indicate that there was one extra line inserted at the very beginning of the added file. Is this the case ? – LeGEC Jul 14 '20 at 13:56
  • Yes, that is correct. I already marked that first line for not being staged. – David Jul 14 '20 at 13:58
  • Git's `add -p` has some kind of bug when the patch is near the top of the file: an edited patch becomes inapplicable. It's not clear precisely what the bug is (or whether it's been fixed in newer Git versions). As a not-very-clever workaround you can just move the final version of the file out of the way, check out the HEAD version, and manually update it to the version you want and then add that. – torek Jul 14 '20 at 17:27

1 Answers1

0

I'm reproducing the same bug locally :

  • if there is an extra first line in the worktree file, and a hunk afterwards, close enough so that the initial add -p offers me to stage both changes at once,
  • and I run add -p,
  • and I first say [s]plit the hunk,
  • and I add or drop the first line (both lead to the same bug),
  • and ask to [e]dit the second hunk :

I can't even apply the proposed patch (eg: saving and quitting the editor without modifications yields an error patch does not apply).

I guess the first condition makes the line range shift, and I couldn't figure out a working combination of range + diff hunk.

I also haven't figured out yet where the partially edited file is stored.

As a workaround :

you can save your current version in a commit or a stash, and edit the file to your convenience.

A workaround close enough to actually running the git add -p you intend to :

  • run git add -p, but do not try to edit a hunk if it is a sub piece of a split hunk, just add those
  • run git stash --keep-index -- the/file (or git stash -k -- the/file)
  • edit the file to remove the extra lines that were included above
  • add & commit that new file
  • then either run :
    • git stash pop and fix the conflicts (you want to keep their version)
    • git show stash@{0}:the/file > the/file (bluntly dump the version stored in the stash on disk, without running any merge-like action)

Given the line ranges in your question : my guess is you first asked to "split", then to "edit" the second hunk.

You can try editing the initial hunk (this worked on my machine, at least).

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Without looking at the code of `git` : I guess the bug lies in first asking to `split` a hunk, then to `edit` a sub hunk. – LeGEC Jul 14 '20 at 14:29
  • Yes you are right. I split the hunk, marked the first subhunk for not being staged and tried to edit the second subhunk like described in the question. Thanks for the workaround ideas. If that really is a bug, do you know where I should report it? Or what steps to follow to fix it? – David Jul 14 '20 at 17:43
  • I'd start from [git on github](https://github.com/git/git). They say bugs should be reported through the mailing list git@vger.kernel.org – LeGEC Jul 14 '20 at 18:51
  • @David : if this post answers your question, can you please accept it ? So that other people know there is an explanation and a workaround – LeGEC Jul 18 '20 at 09:24