4

I am currently presented with the following situation:

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -10130,7 +10160,22 @@ function myGreatFunc(param1, param2

             let a = funcA(b, c);
             if(funcB(a, d.a.a) >= e) {
-                if(d.b === undefined
+                let f = c * parseInt(g.a[b].a);
+                if(h !== null
+                 && (h.a.a >= c
+                  && h.a.b === b
+                  || funcA(h.a.b, h.a.a) >= a
+                 )
+                ) f = 0;
+/*                if(b === 'a'
+                 && c === 1
+                 && d.a.name === 'b'
+                 && (d.c.a.includes('c')
+                  || d.c.a.includes('d')
+                 )
+                ) console.log('e', f);*/
+
+/*                if(d.b === undefined
                  || d.b.a > c * parseInt(g.a[b].a)
                  || d.b.a === c * parseInt(g.a[b].a)
                   && d.b.b < a

The goal is to remove all comments.

The problem here lies in the end of the hunk, which only includes the start of a block comment, and not its end. It thus keeps the last 3 lines as context, while I also want them removed.

Attempt n°1

Keeping the original context lines, so from-file-range does not need being modified

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -10130,7 +10160,11 @@ function myGreatFunc(param1, param2

             let a = funcA(b, c);
             if(funcB(a, d.a.a) >= e) {
-                if(d.b === undefined
+                let f = c * parseInt(g.a[b].a);
+                if(h !== null
+                 && (h.a.a >= c
+                  && h.a.b === b
+                  || funcA(h.a.b, h.a.a) >= a
+                 )
+                ) f = 0;
+
-                 || d.b.a > c * parseInt(g.a[b].a)
-                 || d.b.a === c * parseInt(g.a[b].a)
-                  && d.b.b < a

Note: The leading space for each of the context lines attempted to be removed has correctly been replaced (as opposed to merely preprended), with -.

Attempt n°2

Removing the original context lines

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -10130,4 +10160,11 @@ function myGreatFunc(param1, param2

             let a = funcA(b, c);
             if(funcB(a, d.a.a) >= e) {
-                if(d.b === undefined
+                let f = c * parseInt(g.a[b].a);
+                if(h !== null
+                 && (h.a.a >= c
+                  && h.a.b === b
+                  || funcA(h.a.b, h.a.a) >= a
+                 )
+                ) f = 0;
+

Results

Both attempts were met with:

error: patch failed: myFile.html:10130
error: myFile.html: patch does not apply
Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]?

Notes

Using git version 2.22.0.windows.1

How to edit that hunk to achieve the sought-after result?

Community
  • 1
  • 1
Bernard Rosset
  • 4,523
  • 6
  • 27
  • 29
  • 2
    I don't think you can achieve this with `git add -p`. (I'm not an expert at `git add -p`, so I could be wrong.) In general I find this sort of thing *much* easier to do with: `cp file file.save; vi file` and edit the file into the shape I want for this commit. Then I can test, add, commit, and `mv file.save file` to go back to the preserved one later. – torek Jun 20 '19 at 21:36
  • 1
    Well, that would be manually managing versions the file... which defeats the whole purpose of using `git`, as it is a version control system! I am seeking for a way for this patch to work, as my fallback strategy would be to 1°) Commit as-is 2°) Rebase & edit/split the last commit to separate changes in 2 specific commits. Moreover, this kind of manual edition of a patch works when there only are removals (ie no `+` lines in the mix). I suspect a bug of some sorts... but the reason I post here is to be certain... added to a lil bit of hope? (o: – Bernard Rosset Jun 20 '19 at 21:43
  • 1
    I wouldn't go so far as to say "defeats the whole purpose". Git is a tool-set. In this case it has a possibly defective tool within the set, but that doesn't mean the rest of the set is useless (or not being used) when you sidestep that one tool... :-) – torek Jun 20 '19 at 21:56
  • Agrred, but as I stated before, I would then continue using the git tools to circumvent that limitation (instead of side-tracking git and risk losing history/rollback ability on some modifications)... provided it is a limitation/bug, and not a mere lack of skills from myself ;o) – Bernard Rosset Jun 20 '19 at 22:01
  • I don't understand your original diff. you seem to be adding comment opening but where does it ends? – max630 Jun 22 '19 at 16:46
  • Why don't you actually remove the comment in file? Then it would not be a "context". – max630 Jun 22 '19 at 17:48
  • @max630 The hunk length as been determined automatically by the interactive `git add --patch`, which seems quite 'dumb'. For block comments, only the first and last lines being modified, the tool takes the liberty of potentially splitting hunks in the middle... As for you other suggestion, I am not looking for a workaround solution, as I stated before there already are some ways within the git framework to get past what I guess is an anomaly. I don't need that comment in this specific commit, but I might want to keep it further down the line, thus removing it entirely is a non-solution. – Bernard Rosset Jun 23 '19 at 17:37

0 Answers0