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
Junio C Hamano <gitster@pobox.com>
Date
Jun 16, 2015, 15:41 UTC
Message-ID
<xmqqzj3z64q9.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CAO8d5Bbi8LHHP0nnYwv=_Qr6KZCJmFPTq5ut2KzeSKJ-i0RZNg@mail.gmail.com>
Simon Eugster <simon.eu@gmail.com> writes:
Show 14 quoted lines
> 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.

Show 37 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.

Thanks.
Previous: Simon EugsterNext: Simon Eugster
Message 8 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.