From: Jeff King <peff@peff.net>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Kaartic Sivaraam <kaartic.sivaraam@gmail.com>,
Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch
Date: Mon, 26 Mar 2018 03:25:05 -0400 [thread overview]
Message-ID: <20180326072505.GA12436@sigill.intra.peff.net> (raw)
In-Reply-To: <CA+P7+xr2-OidiX9ve6GwOR4pSOe4Gn=A3Aow5L=oLZgZE+XqMQ@mail.gmail.com>
On Sun, Mar 25, 2018 at 12:15:42AM -0700, Jacob Keller wrote:
> > 3. Drop "-l" (probably with a deprecation period); it seems unlikely
> > to me that anybody uses it for branch creation, and this would at
> > least reduce the confusion (then it would just be "so why don't we
> > have -l" instead of "why is -l not what I expect").
>
> Personally, I'd prefer this, because it's minimal effort on scripts
> part to fix themselves to use the long option name for reflog, and
> doesn't cause that much heart burn.
>
> >
> > 4. Repurpose "-l" as a shortcut for --list (also after a deprecation
> > period). This is slightly more dangerous in that it may confuse
> > people using multiple versions of Git that cross the deprecation
> > line. But that's kind of what the deprecation period is for...
>
> I don't think this is particularly all that valuable, since we default
> to list mode so it only helps if you want to pass an argument to the
> list mode (since otherwise we'd create a branch). Maybe it could be
> useful, but if we did it, I'd do it as a sort of double deprecation
> period where we use one period to remove the -l functionality
> entirely, before adding anything back. I think the *gain* of having -l
> is not really worth it though.
OK, so here's some patches. We could do the first three now, wait a
while before the fourth, and then wait a while (or never) on the fifth.
[1/5]: t3200: unset core.logallrefupdates when testing reflog creation
[2/5]: t: switch "branch -l" to "branch --create-reflog"
[3/5]: branch: deprecate "-l" option
[4/5]: branch: drop deprecated "-l" option
[5/5]: branch: make "-l" a synonym for "--list"
Documentation/git-branch.txt | 3 ++-
builtin/branch.c | 4 ++--
t/t1410-reflog.sh | 4 ++--
t/t3200-branch.sh | 34 +++++++++++++++++-----------------
4 files changed, 23 insertions(+), 22 deletions(-)
-Peff
next prev parent reply other threads:[~2018-03-26 7:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-24 18:38 [PATCH] branch -l: print useful info whilst rebasing a non-local branch Kaartic Sivaraam
2018-03-25 1:34 ` Eric Sunshine
2018-03-25 3:41 ` Kaartic Sivaraam
2018-03-25 4:10 ` Jeff King
2018-03-25 4:13 ` Eric Sunshine
2018-03-25 4:28 ` Eric Sunshine
2018-03-25 4:33 ` Jeff King
2018-03-25 6:54 ` Kaartic Sivaraam
2018-03-25 7:15 ` Jacob Keller
2018-03-26 7:25 ` Jeff King [this message]
2018-03-26 7:26 ` [PATCH 1/5] t3200: unset core.logallrefupdates when testing reflog creation Jeff King
2018-03-26 7:26 ` [PATCH 2/5] t: switch "branch -l" to "branch --create-reflog" Jeff King
2018-03-26 7:28 ` [PATCH 3/5] branch: deprecate "-l" option Jeff King
2018-03-26 7:29 ` [PATCH 4/5] branch: drop deprecated " Jeff King
2018-03-26 7:29 ` [PATCH 5/5] branch: make "-l" a synonym for "--list" Jeff King
2018-03-26 7:44 ` [PATCH] branch -l: print useful info whilst rebasing a non-local branch Eric Sunshine
2018-03-26 18:38 ` Jacob Keller
2018-03-25 17:06 ` Junio C Hamano
2018-03-25 5:48 ` Eric Sunshine
2018-03-25 7:36 ` Kaartic Sivaraam
2018-04-03 4:31 ` [PATCH v2 1/2] branch --list: print useful info whilst interactive rebasing a detached HEAD Kaartic Sivaraam
2018-04-03 4:31 ` [PATCH v2 2/2] t3200: verify "branch --list" sanity when rebasing from " Kaartic Sivaraam
2018-04-03 8:00 ` Eric Sunshine
2018-04-03 12:58 ` Kaartic Sivaraam
2018-04-03 14:47 ` [PATCH v3 " Kaartic Sivaraam
2018-04-04 8:09 ` Eric Sunshine
2018-04-03 5:02 ` [PATCH v2 0/2] branch --list: print useful info whilst interactive rebasing a " Kaartic Sivaraam
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=20180326072505.GA12436@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jacob.keller@gmail.com \
--cc=kaartic.sivaraam@gmail.com \
--cc=sunshine@sunshineco.com \
/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).