All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Packham <judge.packham@gmail.com>
To: Nazri Ramliy <ayiehere@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [TOY PATCH]: rebase: Add --show-files option
Date: Fri, 3 Oct 2014 20:42:10 +1300	[thread overview]
Message-ID: <CAFOYHZDDq0UfvznUTx5FMaX97kK0nJxYAJ_-sj_Mu+x3o3ftCg@mail.gmail.com> (raw)
In-Reply-To: <CAEY4ZpN4HEo-Csf1UjpGX4YLKWRrywinUemeZFZdVg=ZtTsaqA@mail.gmail.com>

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

  reply	other threads:[~2014-10-03  7:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-03  4:42 [TOY PATCH]: rebase: Add --show-files option Nazri Ramliy
2014-10-03  7:42 ` Chris Packham [this message]
2014-10-03 19:11 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFOYHZDDq0UfvznUTx5FMaX97kK0nJxYAJ_-sj_Mu+x3o3ftCg@mail.gmail.com \
    --to=judge.packham@gmail.com \
    --cc=ayiehere@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.