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

Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch

From
Jakub Narebski <jnareb@gmail.com>
Date
Jul 7, 2008, 22:58 UTC
Message-ID
<200807080058.56346.jnareb@gmail.com>
In-Reply-To
<7vk5fx1g0a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 24 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>>> @@ -289,10 +299,10 @@ notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
>>>  from `r2` but exclude the ones reachable from `r1`.
>>>  
>>>  This set operation appears so often that there is a shorthand
>>> -for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
>>> -the difference of two sets (subtract the set of commits
>>> -reachable from `r1` from the set of commits reachable from
>>> -`r2`).
>>> +for it.  When you have two commits `r1` and `r2` (named according
>>> +to the syntax explained in SPECIFYING REVISIONS above), you can ask
>>> +for commits that are reachable from r2 but not from r1 by
>>> +"`{caret}r1 r2`" and it can be written as "`r1..r2`".
>>
>> I'm not sure if the last part is improvement, and it wouldn't be better
>> to say rather than r1..r2 / ^r1 r2 are "commits that are reachable from
>> r2, excluding those commits which are reachable from r1" (which translates
>> into set difference / subtracting set of commits.
> 
> I tried to make it easier to understand by people without having to know
> what a set difference is, and that was the reason I did not use "subtract"
> nor "difference", as I saw somebody was quoting the above part in #git was
> wondering what it was talking about.

I understand, and the replacement you proposed is better, as it does not require understanding of [mathematical] set operations. I just think that "commits that are reachable from r2, excluding those commits which are reachable from r1" could be better than "commits that are reachable from r2 but not from r1".

-- 
Jakub Narebski
Poland
Previous: Junio C HamanoNext: Brian Gernhardt
Message 17 of 28 in “Make rebase save ORIG_HEAD if changing current branch”
  1. Make rebase save ORIG_HEAD if changing current branchBrian Gernhardt, Jul 6, 2008
  2. Junio C HamanoJul 7, 2008
  3. Brian GernhardtJul 7, 2008
  4. Junio C HamanoJul 7, 2008
  5. Junio C HamanoJul 7, 2008
  6. Junio C HamanoJul 7, 2008
  7. Theodore TsoJul 7, 2008
  8. Jakub NarebskiJul 7, 2008
  9. Brian GernhardtJul 7, 2008
  10. Jeff KingJul 8, 2008
  11. Brian GernhardtJul 8, 2008
  12. Brian GernhardtJul 7, 2008
  13. Junio C HamanoJul 7, 2008
  14. Junio C HamanoJul 7, 2008
  15. Jakub NarebskiJul 7, 2008
  16. Junio C HamanoJul 7, 2008
  17. Jakub NarebskiJul 7, 2008
  18. Brian GernhardtJul 8, 2008
  19. Documentation: mention ORIG_HEAD in am, merge, and rebaseBrian Gernhardt, Jul 8, 2008
  20. Junio C HamanoJul 8, 2008
  21. Brian GernhardtJul 8, 2008
  22. Jay SoffianJul 8, 2008
  23. Mike HommeyJul 7, 2008
  24. Junio C HamanoJul 7, 2008
  25. Mike HommeyJul 7, 2008
  26. Nanako ShiraishiJul 7, 2008
  27. Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branchJunio C Hamano, Jul 7, 2008
  28. Brian GernhardtJul 7, 2008

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.