From: git@matthieu-moy.fr
To: Jeff King <peff@peff.net>
Cc: Aaron Greenberg <p@aaronjgreenberg.com>,
git@matthieu-moy.fr, git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v2] branch: implement shortcut to delete last branch
Date: Mon, 26 Mar 2018 14:41:49 +0200 [thread overview]
Message-ID: <86r2o7nh4i.fsf@matthieu-moy.fr> (raw)
In-Reply-To: <20180326081036.GA18714@sigill.intra.peff.net>
Thanks for Cc-ing me, and sorry for not being very responsive these
days :-\.
Jeff King writes:
> On Fri, Mar 23, 2018 at 10:40:34PM +0000, Aaron Greenberg wrote:
>
>> I can appreciate Matthieu's points on the use of "-" in destructive
>> commands. As of this writing, git-merge supports the "-" shorthand,
>> which while not destructive, is at least _mutative_. Also,
>> "git branch -d" is not destructive in the same way that "rm -rf" is
>> destructive since you can recover the branch using the reflog.
>
> There's a slight subtlety there with the reflog, because "branch -d"
> actually _does_ delete the reflog for the branch. By definition if
> you've found the branch with "-" then it was just checked out, so you at
> least have the old tip. But the branch's whole reflog is gone for good.
>
> That said, I'd still be OK with it.
I don't have objection either.
Anyway, we're supporting this "-" shortcut in more and more commands
(partly because it's a nice microproject, but it probably makes sense),
so the "consistency" argument becomes more and more important, and is
probably more important than the (relative) safety of not having the
shortcut.
>> One thing to consider is that approval of this patch extends the
>> implementation of the "-" shorthand in a piecemeal, rather than
>> consistent, way (implementing it in a consistent way was the goal of
>> the patch set you mentioned in your previous email.) Is that okay? Or
>> is it better to pick up the consistent approach where it was left?
>
> I don't have a real opinion on whether it should be implemented
> everywhere or not. But IMHO it's OK to do it piecemeal for now either
> way, unless we're really sure it's time to move to respecting it
> everywhere. Because we can always convert a
> piecemeal-but-covers-everything state to centralized parsing as a
> cleanup.
Not sure whether it's already been mentionned here, but a previous
attempt is here:
https://public-inbox.org/git/1488007487-12965-1-git-send-email-kannan.siddharth12@gmail.com/
My understanding is that the actual code is quite straightforward, but
1) it needs a few cleanup patches to be done correctly, and 2) there are
corner-cases to deal with like avoiding a commit message like "merge
branch '-' into 'foo'". Regarding 2), any piecemeal implementation with
proper tests is a step in the right direction.
--
Matthieu Moy
https://matthieu-moy.fr/
next prev parent reply other threads:[~2018-03-26 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 2:09 [PATCH] branch: implement shortcut to delete last branch Aaron Greenberg
2018-03-23 2:09 ` Aaron Greenberg
2018-03-23 8:56 ` Jeff King
2018-03-23 9:00 ` Jeff King
2018-03-23 22:40 ` [PATCH v2] " Aaron Greenberg
2018-03-23 22:40 ` [PATCH] " Aaron Greenberg
2018-03-26 8:10 ` [PATCH v2] " Jeff King
2018-03-26 12:41 ` git [this message]
2018-03-26 16:49 ` 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=86r2o7nh4i.fsf@matthieu-moy.fr \
--to=git@matthieu-moy.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=p@aaronjgreenberg.com \
--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 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.