On Mon, Aug 19, 2019 at 12:12:32PM -0400, Derrick Stolee wrote:
> On 8/19/2019 11:02 AM, SZEDER Gábor wrote:
> > On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
> >> Note that I don't include the "without patch" numbers. For some
> >> reason the path provided is particularly nasty a
On 8/19/2019 11:02 AM, SZEDER Gábor wrote:
> On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
>> Note that I don't include the "without patch" numbers. For some
>> reason the path provided is particularly nasty and caused 20,000+
>> missing blobs to be downloaded one-by-one (remember
On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
> Note that I don't include the "without patch" numbers. For some
> reason the path provided is particularly nasty and caused 20,000+
> missing blobs to be downloaded one-by-one (remember: VFS for Git
> has many partial-clone-like beha
ting, which I don't usually do, hence the RFC.
>>
>> Hi Szeder,
>>
>> Thanks for sending this series! I'm particularly excited about it
>> because we recently got a bug report from a user in the Windows OS
>> repo about "git log -L" being very
nding this series! I'm particularly excited about it
> because we recently got a bug report from a user in the Windows OS
> repo about "git log -L" being very slow. I put it on the backlog [1]
> but haven't had time to investigate it myself. After we are done
> updati
On 8/18/2019 2:28 PM, SZEDER Gábor wrote:
> To be clear: this patch doesn't actually optimize the line-level log,
> but merely moves most of the work from the preprocessing step to the
> history travelsal, so the commits modifying the line range can be
s/travelsal/traversal/
-Stolee
given revision
> range this preprocessing can result in a significant delay before
> the first commit is shown.
>
> - Limiting the number of displayed commits (e.g. 'git log -3 -L...')
> doesn't limit the amount of work during preprocessing, because
>
t the rest deals with history traversal and parent
> rewriting, which I don't usually do, hence the RFC.
Hi Szeder,
Thanks for sending this series! I'm particularly excited about it
because we recently got a bug report from a user in the Windows OS
repo about "git log -L" being very
shown.
- Limiting the number of displayed commits (e.g. 'git log -3 -L...')
doesn't limit the amount of work during preprocessing, because
that limit is applied during history traversal. Alas, by that
point this expensive preprocessing step has already churned
throug
R Gábor (5):
completion: offer '--(no-)patch' among 'git log' options
line-log: remove unused fields from 'struct line_log_data'
t4211-line-log: add tests for parent oids
line-log: more responsive, incremental 'git log -L'
line-log: try to use generation n
Johannes Schindelin writes:
> Hi Stolee,
>
> On Mon, 1 Jul 2019, Derrick Stolee via GitGitGadget wrote:
>
>> From: Derrick Stolee
>>
>> Using 'ls -l' and parsing the columns to find file sizes is
>> problematic when the platform could report the ow
Hi Stolee,
On Mon, 1 Jul 2019, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> Using 'ls -l' and parsing the columns to find file sizes is
> problematic when the platform could report the owner as a name
> with spaces. Instead, use the '
From: Derrick Stolee
Using 'ls -l' and parsing the columns to find file sizes is
problematic when the platform could report the owner as a name
with spaces. Instead, use the 'test-tool path-utils file-size'
command to list only the sizes.
Reported-by: Johannes Sixt
-replace.sh
+++ b/t/t6050-replace.sh
@@ -393,9 +393,11 @@ test_expect_success 'replace ref cleanup' '
'
test_expect_success '--graft with and without already replaced object' '
- test $(git log --oneline | wc -l) = 7 &&
+ git log --onel
7;git commit-tree omits duplicated
parent in a commit' '
parent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
test "z$commit0" = "z$parent" &&
git show --pretty=raw $commit2 >actual &&
/checkout.c
index 6d0b2ef565..d63116b686 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1376,7 +1376,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL(&#
-replace.sh
@@ -393,9 +393,11 @@ test_expect_success 'replace ref cleanup' '
'
test_expect_success '--graft with and without already replaced object' '
- test $(git log --oneline | wc -l) = 7 &&
+ git log --oneline >log &&
+
)
OPT_CALLBACK_F(0, "follow", options, NULL,
N_("continue listing the history of a file
beyond renames"),
PARSE_OPT_NOARG, diff_opt_follow),
+ OPT_INTEGER('l', NULL, &options->rename_
100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1376,7 +1376,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL('l', NULL, &opts->n
)
OPT_CALLBACK_F(0, "follow", options, NULL,
N_("continue listing the history of a file
beyond renames"),
PARSE_OPT_NOARG, diff_opt_follow),
+ OPT_INTEGER('l', NULL, &options->rename_
Ævar Arnfjörð Bjarmason writes:
> No objections to changing this, but I don't think it's the fault of a
> commit message if someone reading it doesn't get an explanation for a
> future unrelated improvement.
>
> The times when a commit should have such an explanation are cases like
> e.g. introdu
git commit-tree omits
>> > duplicated parent in a commit' '
>> >parent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
>> >test "z$commit0" = "z$parent" &&
>> >git sh
-n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
> > test "z$commit0" = "z$parent" &&
> > git show --pretty=raw $commit2 >actual &&
> > - numparent=$(sed -n -e "s/^
test "z$commit0" = "z$parent" &&
> git show --pretty=raw $commit2 >actual &&
> - numparent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | wc -l)
> &&
> - test $numparent = 1
> + sed -n -e &quo
7;git commit-tree omits duplicated
parent in a commit' '
parent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
test "z$commit0" = "z$parent" &&
git show --pretty=raw $commit2 >actual &&
/checkout.c
index bd94b04303..85fc60f5f2 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1376,7 +1376,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL(&#
t-tree omits duplicated
> > parent in a commit' '
> > - numparent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | wc
> > -l) &&
> > - test $numparent = 1
> > + sed -n -e "s/^parent //p" -e "/^a
nt=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | wc
> -l) &&
> - test $numparent = 1
> + sed -n -e "s/^parent //p" -e "/^author /q" actual | wc -l >numparent
> &&
> + test_line_count = 1 numparent
T
=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
test "z$commit0" = "z$parent" &&
git show --pretty=raw $commit2 >actual &&
- numparent=$(sed -n -e "s/^parent //p" -e "/^author /q&q
100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1372,7 +1372,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL('l', NULL, &opts->n
On February 25, 2019 12:18, Jeff King wrote:
> To: Matthew Booth
> Cc: git@vger.kernel.org
> Subject: Re: [BUG] git log -L ... -s does not suppress diff output
>
> On Mon, Feb 25, 2019 at 05:03:50PM +, Matthew Booth wrote:
>
> > Example output:
> >
> > =
On Mon, Feb 25, 2019 at 05:03:50PM +, Matthew Booth wrote:
> Example output:
>
> =
> $ git --version
> git version 2.20.1
>
> $ git log -L 2957,3107:nova/compute/manager.py -s
> commit 35ce77835bb271bad3c18eaf22146edac3a42ea0
>
>
> diff --git
Example output:
=
$ git --version
git version 2.20.1
$ git log -L 2957,3107:nova/compute/manager.py -s
commit 35ce77835bb271bad3c18eaf22146edac3a42ea0
diff --git a/nova/compute/manager.py b/nova/compute/manager.py
--- a/nova/compute/manager.py
+++ b/nova/compute/manager.py
@@ -2937,152
/checkout.c
index f6de232922..f7d8fa7caa 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1357,7 +1357,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL(&#
/checkout.c
index 2251883a88..db9a2692db 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1357,7 +1357,6 @@ static struct option *add_common_switch_branch_options(
struct checkout_opts *opts, struct option *prevopts)
{
struct option options[] = {
- OPT_BOOL(&#
)
OPT_CALLBACK_F(0, "follow", options, NULL,
N_("continue listing the history of a file
beyond renames"),
PARSE_OPT_NOARG, diff_opt_follow),
+ OPT_INTEGER('l', NULL, &options->rename_
On Tue, Jan 15 2019, tbo...@web.de wrote:
> From: Torsten Bögershausen
>
> From `man sed` (on a Mac OS X box):
> The -E, -a and -i options are non-standard FreeBSD extensions and may not be
> available
> on other operating systems.
>
> From `man sed` on a Linux box:
> REGULAR EXPRESSIONS
>
;
Please update the new message to be more consistent with existing
surrounding error messages. For instance:
err 'sed -i/-a/-l/-E not portable (use only -e/-f/-n)'
or something. Thanks.
From: Torsten Bögershausen
From `man sed` (on a Mac OS X box):
The -E, -a and -i options are non-standard FreeBSD extensions and may not be
available
on other operating systems.
From `man sed` on a Linux box:
REGULAR EXPRESSIONS
POSIX.2 BREs should be supported, but they aren't completel
On Tue, Oct 02, 2018 at 06:56:29AM +, peter.doll...@mt.com wrote:
> Please see my original observation below.
> Is it possible, to extend the git-log syntax in the way, that it
> accepts the short -L option (without :file) of blame in unique cases
> (only one file is logged or
Please see my original observation below.
Is it possible, to extend the git-log syntax in the way, that it accepts the
short -L option (without :file) of blame in unique cases (only one file is
logged or respectively the -L expression may be valid for all logged files)? It
would be nice for
On Thu, Aug 30 2018, Jeff King wrote:
> On Thu, Aug 30, 2018 at 01:29:53PM -0700, Junio C Hamano wrote:
>
>> >> > I do not know if the documentation that is shipped in 2.20 should
>> >> > talk about how the old world looked like, though. `-l` was a short
&g
On Thu, Aug 30, 2018 at 01:29:53PM -0700, Junio C Hamano wrote:
> >> > I do not know if the documentation that is shipped in 2.20 should
> >> > talk about how the old world looked like, though. `-l` was a short
> >> > for `--create-reflog` is worth saying, b
Jeff King writes:
> On Thu, Aug 30, 2018 at 09:53:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > In the SYNOPSIS section we still see "[-l]" listed; that also must
>> > be replaced with "--create-reflog", or just dropped, as that is the
>>
On Thu, Aug 30, 2018 at 09:53:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the SYNOPSIS section we still see "[-l]" listed; that also must
> > be replaced with "--create-reflog", or just dropped, as that is the
> > default.
>
> Oh yes, it seems
On Thu, Aug 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> +-l::
>>> --list::
>>> List branches. With optional `...`, e.g. `git
>>> branch --list 'maint-*'`, list only the branches that match
>>
Ævar Arnfjörð Bjarmason writes:
>> +-l::
>> --list::
>> List branches. With optional `...`, e.g. `git
>> branch --list 'maint-*'`, list only the branches that match
>
> I think it's better to have something like this on top:
>
&
form `--no-create-reflog` only overrides an earlier
> `--create-reflog`, but currently does not negate the setting of
> `core.logAllRefUpdates`.
> -+
> -The `-l` option is a deprecated synonym for `--create-reflog`.
>
> -f::
> --force::
> @@ -156,6 +154,7 @@ Thi
;copy a branch, even if target
> exists"), 2),
> OPT_BOOL(0, "list", &list, N_("list branch names")),
> - OPT_BOOL('l', "create-reflog", &reflog, N_("create the branch's
> reflog")),
> +
On Fri, Jun 22, 2018 at 05:24:14AM -0400, Jeff King wrote:
> Let's deprecate "-l" in hopes of eventually re-purposing it
> to "--list".
>
> Signed-off-by: Jeff King
> ---
> diff --git a/builtin/branch.c b/builtin/branch.c
> @@ -36,6 +36,7 @@
The other "mode" options of git-branch have short-option
aliases that are easy to type (e.g., "-d" and "-m"). Let's
give "--list" the same treatment.
This also makes it consistent with the similar "git tag -l"
option.
We didn't do th
The "-l" option is short for "--create-reflog". This has
caused much confusion over the years. Most people expect it
to work as "--list", because that would match the other
"mode" options like -d/--delete and -m/--move, as well as
the similar -l/--list opt
In preparation for deprecating "-l", let's make sure we're
using the recommended option ourselves.
This patch just mechanically converts "branch -l" to "branch
--create-reflog". Note that with the exception of the
actual "--create-reflog" test, w
This series replaces the contents of jk/branch-l-0-deprecation,
jk/branch-l-1-removal, and jk/branch-l-2-reincarnation.
It implements the idea discussed in the subthread in:
https://public-inbox.org/git/xmqqzi0hety4@gitster-ct.c.googlers.com/
Namely that "branch -l" would
On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote:
> > if (used_deprecated_reflog_option) {
> > - warning("the '-l' alias for '--create-reflog' is
> > deprecated;");
> > -
On Fri, May 25, 2018 at 4:40 AM, Jeff King wrote:
> -- >8 --
> Subject: [PATCH] branch: customize "-l" warning in list mode
>
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
&g
Jeff King writes:
> So I think you're proposing:
>
> - step 0: warn about "-l" when it actually gets used, and otherwise
> continue ignoring
>
> - step 1: turn "-l" into "--list"
>
> - step 2: there is no step 2
>
> .
On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote:
Jeff King writes:
Right, what I meant by "gentler" is that we continue to perform the same
behavior as the old version, alongside the warning. It's arguable here
because running "git branch -l" has _always_ be
On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, what I meant by "gentler" is that we continue to perform the same
> > behavior as the old version, alongside the warning. It's arguable here
> > because ru
On Wed, May 30, 2018 at 11:48:32AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> - if (list) {
> >> - warning("the '-l' option is an alias for
> >> '--create-reflog' and");
> >>
Jeff King writes:
> Right, what I meant by "gentler" is that we continue to perform the same
> behavior as the old version, alongside the warning. It's arguable here
> because running "git branch -l" has _always_ been wrong. It's just wrong
> in a
Jeff King writes:
>> -if (list) {
>> -warning("the '-l' option is an alias for
>> '--create-reflog' and");
>> -warning("has no effect in list mode. This option will
>> soon be&q
On Tue, May 29, 2018 at 05:20:29PM -0400, Jeff King wrote:
> Thanks. There's one bit missing here, because it did not cause a textual
> conflict during the rebase (but it's now dead code). Patch below (to be
> squashed to the tip of jk/branch-l-1-removal).
it from behind the pager).
>
> With these two patches queued on top of jk/branch-l-0-deprecation,
> the follow-up patches jk/branch-l-1-removal that makes 'branch -l'
> to fail and then jk/branch-l-2-reincarnation that makes 'branch -l'
> a synonym to 'branch --li
On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote:
> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme" from your sugges
Elijah Newren writes:
>> I'd expect that a reader of the commit who cares enough to bother to
>> wonder by looking at the patch and seeing that 2 became 3 would know
>> why already. And a reader of the resulting file would not know that
>> the 3 used to be 2, and won't be helped by "we used to c
On Friday 25 May 2018 08:10 AM, Jeff King wrote:
> Subject: [PATCH] branch: customize "-l" warning in list mode
>
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in t
On Friday 25 May 2018 01:01 AM, Jeff King wrote:
> On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote:
>
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extr
Jeff King writes:
>> By the way, this is one of these times when I feel that we should
>> have a better multi-line message support in die/error/warning/info
>> functions. Ideally, I should be able to write
>>
>> warning(_("the '-l' o
Junio C Hamano writes:
> With these two patches queued on top of jk/branch-l-0-deprecation,
> the follow-up patches jk/branch-l-1-removal that makes 'branch -l'
> to fail and then jk/branch-l-2-reincarnation that makes 'branch -l'
> a synonym to 'branch --li
Junio C Hamano writes:
> Yup, thanks for being extra explicit. I do imagine there are quite
> a few of us who would be puzzled without this update (but with the
> previous one to unhide it from behind the pager).
With these two patches queued on top of jk/branch-l-0-deprecation,
the
On Thu, May 24, 2018 at 6:17 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> -test 2 = $(git ls-files -s | wc -l) &&
>>> -test 2 = $(git ls-files -u | wc -l) &&
>>> -test 2 = $(git ls-files -o | wc -l) &
On Thu, May 24, 2018 at 6:17 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> -test 2 = $(git ls-files -s | wc -l) &&
>>> -test 2 = $(git ls-files -u | wc -l) &&
>>> -test 2 = $(git ls-files -o | wc -l) &
On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> - warning("the '-l' alias for '--create-reflog' is deprecated;");
> >> - warning("it will be rem
Junio C Hamano writes:
>> -warning("the '-l' alias for '--create-reflog' is deprecated;");
>> -warning("it will be removed in a future version of Git");
>> + if (list) {
>> +wa
Jeff King writes:
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in that command does (and the "-l" becomes a
> silent noop).
>
> Since afc968e579 (branch: deprecate &
On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme"
Jeff King writes:
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extreme" from your suggested patch would only affect "branch -l".
> Still, I think I
SZEDER Gábor writes:
>> -test 2 = $(git ls-files -s | wc -l) &&
>> -test 2 = $(git ls-files -u | wc -l) &&
>> - test 2 = $(git ls-files -o | wc -l) &&
>
> Here 'git ls-files -o' should have listed two
On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote:
> On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote:
>
> > > On the other hand, I'm not sure this is that big a deal. The point of
> > > the deprecation warning is to catch people who are act
On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote:
> > On the other hand, I'm not sure this is that big a deal. The point of
> > the deprecation warning is to catch people who are actually trying to
> > use "-l" as "--create-reflog&quo
>> test_must_fail git merge -s recursive R2^0 &&
>>
>> - test 2 = $(git ls-files -s | wc -l) &&
>> - test 2 = $(git ls-files -u | wc -l) &&
>> - test 2 = $(git ls-files -o | wc -l) &&
&g
rst, the error
is emitted and then the pager kicks in to list the branches.
> On the other hand, I'm not sure this is that big a deal. The point of
> the deprecation warning is to catch people who are actually trying to
> use "-l" as "--create-reflog", and that case do
gt; @@ -65,9 +65,12 @@ test_expect_success 'merge simple rename+criss-cross with
>> no modifications' '
>>
>> test_must_fail git merge -s recursive R2^0 &&
>>
>> - test 2 = $(git ls-files -s | wc -l) &&
>>
ns' '
>
> test_must_fail git merge -s recursive R2^0 &&
>
> - test 2 = $(git ls-files -s | wc -l) &&
> - test 2 = $(git ls-files -u | wc -l) &&
> - test 2 = $(git ls-files -o | wc -l) &&
recursive R2^0 &&
- test 2 = $(git ls-files -s | wc -l) &&
- test 2 = $(git ls-files -u | wc -l) &&
- test 2 = $(git ls-files -o | wc -l) &&
+ git ls-files -s >out &&
+ test_
atic int deprecated_reflog_option_cb(const struct option *opt,
const char *arg, int unset)
{
- warning("the '-l' alias for '--create-reflog' is deprecated;");
- warning("it will be removed in a future version of
t;
>> PAGER=less LESS="--no-init --quit-if-one-screen" git branch -l
>>
>> ...
>>
>> So I think this is probably OK for most users, if the have very few
>> branches they'll see it, and then if they use default pager settings
>> they'll
Hi Ævar,
On Thursday 17 May 2018 03:18 PM, Ævar Arnfjörð Bjarmason wrote:
> I've ended up with that $LESS setting via hackery over the years, so
> maybe I'm doing something retarded, minimal test case:
>
> PAGER=less LESS="--no-init --quit-if-one-screen"
On Thu, May 17 2018, Kaartic Sivaraam wrote:
> On Thursday 17 May 2018 11:31 AM, Junio C Hamano wrote:
>> * jk/branch-l-0-deprecation (2018-03-26) 3 commits
>>
>> ...
>>
>> The "-l" option in "git branch -l" is an unfortunate short-hand fo
On Thursday 17 May 2018 11:31 AM, Junio C Hamano wrote:
> * jk/branch-l-0-deprecation (2018-03-26) 3 commits
>
> ...
>
> The "-l" option in "git branch -l" is an unfortunate short-hand for
> "--create-reflog", but many users, both old and new, so
;
>> [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]: bra
; [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"
The entire series looks good to me. FWIW,
Reviewed-by: Eric Sunshine
The other "mode" options of git-branch have short-option
aliases that are easy to type (e.g., "-d" and "-m"). Let's
give "--list" the same treatment.
This also makes it consistent with the similar "git tag -l"
option.
We didn't do th
We marked the "-l" option as deprecated back in . Now that sufficient time has passed, let's follow
through and get rid of it.
Signed-off-by: Jeff King
---
I'll need some help from the maintainer on the commit message. :)
builtin/branch.c | 15 ---
1 file c
The "-l" option is short for "--create-reflog". This has
caused much confusion over the years. Most people expect it
to work as "--list", because that would match the other
"mode" options like -d/--delete and -m/--move, as well as
the similar -l/--list opt
In preparation for deprecating "-l", let's make sure we're
using the recommended option ourselves.
This patch just mechanically converts "branch -l" to "branch
--create-reflog". Note that with the exception of the
actual "--create-reflog" test, w
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 wo
Jeff King writes:
> IMHO we should do one of:
>
> 1. Nothing. ;)
>
> 2. Complain about "-l" in list mode to help educate users about the
> current craziness.
Nah. We've seen this, perhaps not often but enough times over long
period of time. The ab
On Sunday 25 March 2018 11:18 AM, Eric Sunshine wrote:
> On Sun, Mar 25, 2018 at 09:11:34AM +0530, Kaartic Sivaraam wrote:
>> On Sunday 25 March 2018 07:04 AM, Eric Sunshine wrote:
>>> Can we have a couple new tests: one checking "git branch --list" for
>>> the typical case (when rebasing off a nam
1 - 100 of 383 matches
Mail list logo
