git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] Documentation on git-checkout --ours/--theirs improved

From
Simon Eugster <simon.eu@gmail.com>
Date
Jun 17, 2015, 14:31 UTC
Message-ID
<CAO8d5BYkgNgB+fV2HjrUasYi0jz9YvZGuFxKNMBbWoaONpAeUA@mail.gmail.com>
In-Reply-To
<xmqqzj3z64q9.fsf@gitster.dls.corp.google.com>
2015-06-16 17:41 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
Show 22 quoted lines
> Simon Eugster <simon.eu@gmail.com> writes:
>
>> 2015-06-15 22:10 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
>>>
>>> "Simon A. Eugster" <simon.eu@gmail.com> writes:
>>>
>>> > ---
>>>
>>> - Lack of explanation as to why this is a good thing.
>>> - Lack of sign-off.
>>>
>>> Why is there still 1/2, if its effect is wholly annulled by a
>>> subsequent step 2/2?
>>
>>
>> Sorry for that, still trying to find out how git send-email works.
>
> I do not think "git send-email" is involved in that process in any
> way.  The problem is you made the updates on top of the previous
> one, without squashing.  You fed two commits, instead of a squashed
> one commit, to "git send-email", and the command obliged and sent
> them out.

Yes, I somehow expected the two commits would be added to the same email because I provided the Message-Id, and yes, I could just have squashed them.

Show 42 quoted lines
>>> > +During merging, we assume the role of the canonical history’s keeper,
>>> > +which, in case of a rebase, is the remote history, and our private commits
>>> > +look to the keeper as “their” commits which need to be integrated on top
>>> > +of “our” work.
>>> > ++
>>> > +Normal merging:
>>> > +------------
>>> > +local ---------abC                  <-- canonical history
>>> > +                 | git checkout --ours
>>> > +                 v
>>> > +MERGE ---------abC
>>> > +                 ^
>>> > +                 | git checkout --theirs
>>> > +origin/master ---Xyz
>>> > +------------
>>> > +Rebasing:
>>> > +------------
>>> > +local -----------Abc
>>> > +                 | git checkout --theirs
>>> > +                 v
>>> > +REBASE --------xyZ
>>> > +                 ^
>>> > +                 | git checkout --ours
>>> > +origin/master -xyZ                    <-- canonical history
>>> > +------------
>>>
>>> I can see that an arrow with "canonical history" points at different
>>> things between the two pictures, but other than that, I am not sure
>>> what these are trying to illustrate.  Especially between abc and
>>> xyz, why does the former choose abc while the latter choooses xyz?
>>> Are these pictures meant to show what happens when the user says
>>> "checkout --ours" during a conflicted integration (whether it is a
>>> merge or a rebase)?
>>
>> I tried to create a picture which shows the difference of ours and
>> theirs when merging vs. rebasing, but apparently it did not turn out
>> well, and I will just leave it away.
>
> I'll wait for several days to see what other people would say, if
> they care to comment on this.  Maybe they can come up with a more
> intuitive picture, or maybe they say textual description is
> sufficiently clear that we do not need an illustration.  I dunno.

A better picture would be nice. And regarding the textual description, are you going to commit your version?

Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 10 in “Documentation clarification on git-checkout regarding ours/theirs”
  1. Documentation clarification on git-checkout regarding ours/theirsSimon A. Eugster, Jun 11, 2015
  2. Junio C HamanoJun 11, 2015
  3. Documentation clarification on git-checkoutSimon A. Eugster, Jun 15, 2015
  4. 1/2 Documentation clarification on git-checkout regarding ours/theirsSimon A. Eugster, Jun 15, 2015
  5. 2/2 Documentation on git-checkout --ours/--theirs improvedSimon A. Eugster, Jun 15, 2015
  6. Junio C HamanoJun 15, 2015
  7. Simon EugsterJun 16, 2015
  8. Junio C HamanoJun 16, 2015
  9. Simon EugsterJun 17, 2015
  10. Junio C HamanoJun 17, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.