git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Wang <wwwjfy@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
Date: Mon, 7 Nov 2011 19:02:10 +0800	[thread overview]
Message-ID: <EF1B195E54C9411A91CCF9A21C5FADC2@gmail.com> (raw)
In-Reply-To: <20111107104128.GA2964@do>

On Monday, November 7, 2011 at 18:41, Nguyen Thai Ngoc Duy wrote:
> On Mon, Nov 07, 2011 at 05:48:25PM +0800, Tony Wang wrote:
> > > It was on purpose. HEAD may contain a tag, in which case
> > > lookup_commit() would to return a commit fail while
> > > lookup_commit_reference() can peel the tag to the commit.
> > 
> > 
> > 
> > However, I tried to make it lookup_commit and it worked as expected. I'll try to read some detail. 
> 
> and the strange value of branch "s/origin/b" in your previous message..
that's the strange thing. seems like part of the string "refs/origin/b" 
> 
> > > 
> > > > I tried to debug, and found after this
> > > > merge.c:1104
> > > > head_commit = lookup_commit_or_die(head_sha1, "HEAD");
> > > > the variable branch becomes "s/origin/b", which is previously "b".
> > > 
> > 
> 
> 
> 
> ..led me to think that it's because branch points to the static buffer
> returned by by resolve_ref().
> 
> lookup_commit_reference() may call resolve_ref() again and change the
> buffer value, which also changes "branch" variable.
> 
> So, does this help?
> 
> -- 8< --
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 581f494..4f20833 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -1029,7 +1029,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> * Check if we are _not_ on a detached HEAD, i.e. if there is a
> * current branch.
> */
> - branch = resolve_ref("HEAD", head_sha1, 0, &flag);
> + branch = xstrdup(resolve_ref("HEAD", head_sha1, 0, &flag));
> if (branch && !prefixcmp(branch, "refs/heads/"))
> branch += 11;
> if (!branch || is_null_sha1(head_sha1))
> -- 8< --

Yes! It works.
I do learn from it, thanks!
But seems it's possible the potential problem exists somewhere else.
> -- 
> Duy



-- 
BR,
Tony Wang

  reply	other threads:[~2011-11-07 11:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BC404302028E4B6F8F2C27DC8E63545F@gmail.com>
2011-11-07  9:30 ` git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 Nguyen Thai Ngoc Duy
2011-11-07  9:48   ` Tony Wang
2011-11-07 10:41     ` Nguyen Thai Ngoc Duy
2011-11-07 11:02       ` Tony Wang [this message]
2011-11-07 11:21         ` Nguyen Thai Ngoc Duy
2011-11-08  2:30           ` [PATCH] Copy resolve_ref() return value for longer use Nguyễn Thái Ngọc Duy
2011-11-13  5:57             ` Junio C Hamano
2011-11-13  7:09               ` Nguyen Thai Ngoc Duy
2011-11-13  7:59                 ` Junio C Hamano
2011-11-13 10:22                   ` [PATCH 1/2] Convert many resolve_ref() calls to read_ref*() and ref_exists() Nguyễn Thái Ngọc Duy
2011-11-13 10:22                     ` [PATCH 2/2] Copy resolve_ref() return value for longer use Nguyễn Thái Ngọc Duy
2011-11-13 20:41                       ` Junio C Hamano
2011-11-14  3:32                         ` Nguyen Thai Ngoc Duy
2011-11-14  4:03                           ` Junio C Hamano
2011-11-14 11:24                           ` Jeff King
2011-11-15  6:06                             ` Nguyen Thai Ngoc Duy
2011-11-15  6:07                               ` [PATCH 01/10] Allow resolve_ref() caller to decide whether to receive static buffer Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 02/10] cmd_merge: convert to single exit point Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 03/10] merge: do not point "branch" to a resolve_ref()'s static buffer Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 04/10] commit: move resolve_ref() closer to where the return value is used Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 05/10] checkout: do not try xstrdup() on NULL Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 06/10] reflog-walk.c: request allocated buffer from resolve_ref() Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 07/10] receive-pack: request resolve_ref() to allocate new buffer Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 08/10] notes: " Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 09/10] fmt-merge-msg: " Nguyễn Thái Ngọc Duy
2011-11-15  6:07                                 ` [PATCH 10/10] branch: " Nguyễn Thái Ngọc Duy
2011-11-15  7:09                                 ` [PATCH 01/10] Allow resolve_ref() caller to decide whether to receive static buffer Junio C Hamano
2011-11-13 20:30                     ` [PATCH 1/2] Convert many resolve_ref() calls to read_ref*() and ref_exists() Junio C Hamano
2011-12-10  3:43                   ` [PATCH] Copy resolve_ref() return value for longer use Tony Wang
2011-12-10  4:48                     ` Nguyen Thai Ngoc Duy
2011-12-11  2:28                       ` Tony Wang

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=EF1B195E54C9411A91CCF9A21C5FADC2@gmail.com \
    --to=wwwjfy@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@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 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).