git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: liam Beguin <liambeguin@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH v2] rebase -i: add config to abbreviate command-names
Date: Wed, 26 Apr 2017 21:20:51 -0400	[thread overview]
Message-ID: <1493256051.29673.35.camel@gmail.com> (raw)
In-Reply-To: <CACBZZX49HZbQ32TTM8V3hSHwEJxkewV3VwfJO75u+D-9RmsOtw@mail.gmail.com>

Hi Ævar,

On Wed, 2017-04-26 at 17:24 +0200, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 25, 2017 at 6:43 AM, Liam Beguin <liambeguin@gmail.com> wrote:
> > Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i`
> > to abbreviate the command-names in the instruction list.
> > 
> > This means that `git rebase -i` would print:
> >     p deadbee The oneline of this commit
> >     ...
> > 
> > instead of:
> >     pick deadbee The oneline of this commit
> >     ...
> > 
> > Using a single character command-name allows the lines to remain
> > aligned, making the whole set more readable.
> 
> Aside from the existing comments about the commit message from others,
> you should be noting that we *already* have these abbreviations for
> all the todo list options, and we note this in append_todo_help.
> 
> 
> > +rebase.abbrevCmd::
> > +       If set to true, `git rebase -i` will abbreviate the command-names in the
> > +       instruction list. This means that instead of looking like this,
> > +
> > [...]
> > +rebase.abbrevCmd::
> > +       If set to true, `git rebase -i` will abbreviate the command-names in the
> > +       instruction list. This means that instead of looking like this,
> > [...]
> 
> Better to split this out into a new *.txt file and use the include::*
> facility (grep for it) rather than copy/pasting this entirely across
> two files.
> 

Thanks for pointing this out, I'll update the documentation

> >  OPTIONS
> >  -------
> >  --onto <newbase>::
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 2c9c0165b5ab..9f3e82b79615 100644
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -1210,6 +1210,10 @@ else
> >         revisions=$onto...$orig_head
> >         shortrevisions=$shorthead
> >  fi
> > +
> > +rebasecmd=pick
> > +test "$(git config --bool --get rebase.abbrevCmd)" = true && rebasecmd=p
> 
> Rather than hardcoding "p" here maybe it would be worthhwile to make
> that into a variable used both here and in append_todo_help, maybe
> not...
> 

I'm not sure I understand, do you mean that the option should also affect the
message added by append_todo_help ?

> >  format=$(git config --get rebase.instructionFormat)
> >  # the 'rev-list .. | sed' requires %m to parse; the instruction requires %H to parse
> >  git rev-list $merges_option --format="%m%H ${format:-%s}" \
> > @@ -1228,7 +1232,7 @@ do
> > 
> >         if test t != "$preserve_merges"
> >         then
> > -               printf '%s\n' "${comment_out}pick $sha1 $rest" >>"$todo"
> > +               printf '%s\n' "${comment_out}${rebasecmd} $sha1 $rest" >>"$todo"
> >         else
> >                 if test -z "$rebase_root"
> >                 then
> > @@ -1246,7 +1250,7 @@ do
> >                 if test f = "$preserve"
> >                 then
> >                         touch "$rewritten"/$sha1
> > -                       printf '%s\n' "${comment_out}pick $sha1 $rest" >>"$todo"
> > +                       printf '%s\n' "${comment_out}${rebasecmd} $sha1 $rest" >>"$todo"
> >                 fi
> >         fi
> >  done
> 
> I haven't tried applying & running this patch, but it seems you
> definitely missed the case where --autosquash will add fixup or
> squash, that should be f or s with your patch, but you didn't change
> that code. See the rearrange_squash function.
> 
> Ditto for turning "exec" into "e" with --exec.
> 

I noticed this yesterday, I'll add both cases the next iteration.

> But if the motivation for this entire thing is to make sure the
> commands are aligned this doesn't fix that, because the sha1s can be
> of different lengths. So as others have pointed out maybe this entire
> thing should be dropped & replaced with some bool command to align the
> todo list, maybe turning that on by default.
> 
> Unless the real unstated reason is to make this easier to edit in vim
> or something, in which case this approach seems reasonable.

Keeping things aligned was the first motivation but the fact that it also
makes changing the action faster is also nice to have. I didn't think it
would help justify the patch.
The SHA1s not having the same length can easily be 'fixed' by setting a
higher value for 'core.abbrev'. 

Thanks, 
Liam 

      reply	other threads:[~2017-04-27  1:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  3:23 [PATCH] rebase -i: add config to abbreviate command name Liam Beguin
2017-04-24 10:26 ` Johannes Schindelin
2017-04-24 11:04   ` liam BEGUIN
2017-04-25  2:57   ` liam BEGUIN
2017-04-25 19:45     ` Johannes Schindelin
2017-04-25 22:58       ` liam BEGUIN
2017-04-24 12:29 ` Jeff King
2017-04-25  4:37 ` [PATCH v2] rebase -i: add config to abbreviate command-names Liam Beguin
2017-04-25  6:29   ` Junio C Hamano
2017-04-25  8:29     ` Jacob Keller
2017-04-25 23:34       ` liam Beguin
2017-04-26  2:09       ` Junio C Hamano
2017-04-25  9:57   ` Andreas Schwab
2017-04-25 13:59     ` Mike Rappazzo
2017-04-25 10:34   ` Philip Oakley
2017-04-25  4:43 ` Liam Beguin
2017-04-25  9:53   ` Andreas Schwab
2017-04-25 21:23     ` Johannes Schindelin
2017-04-25 22:56       ` liam BEGUIN
2017-04-25 20:08   ` Johannes Schindelin
2017-04-26  0:13     ` liam Beguin
2017-04-26  1:47       ` Jeff King
2017-04-26  3:59         ` Junio C Hamano
2017-04-26  9:25           ` Johannes Schindelin
2017-04-27  0:37             ` Junio C Hamano
2017-04-26  9:28       ` Johannes Schindelin
2017-04-26 15:24   ` Ævar Arnfjörð Bjarmason
2017-04-27  1:20     ` liam Beguin [this message]

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=1493256051.29673.35.camel@gmail.com \
    --to=liambeguin@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).