Can I force git to treat a change as a single piece?












4















Occasionally I'll have a commit that completely rewrites a block of code, but has a few identical lines interspersed by chance. Git-diff divides the change into pieces around those lines, and the diff becomes hard to understand.



In such cases it would be nice to tell git "ignore single unchanged lines; act as if this entire block was deleted and replaced."



For example, I want to turn a diff that looks like this:



-def rewritten_function(oldarg):
- do a
- do b
+def rewritten_function(newarg):
+ do z
+ do y
with random_matching_line as f:
- do x
- do y
- do z
+ do a
+ do b
+ do c


into this:



-def rewritten_function(oldarg):
- do a
- do b
- with random_matching_line as f:
- do x
- do y
- do z
+def rewritten_function(newarg):
+ do z
+ do y
+ with random_matching_line as f:
+ do a
+ do b
+ do c


Is there a way to do that, either when preparing a commit or viewing the log later?










share|improve this question





























    4















    Occasionally I'll have a commit that completely rewrites a block of code, but has a few identical lines interspersed by chance. Git-diff divides the change into pieces around those lines, and the diff becomes hard to understand.



    In such cases it would be nice to tell git "ignore single unchanged lines; act as if this entire block was deleted and replaced."



    For example, I want to turn a diff that looks like this:



    -def rewritten_function(oldarg):
    - do a
    - do b
    +def rewritten_function(newarg):
    + do z
    + do y
    with random_matching_line as f:
    - do x
    - do y
    - do z
    + do a
    + do b
    + do c


    into this:



    -def rewritten_function(oldarg):
    - do a
    - do b
    - with random_matching_line as f:
    - do x
    - do y
    - do z
    +def rewritten_function(newarg):
    + do z
    + do y
    + with random_matching_line as f:
    + do a
    + do b
    + do c


    Is there a way to do that, either when preparing a commit or viewing the log later?










    share|improve this question



























      4












      4








      4








      Occasionally I'll have a commit that completely rewrites a block of code, but has a few identical lines interspersed by chance. Git-diff divides the change into pieces around those lines, and the diff becomes hard to understand.



      In such cases it would be nice to tell git "ignore single unchanged lines; act as if this entire block was deleted and replaced."



      For example, I want to turn a diff that looks like this:



      -def rewritten_function(oldarg):
      - do a
      - do b
      +def rewritten_function(newarg):
      + do z
      + do y
      with random_matching_line as f:
      - do x
      - do y
      - do z
      + do a
      + do b
      + do c


      into this:



      -def rewritten_function(oldarg):
      - do a
      - do b
      - with random_matching_line as f:
      - do x
      - do y
      - do z
      +def rewritten_function(newarg):
      + do z
      + do y
      + with random_matching_line as f:
      + do a
      + do b
      + do c


      Is there a way to do that, either when preparing a commit or viewing the log later?










      share|improve this question
















      Occasionally I'll have a commit that completely rewrites a block of code, but has a few identical lines interspersed by chance. Git-diff divides the change into pieces around those lines, and the diff becomes hard to understand.



      In such cases it would be nice to tell git "ignore single unchanged lines; act as if this entire block was deleted and replaced."



      For example, I want to turn a diff that looks like this:



      -def rewritten_function(oldarg):
      - do a
      - do b
      +def rewritten_function(newarg):
      + do z
      + do y
      with random_matching_line as f:
      - do x
      - do y
      - do z
      + do a
      + do b
      + do c


      into this:



      -def rewritten_function(oldarg):
      - do a
      - do b
      - with random_matching_line as f:
      - do x
      - do y
      - do z
      +def rewritten_function(newarg):
      + do z
      + do y
      + with random_matching_line as f:
      + do a
      + do b
      + do c


      Is there a way to do that, either when preparing a commit or viewing the log later?







      git diff






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 22 '18 at 18:35







      Andrew

















      asked Nov 21 '18 at 0:51









      AndrewAndrew

      1,60121023




      1,60121023
























          1 Answer
          1






          active

          oldest

          votes


















          1














          diff.interHunkContext's config says




          Show the context between diff hunks, up to the specified number of lines,
          thereby fusing the hunks that are close to each other. This value serves as
          the default for the --inter-hunk-context command line option.




          which looks like exactly what you want.






          share|improve this answer
























          • I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

            – Andrew
            Nov 21 '18 at 4:55











          • I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

            – jthill
            Nov 21 '18 at 12:42











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53403800%2fcan-i-force-git-to-treat-a-change-as-a-single-piece%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          diff.interHunkContext's config says




          Show the context between diff hunks, up to the specified number of lines,
          thereby fusing the hunks that are close to each other. This value serves as
          the default for the --inter-hunk-context command line option.




          which looks like exactly what you want.






          share|improve this answer
























          • I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

            – Andrew
            Nov 21 '18 at 4:55











          • I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

            – jthill
            Nov 21 '18 at 12:42
















          1














          diff.interHunkContext's config says




          Show the context between diff hunks, up to the specified number of lines,
          thereby fusing the hunks that are close to each other. This value serves as
          the default for the --inter-hunk-context command line option.




          which looks like exactly what you want.






          share|improve this answer
























          • I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

            – Andrew
            Nov 21 '18 at 4:55











          • I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

            – jthill
            Nov 21 '18 at 12:42














          1












          1








          1







          diff.interHunkContext's config says




          Show the context between diff hunks, up to the specified number of lines,
          thereby fusing the hunks that are close to each other. This value serves as
          the default for the --inter-hunk-context command line option.




          which looks like exactly what you want.






          share|improve this answer













          diff.interHunkContext's config says




          Show the context between diff hunks, up to the specified number of lines,
          thereby fusing the hunks that are close to each other. This value serves as
          the default for the --inter-hunk-context command line option.




          which looks like exactly what you want.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 21 '18 at 1:05









          jthilljthill

          28.4k34580




          28.4k34580













          • I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

            – Andrew
            Nov 21 '18 at 4:55











          • I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

            – jthill
            Nov 21 '18 at 12:42



















          • I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

            – Andrew
            Nov 21 '18 at 4:55











          • I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

            – jthill
            Nov 21 '18 at 12:42

















          I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

          – Andrew
          Nov 21 '18 at 4:55





          I don't think it is...if I'm reading that right, it affects which changes are considered part of the same hunk; but I'm concerned with the display of the add/removes within what's already one hunk. Experimenting with it hasn't gotten me anywhere either. Maybe I should come up with a simplified example to add to the question.

          – Andrew
          Nov 21 '18 at 4:55













          I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

          – jthill
          Nov 21 '18 at 12:42





          I see it now, the word "hunk" just has too much work to do, I was thinking of potential-conflict ranges, which can be separated by single matching lines, which aren't the same as what diff calls a hunk, that generally need three. An example would probably have helped. I don't know how to do what you're after, I suspect that'd be a welcome patch..

          – jthill
          Nov 21 '18 at 12:42




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53403800%2fcan-i-force-git-to-treat-a-change-as-a-single-piece%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          這個網誌中的熱門文章

          Academy of Television Arts & Sciences

          L'Équipe

          1995 France bombings