From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org
Subject: Re: [BUG] "git pull" will regress between 'master' and 'pu'
Date: Mon, 20 Apr 2015 12:24:31 -0700 [thread overview]
Message-ID: <xmqqiocqli1c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150420191041.GA14362@peff.net> (Jeff King's message of "Mon, 20 Apr 2015 15:10:41 -0400")
Jeff King <peff@peff•net> writes:
> On Mon, Apr 20, 2015 at 11:59:04AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff•net> writes:
>>
>> > @@ -334,7 +333,7 @@ true)
>> > eval="git-merge $diffstat $no_commit $verify_signatures $edit $squash $no_ff $ff_only"
>> > eval="$eval $log_arg $strategy_args $merge_args $verbosity $progress"
>> > eval="$eval $gpg_sign_args"
>> > - eval="$eval -m \"\$merge_name\" $merge_head"
>> > + eval="$eval FETCH_HEAD"
>> > ;;
>> > esac
>> > eval "exec $eval"
>> >
>> > as we seem to special-case the name FETCH_HEAD. It assumes that
>> > git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
>> > but that seems safe.
>>
>> Unfortunately, "git merge"'s parsing of FETCH_HEAD forgets that we
>> may be creating an Octopus. Otherwise the above should work well.
>
> That sounds like a bug we should fix regardless.
But I am not sure how it should behave. "git fetch $there A B C"
followed by "git merge FETCH_HEAD" merges only A, and I do not know
if people have come to depend on this behaviour.
I suspect there may be larger fallout from such a change, namely,
what should "git log FETCH_HEAD" do? Should it traverse the history
starting from all things that are not marked as not-for-merge, or
should it just say "git rev-parse FETCH_HEAD" and use only the first
one as the starting point?
I would argue that it would be more consistent with how we envision
the "git merge FETCH_HEAD" should work if "git log FETCH_HEAD"
traversed from all fetched HEAD for merging, but surely it is a huge
potential incompatibility.
For that matter, "git rev-parse FETCH_HEAD" and even get_sha1() should
yield all fetched HEAD for merging if we want to be consistent. I
haven't thought this through yet but it does not look pretty.
next prev parent reply other threads:[~2015-04-20 19:24 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-19 1:39 [BUG] "git pull" will regress between 'master' and 'pu' Junio C Hamano
2015-04-19 13:07 ` Jeff King
2015-04-19 17:38 ` brian m. carlson
2015-04-19 18:19 ` Jeff King
2015-04-20 18:59 ` Junio C Hamano
2015-04-20 19:10 ` Jeff King
2015-04-20 19:24 ` Junio C Hamano [this message]
2015-04-26 5:25 ` [PATCH 00/14] Teach "git merge FETCH_HEAD" octopus merges Junio C Hamano
2015-04-26 5:25 ` [PATCH 01/14] merge: simplify code flow Junio C Hamano
2015-04-26 5:25 ` [PATCH 02/14] t5520: style fixes Junio C Hamano
2015-04-26 5:25 ` [PATCH 03/14] t5520: test pulling an octopus into an unborn branch Junio C Hamano
2015-04-26 5:25 ` [PATCH 04/14] merge: clarify "pulling into void" special case Junio C Hamano
2015-04-26 5:25 ` [PATCH 05/14] merge: do not check argc to determine number of remote heads Junio C Hamano
2015-04-26 5:25 ` [PATCH 06/14] merge: small leakfix and code simplification Junio C Hamano
2015-04-26 5:26 ` [PATCH 07/14] merge: clarify collect_parents() logic Junio C Hamano
2015-04-26 5:26 ` [PATCH 08/14] merge: split reduce_parents() out of collect_parents() Junio C Hamano
2015-04-26 5:26 ` [PATCH 09/14] merge: narrow scope of merge_names Junio C Hamano
2015-04-26 5:26 ` [PATCH 10/14] merge: extract prepare_merge_message() logic out Junio C Hamano
2015-04-26 5:26 ` [PATCH 11/14] merge: make collect_parents() auto-generate the merge message Junio C Hamano
2015-04-26 5:26 ` [PATCH 12/14] merge: decide if we auto-generate the message early in collect_parents() Junio C Hamano
2015-04-26 5:26 ` [PATCH 13/14] merge: handle FETCH_HEAD internally Junio C Hamano
2015-04-26 5:26 ` [PATCH 14/14] merge: deprecate 'git merge <message> HEAD <commit>' syntax Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 00/15] Teach "git merge FETCH_HEAD" octopus merges Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 01/15] merge: test the top-level merge driver Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 02/15] merge: simplify code flow Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 03/15] t5520: style fixes Junio C Hamano
2015-05-01 8:35 ` Paul Tan
2015-05-03 1:57 ` Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 04/15] t5520: test pulling an octopus into an unborn branch Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 05/15] merge: clarify "pulling into void" special case Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 06/15] merge: do not check argc to determine number of remote heads Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 07/15] merge: small leakfix and code simplification Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 08/15] merge: clarify collect_parents() logic Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 09/15] merge: split reduce_parents() out of collect_parents() Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 10/15] merge: narrow scope of merge_names Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 11/15] merge: extract prepare_merge_message() logic out Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 12/15] merge: make collect_parents() auto-generate the merge message Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 13/15] merge: decide if we auto-generate the message early in collect_parents() Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 14/15] merge: handle FETCH_HEAD internally Junio C Hamano
2015-04-29 21:29 ` [PATCH v2 15/15] merge: deprecate 'git merge <message> HEAD <commit>' syntax Junio C Hamano
2015-04-20 19:28 ` [BUG] "git pull" will regress between 'master' and 'pu' Junio C Hamano
2015-04-21 7:23 ` Johannes Schindelin
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=xmqqiocqli1c.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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