[TOY PATCH]: rebase: Add --show-files option

[TOY PATCH]: rebase: Add --show-files option

[Nazri Ramliy]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Hi,

When working on a "new feature branch" that touches a lot of files I
tend to make commits that affect only single files, and for very small
changes. Since at this stage I'm experimentating a lot - trying out
ideas, etc. - the commits tend to grow a lot (could be 50-70
individual commits, each modifying one or two files), and I don't
think much about the commit message beside making a one-liner that
explains only the gist.

Most of the times I include the filename in the commit message to help
me identify which commits should be squashed together later.

Only when the feature seems to be functional that I git rebase the
commits in order to shape the history into its final, proper form.

When rebasing these upwards of 40+ commits, it is helpful if the
rebase instruction sheet shows me the actual files that the commits
affect so I made this patch (sorry I couldn't attach it inline since
gmail eats all the tabs) that adds the "--show-files" option to
git-rebase to achieve something to this effect:

pick 996fa59 Remove autoconf submodule
     # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules
     # :160000 000000 0263a9f... 0000000... D   autoconf
... more pick lines
pick 4c5070f Remove automake submodule
     # :100644 100644 28ddb02... f907328... M   .gitmodules
     # :160000 000000 9042530... 0000000... D   automake

Having the list of files shown below each commit, indented to reduce
cluttering the "pick" instruction, really does help in deciding the
reorder and squash candidates.

The files list came from this:

  git show --raw $sha1|awk '/^:/ {print " '"${comment_char}"'\t"$0}'

Thoughts?

nazri

[-- Attachment #2: 0001-rebase-Add-show-files-option.patch --]
[-- Type: text/x-patch, Size: 3169 bytes --]

From 4826875c14554d4fa5098ddf9499c33cb7b9001b Mon Sep 17 00:00:00 2001
From: Nazri Ramliy <ayiehere@gmail.com>
Date: Fri, 3 Oct 2014 09:59:38 +0800
Subject: [PATCH] rebase: Add --show-files option

---
 Documentation/git-rebase.txt |  8 ++++++++
 git-rebase--interactive.sh   | 13 +++++++++++++
 git-rebase.sh                |  5 +++++
 3 files changed, 26 insertions(+)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index f14100a..4996bc4 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -383,6 +383,14 @@ If `--autosquash` is used, "exec" lines will not be appended for
 the intermediate commits, and will only appear at the end of each
 squash/fixup series.
 
+-F::
+--show-files::
+	Append the list of affected files after each line creating a commit in
+	the history.
++
+This option can only be used with the `--interactive` option
+(see INTERACTIVE MODE below).
+
 --root::
 	Rebase all commits reachable from <branch>, instead of
 	limiting them with an <upstream>.  This allows you to rebase
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index b64dd28..32b4266 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -820,6 +820,11 @@ add_exec_commands () {
 	mv "$1.new" "$1"
 }
 
+print_affected_files () {
+	commit_sha1="$1"
+	git show --raw $commit_sha1|awk '/^:/ {print "     '"${comment_char}"' "$0}'
+}
+
 # The whole contents of this file is run by dot-sourcing it from
 # inside a shell function.  It used to be that "return"s we see
 # below were not inside any function, and expected to return
@@ -978,6 +983,10 @@ do
 	if test t != "$preserve_merges"
 	then
 		printf '%s\n' "${comment_out}pick $shortsha1 $rest" >>"$todo"
+		if test -n "$show_files"
+		then
+			print_affected_files $shortsha1 >> "$todo"
+		fi
 	else
 		sha1=$(git rev-parse $shortsha1)
 		if test -z "$rebase_root"
@@ -997,6 +1006,10 @@ do
 		then
 			touch "$rewritten"/$sha1
 			printf '%s\n' "${comment_out}pick $shortsha1 $rest" >>"$todo"
+			if test -n "$show_files"
+			then
+				print_affected_files $sha1 >> "$todo"
+			fi
 		fi
 	fi
 done
diff --git a/git-rebase.sh b/git-rebase.sh
index 55da9db..4968b2c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -24,6 +24,7 @@ m,merge!           use merging strategies to rebase
 i,interactive!     let the user edit the list of commits to rebase
 x,exec=!           add exec lines after each commit of the editable list
 k,keep-empty	   preserve empty commits during rebase
+F,show-files       Show files affected by each list of commit to rebase
 f,force-rebase!    force rebase even if branch is up to date
 X,strategy-option=! pass the argument through to the merge strategy
 stat!              display a diffstat of what changed upstream
@@ -88,6 +89,7 @@ autosquash=
 keep_empty=
 test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
 gpg_sign_opt=
+show_files=
 
 read_basic_state () {
 	test -f "$state_dir/head-name" &&
@@ -336,6 +338,9 @@ do
 	--gpg-sign=*)
 		gpg_sign_opt="-S${1#--gpg-sign=}"
 		;;
+	 --show-files|-F)
+		show_files=t
+		;;
 	--)
 		shift
 		break
