From: Junio C Hamano <gitster@pobox.com>
To: James Denholm <nod.helm@gmail.com>
Cc: git@vger.kernel.org, Kevin Cagle <kcagle@micron.com>
Subject: Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag
Date: Thu, 08 May 2014 10:38:32 -0700 [thread overview]
Message-ID: <xmqqoaz841d3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1399511079-1994-1-git-send-email-nod.helm@gmail.com> (James Denholm's message of "Thu, 8 May 2014 11:04:39 +1000")
James Denholm <nod.helm@gmail.com> writes:
> cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
> then rev-parsed into an object ID. However, if the user is fetching a
> tag rather than a branch HEAD, such as by executing:
>
> $ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0
>
> The object ID is a tag and is never peeled, and the git commit-tree call
> (line 561) slaps us in the face because it doesn't handle tag IDs.
The "rev" (not "revs") seems to be used by more things than the
final commit-tree state. Are we losing some useful information by
peeling it too early like this patch does? The reason why we
stopped peeling when writing FETCH_HEAD was because we wanted to
record the fact that we merged a tag (and use the GPG signature if
found in it) when constructing the log message for the merge, and
peeling the tag too early and recording the commit in FETCH_HEAD
would make it impossible to do, and I am wondering if this change is
making the same kind of mistake here.
I see that add_msg does not use anything useful from latest_new, so
with the current state of the code, it does not make that much
difference (except that it says "from commit '$latest_new'", and by
peeling, the fact that the user wanted to use a tag is lost from the
result).
> On a side note, if merging a tag without --squash, git merge recognises
> that it's a tag and adds a note to the merge commit body. It may be
> worth mimicking this when using "subtree merge --squash" or
> "subtree add".
Yes, and this change makes such a change harder to implement on top,
I suspect.
Would it be sufficient to do
git commit-tree $tree $headp -p "$rev^0"
in that "not squashing" codepath instead?
> contrib/subtree/git-subtree.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index dc59a91..9453dae 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -538,7 +538,7 @@ cmd_add_commit()
> {
> revs=$(git rev-parse $default --revs-only "$@") || exit $?
> set -- $revs
> - rev="$1"
> + rev=$(peel_committish "$1")
>
> debug "Adding $dir as '$rev'..."
> git read-tree --prefix="$dir" $rev || exit $?
next prev parent reply other threads:[~2014-05-08 17:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 1:04 [PATCH] contrib/subtree bugfix: Can't `add` annotated tag James Denholm
2014-05-08 17:38 ` Junio C Hamano [this message]
2014-05-09 7:36 ` James Denholm
2014-05-12 7:29 ` 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=xmqqoaz841d3.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kcagle@micron.com \
--cc=nod.helm@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.
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.