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

Re: Itches with the current rev spec

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 29, 2013, 17:33 UTC
Message-ID
<7vip35jl7z.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CALkWK0k7w4xuewnJFNJLk730NSiZOA_1UF0_Dqcnw5Or3GYOcA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 8 quoted lines
> Junio C Hamano wrote:
>> That world view is broken, isn't it?  Perhaps you forgot to consider
>> symmetric differences, where left positives and right positives have
>> to be treated differently.
>
> No, I did consider symmetric difference.  How is git log A B --not
> $(git merge-base --all A B) different from git log B A --not $(git
> merge-base --all A B)?
Compare these (gitk will give you nicer picture):
   $ git log --oneline --graph --left-right A...B
   $ git log --oneline --graph --left-right B...A
Show 6 quoted lines
> Um, my point was again that "ordering does not matter"; therefore for
> a third type of commit, you need a command-line parameter.
>
>>     git show A..B C..D
>
> This is seriously bad.  We'll have to think about fixing this along the way.

For the purpose of "doing one thing and well", we have drawn the line at "we operate on at most one DAG and specify what happens to it with various other parameters, which may include commits" long time ago. If you want to operate on more than one DAG, the cleanest way is to do the set computation for A..B and C..D separately and combine them yourself (which is the example you omitted from the quote).

The setup_revisions() machinery that is the foundation of the current codebase has this design decision ingrained in it. That is where the marking of commits with only two primary colors (i.e. the UNINTERESTING bit) comes from, and where the "single DAG" limitation originates. You can extending it a little bit (e.g. by introducing a secondary color left/right) to enrich it, but fundamentally the infrastructure pretty much assumes we operate on one DAG and a commit is either outside or inside (or at the boundary) of it.

It may be nice if the low-level operated on more than one DAG, but it is very close to a proposition to throw the baby with the bathwater and restart from scratch. It is a lot more than a little "as an aside" task.

Previous: Ramkumar RamachandraNext: Ramkumar Ramachandra
Message 20 of 24 in “Itches with the current rev spec”
  1. Ramkumar RamachandraApr 25, 2013
  2. Ramkumar RamachandraApr 25, 2013
  3. Matthieu MoyApr 25, 2013
  4. Felipe ContrerasApr 25, 2013
  5. Ramkumar RamachandraApr 25, 2013
  6. Michael J GruberApr 29, 2013
  7. Andreas SchwabApr 25, 2013
  8. Ramkumar RamachandraApr 25, 2013
  9. Phil HordApr 25, 2013
  10. Yann DirsonApr 26, 2013
  11. Johannes SixtApr 26, 2013
  12. Ramkumar RamachandraApr 26, 2013
  13. Junio C HamanoApr 26, 2013
  14. Felipe ContrerasApr 26, 2013
  15. Junio C HamanoApr 26, 2013
  16. Ramkumar RamachandraApr 29, 2013
  17. Yann DirsonApr 29, 2013
  18. Junio C HamanoApr 29, 2013
  19. Ramkumar RamachandraApr 29, 2013
  20. Junio C HamanoApr 29, 2013
  21. Ramkumar RamachandraApr 29, 2013
  22. Ramkumar RamachandraApr 29, 2013
  23. Junio C HamanoApr 30, 2013
  24. Ramkumar RamachandraApr 29, 2013

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.