{"thread":{"id":"37666","subject":"[TOY PATCH]: rebase: Add --show-files option","startedAt":"2014-10-03T04:42:14Z","lastAt":"2014-10-03T19:11:18Z","messageCount":3,"participants":["Nazri Ramliy","Chris Packham","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"250191","messageId":"CAEY4ZpN4HEo-Csf1UjpGX4YLKWRrywinUemeZFZdVg=ZtTsaqA@mail.gmail.com","threadId":"37666","inReplyTo":null,"subject":"[TOY PATCH]: rebase: Add --show-files option","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2014-10-03T04:42:14Z","receivedAt":"2014-10-03T04:42:14Z","isPatch":true,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"Hi,\n\nWhen working on a \"new feature branch\" that touches a lot of files I\ntend to make commits that affect only single files, and for very small\nchanges. Since at this stage I'm experimentating a lot - trying out\nideas, etc. - the commits tend to grow a lot (could be 50-70\nindividual commits, each modifying one or two files), and I don't\nthink much about the commit message beside making a one-liner that\nexplains only the gist.\n\nMost of the times I include the filename in the commit message to help\nme identify which commits should be squashed together later.\n\nOnly when the feature seems to be functional that I git rebase the\ncommits in order to shape the history into its final, proper form.\n\nWhen rebasing these upwards of 40+ commits, it is helpful if the\nrebase instruction sheet shows me the actual files that the commits\naffect so I made this patch (sorry I couldn't attach it inline since\ngmail eats all the tabs) that adds the \"--show-files\" option to\ngit-rebase to achieve something to this effect:\n\npick 996fa59 Remove autoconf submodule\n     # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules\n     # :160000 000000 0263a9f... 0000000... D   autoconf\n... more pick lines\npick 4c5070f Remove automake submodule\n     # :100644 100644 28ddb02... f907328... M   .gitmodules\n     # :160000 000000 9042530... 0000000... D   automake\n\nHaving the list of files shown below each commit, indented to reduce\ncluttering the \"pick\" instruction, really does help in deciding the\nreorder and squash candidates.\n\nThe files list came from this:\n\n  git show --raw $sha1|awk '/^:/ {print \" '\"${comment_char}\"'\\t\"$0}'\n\nThoughts?\n\nnazri\n\n\nFrom 4826875c14554d4fa5098ddf9499c33cb7b9001b Mon Sep 17 00:00:00 2001\nFrom: Nazri Ramliy <ayiehere@gmail.com>\nDate: Fri, 3 Oct 2014 09:59:38 +0800\nSubject: [PATCH] rebase: Add --show-files option\n\n---\n Documentation/git-rebase.txt |  8 ++++++++\n git-rebase--interactive.sh   | 13 +++++++++++++\n git-rebase.sh                |  5 +++++\n 3 files changed, 26 insertions(+)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex f14100a..4996bc4 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -383,6 +383,14 @@ If `--autosquash` is used, \"exec\" lines will not be appended for\n the intermediate commits, and will only appear at the end of each\n squash/fixup series.\n \n+-F::\n+--show-files::\n+\tAppend the list of affected files after each line creating a commit in\n+\tthe history.\n++\n+This option can only be used with the `--interactive` option\n+(see INTERACTIVE MODE below).\n+\n --root::\n \tRebase all commits reachable from <branch>, instead of\n \tlimiting them with an <upstream>.  This allows you to rebase\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex b64dd28..32b4266 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -820,6 +820,11 @@ add_exec_commands () {\n \tmv \"$1.new\" \"$1\"\n }\n \n+print_affected_files () {\n+\tcommit_sha1=\"$1\"\n+\tgit show --raw $commit_sha1|awk '/^:/ {print \"     '\"${comment_char}\"' \"$0}'\n+}\n+\n # The whole contents of this file is run by dot-sourcing it from\n # inside a shell function.  It used to be that \"return\"s we see\n # below were not inside any function, and expected to return\n@@ -978,6 +983,10 @@ do\n \tif test t != \"$preserve_merges\"\n \tthen\n \t\tprintf '%s\\n' \"${comment_out}pick $shortsha1 $rest\" >>\"$todo\"\n+\t\tif test -n \"$show_files\"\n+\t\tthen\n+\t\t\tprint_affected_files $shortsha1 >> \"$todo\"\n+\t\tfi\n \telse\n \t\tsha1=$(git rev-parse $shortsha1)\n \t\tif test -z \"$rebase_root\"\n@@ -997,6 +1006,10 @@ do\n \t\tthen\n \t\t\ttouch \"$rewritten\"/$sha1\n \t\t\tprintf '%s\\n' \"${comment_out}pick $shortsha1 $rest\" >>\"$todo\"\n+\t\t\tif test -n \"$show_files\"\n+\t\t\tthen\n+\t\t\t\tprint_affected_files $sha1 >> \"$todo\"\n+\t\t\tfi\n \t\tfi\n \tfi\n done\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 55da9db..4968b2c 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -24,6 +24,7 @@ m,merge!           use merging strategies to rebase\n i,interactive!     let the user edit the list of commits to rebase\n x,exec=!           add exec lines after each commit of the editable list\n k,keep-empty\t   preserve empty commits during rebase\n+F,show-files       Show files affected by each list of commit to rebase\n f,force-rebase!    force rebase even if branch is up to date\n X,strategy-option=! pass the argument through to the merge strategy\n stat!              display a diffstat of what changed upstream\n@@ -88,6 +89,7 @@ autosquash=\n keep_empty=\n test \"$(git config --bool rebase.autosquash)\" = \"true\" && autosquash=t\n gpg_sign_opt=\n+show_files=\n \n read_basic_state () {\n \ttest -f \"$state_dir/head-name\" &&\n@@ -336,6 +338,9 @@ do\n \t--gpg-sign=*)\n \t\tgpg_sign_opt=\"-S${1#--gpg-sign=}\"\n \t\t;;\n+\t --show-files|-F)\n+\t\tshow_files=t\n+\t\t;;\n \t--)\n \t\tshift\n \t\tbreak\n-- \n2.1.0.244.g5796467.dirty\n\n"},{"id":"250195","messageId":"CAFOYHZDDq0UfvznUTx5FMaX97kK0nJxYAJ_-sj_Mu+x3o3ftCg@mail.gmail.com","threadId":"37666","inReplyTo":"CAEY4ZpN4HEo-Csf1UjpGX4YLKWRrywinUemeZFZdVg=ZtTsaqA@mail.gmail.com","subject":"Re: [TOY PATCH]: rebase: Add --show-files option","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-10-03T07:42:10Z","receivedAt":"2014-10-03T07:42:10Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nOn Fri, Oct 3, 2014 at 5:42 PM, Nazri Ramliy <ayiehere@gmail.com> wrote:\n> Hi,\n>\n> When working on a \"new feature branch\" that touches a lot of files I\n> tend to make commits that affect only single files, and for very small\n> changes. Since at this stage I'm experimentating a lot - trying out\n> ideas, etc. - the commits tend to grow a lot (could be 50-70\n> individual commits, each modifying one or two files), and I don't\n> think much about the commit message beside making a one-liner that\n> explains only the gist.\n>\n> Most of the times I include the filename in the commit message to help\n> me identify which commits should be squashed together later.\n>\n> Only when the feature seems to be functional that I git rebase the\n> commits in order to shape the history into its final, proper form.\n>\n> When rebasing these upwards of 40+ commits, it is helpful if the\n> rebase instruction sheet shows me the actual files that the commits\n> affect so I made this patch (sorry I couldn't attach it inline since\n> gmail eats all the tabs) that adds the \"--show-files\" option to\n> git-rebase to achieve something to this effect:\n>\n> pick 996fa59 Remove autoconf submodule\n>      # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules\n>      # :160000 000000 0263a9f... 0000000... D   autoconf\n> ... more pick lines\n> pick 4c5070f Remove automake submodule\n>      # :100644 100644 28ddb02... f907328... M   .gitmodules\n>      # :160000 000000 9042530... 0000000... D   automake\n>\n> Having the list of files shown below each commit, indented to reduce\n> cluttering the \"pick\" instruction, really does help in deciding the\n> reorder and squash candidates.\n\nSounds neat. I do similar things and do sometimes lose track of which\nfiles are being touched by multiple \"fix compile error\" commits. I\nhaven't actually looked at your patch because gmail can't display it\nin-line but it's a feature I'd use.\n\n>\n> The files list came from this:\n>\n>   git show --raw $sha1|awk '/^:/ {print \" '\"${comment_char}\"'\\t\"$0}'\n>\n> Thoughts?\n>\n> nazri\n"},{"id":"250207","messageId":"xmqqiok1klyh.fsf@gitster.dls.corp.google.com","threadId":"37666","inReplyTo":"CAEY4ZpN4HEo-Csf1UjpGX4YLKWRrywinUemeZFZdVg=ZtTsaqA@mail.gmail.com","subject":"Re: [TOY PATCH]: rebase: Add --show-files option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-03T19:11:18Z","receivedAt":"2014-10-03T19:11:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nazri Ramliy <ayiehere@gmail.com> writes:\n\n> When rebasing these upwards of 40+ commits, it is helpful if the\n> rebase instruction sheet shows me the actual files that the commits\n> affect so I made this patch (sorry I couldn't attach it inline since\n> gmail eats all the tabs) that adds the \"--show-files\" option to\n> git-rebase to achieve something to this effect:\n>\n> pick 996fa59 Remove autoconf submodule\n>      # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules\n>      # :160000 000000 0263a9f... 0000000... D   autoconf\n> ... more pick lines\n> pick 4c5070f Remove automake submodule\n>      # :100644 100644 28ddb02... f907328... M   .gitmodules\n>      # :160000 000000 9042530... 0000000... D   automake\n>\n> Having the list of files shown below each commit, indented to reduce\n> cluttering the \"pick\" instruction, really does help in deciding the\n> reorder and squash candidates.\n\nSounds like a good idea to give helpful information in a comment\nform to the insn sheet.\n\nOther than two minor points:\n\n - If I were doing this, I would have used \"diff-tree --stat\n   --summary\" instead of \"show --raw\".  You can tell\n   deletion/addition by paying attention to 0's and also mode\n   changes, but the information density of --raw for human\n   consumption is rather low.\n\n - Regardless of the above, I am not sure if dumping listing of 100+\n   paths modified would really help, and it might make sense to cap\n   the number of paths displayed for each change.\n\nI didn't look at your implementation at all, though.\n"}]}