-- 
2.1.0.244.g5796467.dirty

Re: [TOY PATCH]: rebase: Add --show-files option

[Chris Packham]

Hi,

On Fri, Oct 3, 2014 at 5:42 PM, Nazri Ramliy <ayiehere@gmail.com> wrote:
> Hi,
>
> When working on a "new feature branch" that touches a lot of files I
> tend to make commits that affect only single files, and for very small
> changes. Since at this stage I'm experimentating a lot - trying out
> ideas, etc. - the commits tend to grow a lot (could be 50-70
> individual commits, each modifying one or two files), and I don't
> think much about the commit message beside making a one-liner that
> explains only the gist.
>
> Most of the times I include the filename in the commit message to help
> me identify which commits should be squashed together later.
>
> Only when the feature seems to be functional that I git rebase the
> commits in order to shape the history into its final, proper form.
>
> When rebasing these upwards of 40+ commits, it is helpful if the
> rebase instruction sheet shows me the actual files that the commits
> affect so I made this patch (sorry I couldn't attach it inline since
> gmail eats all the tabs) that adds the "--show-files" option to
> git-rebase to achieve something to this effect:
>
> pick 996fa59 Remove autoconf submodule
>      # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules
>      # :160000 000000 0263a9f... 0000000... D   autoconf
> ... more pick lines
> pick 4c5070f Remove automake submodule
>      # :100644 100644 28ddb02... f907328... M   .gitmodules
>      # :160000 000000 9042530... 0000000... D   automake
>
> Having the list of files shown below each commit, indented to reduce
> cluttering the "pick" instruction, really does help in deciding the
> reorder and squash candidates.

Sounds neat. I do similar things and do sometimes lose track of which
files are being touched by multiple "fix compile error" commits. I
haven't actually looked at your patch because gmail can't display it
in-line but it's a feature I'd use.

>
> The files list came from this:
>
>   git show --raw $sha1|awk '/^:/ {print " '"${comment_char}"'\t"$0}'
>
> Thoughts?
>
> nazri

Re: [TOY PATCH]: rebase: Add --show-files option

[Junio C Hamano]

Nazri Ramliy <ayiehere@gmail.com> writes:

> When rebasing these upwards of 40+ commits, it is helpful if the
> rebase instruction sheet shows me the actual files that the commits
> affect so I made this patch (sorry I couldn't attach it inline since
> gmail eats all the tabs) that adds the "--show-files" option to
> git-rebase to achieve something to this effect:
>
> pick 996fa59 Remove autoconf submodule
>      # :100644 100644 cfc8a25... 28ddb02... M   .gitmodules
>      # :160000 000000 0263a9f... 0000000... D   autoconf
> ... more pick lines
> pick 4c5070f Remove automake submodule
>      # :100644 100644 28ddb02... f907328... M   .gitmodules
>      # :160000 000000 9042530... 0000000... D   automake
>
> Having the list of files shown below each commit, indented to reduce
> cluttering the "pick" instruction, really does help in deciding the
> reorder and squash candidates.

Sounds like a good idea to give helpful information in a comment
form to the insn sheet.

Other than two minor points:

 - If I were doing this, I would have used "diff-tree --stat
   --summary" instead of "show --raw".  You can tell
   deletion/addition by paying attention to 0's and also mode
   changes, but the information density of --raw for human
   consumption is rather low.

 - Regardless of the above, I am not sure if dumping listing of 100+
   paths modified would really help, and it might make sense to cap
   the number of paths displayed for each change.

I didn't look at your implementation at all, though.