public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: Paul Tan <pyokagan@gmail•com>
Cc: Git List <git@vger•kernel.org>,
	Johannes Schindelin <johannes.schindelin@gmx•de>,
	Stefan Beller <sbeller@google•com>
Subject: Re: [RFC] git-am: handling unborn branches
Date: Thu, 04 Jun 2015 10:26:34 -0700	[thread overview]
Message-ID: <xmqqpp5bv0z9.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACRoPnSmF0ym7ONnLAfL=o5ouSrP2Ucxdh40k6Ps-hnTsSUx4w@mail.gmail.com> (Paul Tan's message of "Thu, 4 Jun 2015 18:34:13 +0800")

Paul Tan <pyokagan@gmail•com> writes:

> git-am generally supports applying patches to unborn branches.
> However, there are 2 cases where git-am does not handle unborn
> branches which I would like to address before the git-am rewrite to C:

> 1. am --skip
>
> For git am --skip, git-am.sh does a fast-forward checkout from HEAD to
> HEAD, discarding unmerged entries, and then resets the index to HEAD
> so that the index is not dirty.
>
>         git read-tree --reset -u HEAD HEAD
>         orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>         git reset HEAD
>         git update-ref ORIG_HEAD $orig_head
>
> This requires a valid HEAD. Since git-am requires an empty index for
> unborn branches in the patch application stage anyway, I think we
> should discard all entires in the index if we are on an unborn branch?

Yes, and it should also remove the new files the failed application
brought in to the working tree, if any, to match the "--skip" done
in the normal case (i.e. when we already have a history to apply
patches to), I would think.

> 2. am --abort
>
> For git am --abort, git-am.sh does something similar. It does a
> fast-forward checkout from HEAD to ORIG_HEAD, discarding unmerged
> entries, and then resets the index to ORIG_HEAD so that local changes
> will be unstaged.

In general, the "apply to nothing" is more or less an afterthought
and was not done as carefully as the rest of the program, so view
whenever you see a strange behaviour as not a "strange spec" but
likely to be a bug.  You would do OK if you imagine what should
happen if you were doing the same operation on top of a commit that
records an empty tree and try to match the behaviour to that case.

Thanks.

next prev parent reply	other threads:[~2015-06-04 17:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-04 10:34 [RFC] git-am: handling unborn branches Paul Tan
2015-06-04 17:26 ` Junio C Hamano [this message]
2015-06-05  6:37   ` Paul Tan
2015-06-05 15:36     ` Junio C Hamano
2015-06-05 16:26       ` Paul Tan
2015-06-05 16:33         ` Junio C Hamano
2015-06-04 17:27 ` Stefan Beller
2015-06-05  8:32   ` Paul Tan

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=xmqqpp5bv0z9.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=johannes.schindelin@gmx$(echo .)de \
    --cc=pyokagan@gmail$(echo .)com \
    --cc=sbeller@google$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox