Re: git-merge fails when trying to merge from a tag
- From
- Carl Baldwin <cnb@fc.hp.com>
- Date
- Dec 14, 2005, 00:00 UTC
- Message-ID
- <20051214000012.GA13925@hpsvcnb.fc.hp.com>
- In-Reply-To
- <7vy82o951s.fsf@assigned-by-dhcp.cox.net>
On Tue, Dec 13, 2005 at 11:21:19AM -0800, Junio C Hamano wrote:
Show 18 quoted lines
> Carl Baldwin <cnb@fc.hp.com> writes: > > > I just tried to merge using a tag object. > > Thanks for the report. > > > % git merge "Merging release-0.3.1" HEAD refs/tags/release-0.3.1 > > Once I considered changing commit-tree to take any committish > after -p, but thought the command is a low level primitive and > the user should know what he is doing, but apparently, git-merge > does not know what it is doing ;-). > > In fact, I never use "merge" myself, and haven't noticed this > breakage until now (you would notice that the Everyday document > never talks about "git merge"). Instead, I always do this: > > $ git pull . tag release-0.3.1
I've done this also. Personally, I feel a little more in control with a fetch, merge, tag type of flow. Maybe its just me but I couldn't get used to pull doing it all for me so I like to split the operation so that I can easily run a diff-tree between the two if I want after performing the fetch.
While we're on the subject. It might be nice if merge behaved a little more like pull (without the fetch of course). At the moment, I've got to give merge three arguments whereas pull is happy with just one of them.
So, sometimes I would like to type this % git merge <head>
much like one would type % git pull . <head>
Rather than typing % git merge "Message" HEAD <head>
But, this might not be an easy API change to make. I suppose I could just type 'git pull . <head>' and be satisfied but my thought process tells be that I'm merging branches rather than pulling so I usually don't think about it. I'm really just typing my stream of thought at this point so I'll wrap it up.
Thanks, Carl
Show 40 quoted lines
> But you are right. It is advertised as the end-user
> command and demonstrated in the tutorial.
>
> How about this patch? I haven't looked at what (old)
> git-resolve and git-octopus commands do --- they may need
> similar parameter massaging.
>
> -- >8 --
> [PATCH] allow merging any committish
>
> Although "git-merge" is advertised as the end-user level command
> (instead of being a "git-pull" backend), it was not prepared to
> take tag objects that point at commits and barfed when fed one.
> Sanitize the input while we validate them, for which we already
> have a loop.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> diff --git a/git-merge.sh b/git-merge.sh
> index a221daa..d25ae4b 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -97,11 +97,14 @@ head=$(git-rev-parse --verify "$1"^0) ||
> shift
>
> # All the rest are remote heads
> +remoteheads=
> for remote
> do
> - git-rev-parse --verify "$remote"^0 >/dev/null ||
> + remotehead=$(git-rev-parse --verify "$remote"^0) ||
> die "$remote - not something we can merge"
> + remoteheads="${remoteheads}$remotehead "
> done
> +set x $remoteheads ; shift
>
> case "$#" in
> 1)
>
> -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl Baldwin Systems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com Fort Collins, CO 80525 home: Carl@ecBaldwin.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -