git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Denholm <nod.helm@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Kevin Cagle <kcagle@micron.com>
Subject: Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
Date: Tue, 13 May 2014 23:02:01 +0000	[thread overview]
Message-ID: <20140513230201.GA32562@debian> (raw)
In-Reply-To: <xmqqa9alo4lm.fsf@gitster.dls.corp.google.com>

On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote:
> James Denholm <nod.helm@gmail.com> writes:
> > I felt that defining revp would be a little more self-documenting than
> > using $rev^0.
> 
> That is a good decision, but as long as we are attempting to peel,
> don't we want to stop the damage when it does not peel to a commit?

I'm not sure that can actually happen - peel_committish is essentially
implemented as `rev-parse $arg^0` (though with a bit of bling, of
course), and to my understanding FETCH_HEAD will always parse to a
committish - I could have missed something, of course.

subtree Will need error-catching at some point, of course, triggering
resets or at least suggesting instructions to the user, but I think
that's a touch out of the scope of a bugfix at this point (and, to be
honest, I personally can't allocate the time to that for about a month
due to the dark shadow of academic exams). Indeed, what to do in those
cases is probably worth (re-)discussing the overall design and aims of
subtree for, and so I'm not confident that I currently know the best way
to do that.

> I'll tentatively queue this.  Thanks.

Awesome, thanks again for this and the feedback.

---
Regards,
James Denholm.

  reply	other threads:[~2014-05-13 23:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13  4:08 [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag James Denholm
2014-05-13 19:34 ` Junio C Hamano
2014-05-13 23:02   ` James Denholm [this message]
2014-05-13 23:12     ` Junio C Hamano
2014-05-14 21:32       ` James Denholm
2014-05-14 21:40         ` Junio C Hamano
2014-05-14 22:50           ` James Denholm

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=20140513230201.GA32562@debian \
    --to=nod.helm@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kcagle@micron.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).