From: Jeff King <peff@peff.net>
To: Martin von Zweigbergk <martinvonz@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Maarten de Vries <maarten@de-vri.es>,
git mailing list <git@vger.kernel.org>
Subject: [PATCH 0/2] reset -p and unborn branches
Date: Fri, 25 Oct 2013 02:51:17 -0400 [thread overview]
Message-ID: <20131025065117.GA15192@sigill.intra.peff.net> (raw)
In-Reply-To: <CANiSa6iYLp-iNdcv_qbFTitrfFxaDBVUy9YyUAF4QKM+-35P4A@mail.gmail.com>
On Thu, Oct 24, 2013 at 10:42:52PM -0700, Martin von Zweigbergk wrote:
> > I think that's the correct fix for the regression. You are restoring
> > the original, pre-166ec2e9 behavior for just the HEAD case. I do not
> > think add--interactive does any other magic between a symbolic rev and
> > its sha1, except for recognizing HEAD specially. However, if you wanted
> > to minimize the potential impact of 166ec2e9, you could pass the sha1
> > _only_ in the unborn case, like this:
>
> Plus, the end result is more readable, IMHO.
Agreed. Unfortunately it is slightly wrong, because for the non-patch
cases, we may look at "rev" later, and we would want it to still say
"HEAD" rather than a sha1. This is fixed in my patches below.
> > 1. Pass the head/not-head flag as a separate option.
> >
> > 2. Pass HEAD even in the unborn case; teach add--interactive to
> > convert an unborn HEAD to the empty tree.
> >
> > 3. Teach add--interactive to recognize the empty tree sha1 as an
> > "unstage" path.
> [...]
> Makes sense to me. I'm sure others can implement that much faster than
> I can, but I feel a little guilty, so I'm happy to do it if no one
> else wants to, as long as we agree this is the way we want to go.
As it turns out, add--interactive already _does_ know how to handle an
unborn HEAD. It just didn't use it for this particular code path. So I
think doing (2) makes the most sense, and the result is that the patch
in reset.c ends up nice and simple.
[1/2]: add-interactive: handle unborn branch in patch mode
[2/2]: reset: pass real rev name to add--interactive
-Peff
next prev parent reply other threads:[~2013-10-25 6:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPWpf+wi0zH2sOnuqiZuKkf+kC0RMug_ASb-J-TGGLd2RFT1wg@mail.gmail.com>
[not found] ` <CAPWpf+xqutvhq1jyVkxr6LyKsANTCS6M=vj5XY=EgUfiS3Z8xg@mail.gmail.com>
2013-10-24 23:05 ` Fwd: Bug report: reset -p HEAD Maarten de Vries
2013-10-24 23:16 ` Maarten de Vries
2013-10-25 3:40 ` Re* " Junio C Hamano
2013-10-25 4:24 ` Jeff King
2013-10-25 5:42 ` Martin von Zweigbergk
2013-10-25 6:51 ` Jeff King [this message]
2013-10-25 6:52 ` [PATCH 1/2] add-interactive: handle unborn branch in patch mode Jeff King
2013-10-25 6:54 ` [PATCH 2/2] reset: pass real rev name to add--interactive Jeff King
2013-10-25 16:54 ` Re* Bug report: reset -p HEAD 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131025065117.GA15192@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=maarten@de-vri.es \
--cc=martinvonz@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).