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

Re: Bizarre missing changes (git bug?)

From
RZRoman Zippel <zippel@linux-m68k.org>
Date
Jul 30, 2008, 00:16 UTC
Message-ID
<Pine.LNX.4.64.0807291433430.6791@localhost.localdomain>
In-Reply-To
<46a038f90807282015m7ce3da10h71dfee221c960332@mail.gmail.com>
Hi,
On Tue, 29 Jul 2008, Martin Langhoff wrote:
Show 8 quoted lines
> On Tue, Jul 29, 2008 at 2:59 PM, Roman Zippel <zippel@linux-m68k.org> wrote:
> > Can we please get past this and look at what is required to produce the
> > correct history?
> 
> Roman - correct is --full-history -- any simplification that makes it
> easy on your eyes *is* a simplification. And consumers that want to do
> nice user-friendly simplification like gitk does can hang off the data
> stream.

I don't quite understand what you're trying to say. To avoid further confusion it maybe helps to specify a few of the terms:

- full history graph: produced by "git-log --full-history --parents"
- compact history graph: the full history graph without without any 
  repeated merges, this is what my example script produces.
- full simplified history: output of "git-log --full-history"
- short simplified history: standard output of "git-log"

The important part about the history graphs is that all commits are properly connected in it (i.e. all except the head commit have a child), This is needed to know if you don't just what want to know what happened, but also how it got merged, also any graphical interface needs it to produce a useful history graph.

What the short simplified history is more pure laziness, it's fast and gets the most common cases right, but in order to do this it has to ignore part of the history. The full simplified history at least produces produces the full change history, but it lacks part of the merge history and it stills takes longer to generate.

The point I'm trying to make is that the compact history graph has the potential to completely replace the simplified history. The only problem is that it needs a bit of cached extra information, then it can be as fast the short simplified history for the common case and it still can produce as much information as the full simplified history, thus you can still apply as much simplification as you want on top of it.

Keep in mind that e.g. git-web is using the full simplified history, so what I'm offering also has the potential to improve git-web performance...

Show 6 quoted lines
> > it's also possible to update it when merging/pulling new data.
> 
> If that's what you want to do, you can prototype it with a hook on
> fetch and commit. That is definitely an area that hasn't been explored
> - what nicer (but expensive) views on the history we have can be
> afforded by pre-computing things on fetch and commit hooks.

I already did the prototype, I know how to generate that information, the problem is to get that information to the various graphical interfaces.

bye, Roman
Previous: Martin LanghoffNext: Martin Langhoff
Message 16 of 58 in “Bizarre missing changes (git bug?)”
  1. Tim HarperJul 21, 2008
  2. Linus TorvaldsJul 21, 2008
  3. Tim HarperJul 21, 2008
  4. Tim HarperJul 21, 2008
  5. Roman ZippelJul 26, 2008
  6. Linus TorvaldsJul 26, 2008
  7. Roman ZippelJul 27, 2008
  8. Linus TorvaldsJul 27, 2008
  9. Roman ZippelJul 27, 2008
  10. Linus TorvaldsJul 27, 2008
  11. Roman ZippelJul 28, 2008
  12. Linus TorvaldsJul 28, 2008
  13. Linus TorvaldsJul 28, 2008
  14. Roman ZippelJul 29, 2008
  15. Martin LanghoffJul 29, 2008
  16. Roman ZippelJul 30, 2008
  17. Martin LanghoffJul 30, 2008
  18. Linus TorvaldsJul 30, 2008
  19. Linus TorvaldsJul 30, 2008
  20. Junio C HamanoJul 30, 2008
  21. Junio C HamanoJul 31, 2008
  22. Linus TorvaldsJul 31, 2008
  23. revision traversal: show full history with merge simplificationJunio C Hamano, Jul 31, 2008
  24. Junio C HamanoJul 31, 2008
  25. Linus TorvaldsJul 31, 2008
  26. revision traversal: show full history with merge simplificationJunio C Hamano, Jul 31, 2008
  27. Linus TorvaldsJul 31, 2008
  28. Junio C HamanoJul 31, 2008
  29. Junio C HamanoAug 1, 2008
  30. Linus TorvaldsAug 1, 2008
  31. Junio C HamanoAug 1, 2008
  32. Jakub NarebskiJul 30, 2008
  33. Linus TorvaldsJul 29, 2008
  34. Linus TorvaldsJul 29, 2008
  35. Roman ZippelJul 29, 2008
  36. David KastrupJul 29, 2008
  37. Linus TorvaldsJul 29, 2008
  38. Roman ZippelJul 30, 2008
  39. Kevin BallardJul 30, 2008
  40. Linus TorvaldsJul 30, 2008
  41. Jeff KingJul 29, 2008
  42. Roman ZippelJul 29, 2008
  43. Olivier GalibertJul 29, 2008
  44. Jeff KingJul 29, 2008
  45. Linus TorvaldsJul 29, 2008
  46. Roman ZippelJul 30, 2008
  47. Linus TorvaldsJul 30, 2008
  48. Jeff KingJul 30, 2008
  49. Linus TorvaldsJul 30, 2008
  50. Roman ZippelJul 30, 2008
  51. Kevin BallardJul 30, 2008
  52. Linus TorvaldsJul 30, 2008
  53. Linus TorvaldsJul 30, 2008
  54. Jeff KingJul 30, 2008
  55. Martin LanghoffJul 27, 2008
  56. Roman ZippelJul 28, 2008
  57. Alex RiesenJul 21, 2008
  58. Linus TorvaldsJul 21, 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.