From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
git@vger.kernel.org, Alex Henrie <alexhenrie24@gmail.com>,
Marc Branchaud <marcnarc@xiplink.com>,
Philip Oakley <philipoakley@iee.email>,
Elijah Newren <newren@gmail.com>,
Stephen Haberman <stephen@exigencecorp.com>
Subject: Re: [PATCH] doc: pull: fix rebase=false documentation
Date: Fri, 23 Jul 2021 13:29:37 -0500 [thread overview]
Message-ID: <60fb0a916c9cc_defb208eb@natae.notmuch> (raw)
In-Reply-To: <xmqqwnphowdx.fsf@gitster.g>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So I feel compelled to say now that I do not think that changing the
> > order of parents for "git pull" is the obviously correct thing to do.
> > And likewise, in the one thread I do remember participating in, I
> > expressed something similar:
> >
> > https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/
>
> Thanks for the link. Many articles in the thread are repeating the
> same opinion over and over (and later even descend into ad-hominem
> attacks) and it is not worth anybody's time to read all of them, but
> I found that there still were some gems.
>
> In an worldview where the first-parent chain is the trunk history,
> merging in the upstream where you push back to into your working
> repository where your new work is happening as the second parent
> before pushing it back would obviously make the history that used to
> be trunk to lose the first-parent-ness at that point. And if you
> ask if I just said is correct, everybody would say it is. So there
> is a concensus that the result of "git pull upstream main" becomes
> a wrong shape for people in one workflow.
>
> But that does not necessarily mean swapping the parent order would
> produce the history of a right shape, either, even for those with
> the "first-parent chain is the trunk" worldview.
Why not? Everyone who saw a problem agreed it would.
Reversing the order of the parents creates a merge commit like so:
Y---X-+
\
B---A---M trunk
Most git experts work with topic branches, and when you do that, you get
the same thing:
topic
|
v
Y---X-+
\
B---A---M master
If you merge topic to master, the first parent of the merge commit is A.
If you do `git pull --reverse-parents` on a trunk-based workflow as
above, you would get exactly the same shape of the history.
How is it not the right shape?
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-23 18:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 22:15 [PATCH] doc: pull: fix rebase=false documentation Felipe Contreras
2021-07-21 23:33 ` Junio C Hamano
2021-07-22 0:21 ` Junio C Hamano
2021-07-22 1:24 ` Felipe Contreras
2021-07-23 7:30 ` Jeff King
2021-07-23 10:05 ` Philip Oakley
2021-07-23 16:54 ` Felipe Contreras
2021-07-23 15:58 ` Junio C Hamano
2021-07-23 18:29 ` Felipe Contreras [this message]
2021-07-23 21:44 ` Junio C Hamano
2021-07-24 3:56 ` Felipe Contreras
2021-07-23 16:36 ` Felipe Contreras
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=60fb0a916c9cc_defb208eb@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=alexhenrie24@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marcnarc@xiplink.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=philipoakley@iee.email \
--cc=stephen@exigencecorp.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.