{"thread":{"id":"60984","subject":"[RFD] should \"git log --graph -g\" work and if so how?","startedAt":"2024-02-24T19:04:58Z","lastAt":"2024-02-29T10:03:56Z","messageCount":2,"participants":["Junio C Hamano","Oswald Buddenhagen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"489280","messageId":"xmqqo7c5n0ob.fsf@gitster.g","threadId":"60984","inReplyTo":null,"subject":"[RFD] should \"git log --graph -g\" work and if so how?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-24T19:04:52Z","receivedAt":"2024-02-24T19:04:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Outside work, I keep one repository that keeps copies of a subset of\nwhat is available elsewhere (but that is not version controlled in\nany way), and in this repository, I do either one of two operations:\n\n * I \"fetch\" the latest state of the things I keep track of from\n   that \"elsewhere\", and then record that state as a \"snapshot\".\n\n * I update the \"subset\" I keep track of from that \"elsewhere\",\n   download that new part of the subset, and then record the result\n   as a commit with messages like \"add 'foo'\" or \"drop 'bar'\".\n\nOne curiosity is that I do not care too much about \"snapshot\"; the\nlatest state is often enough, so when the topmost one is a snapshot,\nI may \"amend\" it when making a new \"snapshot\", instead of making two\nor more consecutive \"snapshot\" commits (when the topmost \"snapshot\"\nis too old, I may choose to add a new shapshot on top of it, but\nlet's ignore that for simplicity).\n\n    if I am doing a snapshot\n    then\n\tfetch what I've been tracking from \"elsewhere\"\n\t\"git add .\"\n\tif the topmost commit is an earlier \"snapshot\"\n\tthen\n\t\t\"git commit --amend -m 'snapshot as of ...'\"\n\telse\n\t\t\"git commit -m 'snapshot as of ...'\"\n\tfi\n    elif I am adding new things to be tracked\n    then\n\tfetch the new part of \"elsewhere\"\n\t\"git add .\"\n\t\"git commit -m 'add ...'\n    fi\n\nAfter I started from empty, started tracking 'foo' and then a few\ndays later started tracking 'bar', and then started taking snapshots\non 2024-02-22 and took one every day, I may end up with a history\nthat \"git show-branch -g\" may give me something like this:\n\n    $ git show-branch -g5\n    ! [master@{0}] (24 minutes ago) commit {amend}: snapshot as of 2024-02-24\n     ! [master@{1}] (1 day ago) commit (amend): snapshot as of 2024-02-23\n      ! [master@{2}] (2 days ago) commit: snapshot as of 2024-02-22\n       ! [master@{3}] (3 days ago) commit: add 'bar'\n        ! [master@{4}] (7 days ago) commit: add 'foo'\n    -----\n    +     [master@{0}] snapshot as of 2024-02-24\n     +    [master@{1}] snapshot as of 2024-02-23\n      +   [master@{2}] snapshot as of 2024-02-22\n    ++++  [master@{3}] add 'bar'\n    +++++ [master@{4}] add 'foo'\n\nand that output is sort-of readable (if you have seen and know how\nto read what show-branch produces, that is), but the command way\npredates commit slabs and uses the usual object flag bits, so it is\nlimited to show only 25 or so commits [*1*].\n\nNow, if I could run\n\n    $ git log --oneline --graph -g --since=2024-02-20 --boundary\n\non the result, such a history might look like this:\n\n    * snapshot as of 2024-02-24 (HEAD)\n    | * snapshot as of 2024-02-23 (HEAD@{1})\n    |/\n    | * snapshot as of 2024-02-22 (HEAD@{2})\n    |/\n    * add 'bar' (HEAD~1)\n    o add 'foo' (HEAD~2)\n\nto show the same history.\n\nUnfortunately, \"--graph\" and \"-g\" does not mix X-<.\n\nSo, the RFD is,\n\n (1) Should \"git log\" learn a trick to show a history like this in a\n     readable way?  Does it have utility outside this use case of\n     mine?  I am not interested in adding a new feature just for\n     myself ;-)\n\n (2) The use case requires a solution to look at reflog entries, but\n     it does not need to \"walk\" reflog [*2*].  Should such a feature\n     still be tied to the \"-g\" flag, or should we want a separate\n     flag?\n\n (3) What should the UI and the implementation look like?  \"Show me\n     what happened to this branch since 2024-02-20, including what\n     is in reflog\" that results in:\n\n     - we first enumerate commits on the reflog of this branch that\n       were made since the given date.\n\n     - we then pretend as if all of these commits were given on the\n       command line of \"git log --oneline --graph\", with some other\n       commits that probably are ancestors of these commits marked\n       as UNINTERESTING.\n\n     may be a promising approach to go.  In the sample history\n     depicted above, we would want an equivalent to\n\n       $ git log --oneline --graph HEAD HEAD@{1} HEAD@{2} --not HEAD~2\n\n     where the positive commits are gathered by inspecting the\n     reflog for commits newer than 2024-02-20, and then list of\n     negative commits (HEAD~2 in this case) is somehow computed to\n     stop the usual \"git log\" traversal from these positive commits\n     after showing all of them (and before showing other commits not\n     in that initial set).\n\nThoughts?\n\n\n[Footnotes]\n\n *1* It may be an interesting side project to teach show-branch to\n     store the bits it uses to paint commits in commit slabs,\n     instead of using the object flags, to lift this limitation.\n     I'll not put the l e f t o v e r b i t s label on this item, as\n     it certainly is an interesting exercise but its usefulness is\n     rather dubious.\n\n *2* \"walking\" reflog stresses the fact that HEAD@{2} came\n     immediately before HEAD@{1} which came immediately before\n     HEAD@{0} (or HEAD, which are equivalents), but in this use\n     case, it is equally (if not more) important that the snapshots\n     taken on 2024-02-22, 2024-02-23, and on 2024-02-24 are more or\n     less equals, with the latest one a bit more important than\n     others because it is on the branch while the other ones are not\n     and merely appear in the reflog.\n"},{"id":"489655","messageId":"ZeBWhkSwec7PmQID@ugly","threadId":"60984","inReplyTo":"xmqqo7c5n0ob.fsf@gitster.g","subject":"Re: [RFD] should \"git log --graph -g\" work and if so how?","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-02-29T10:03:50Z","receivedAt":"2024-02-29T10:03:56Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Sat, Feb 24, 2024 at 11:04:52AM -0800, Junio C Hamano wrote:\n>Now, if I could run\n>\n>    $ git log --oneline --graph -g --since=2024-02-20 --boundary\n>\n>on the result, such a history might look like this:\n>\n>    * snapshot as of 2024-02-24 (HEAD)\n>    | * snapshot as of 2024-02-23 (HEAD@{1})\n>    |/\n>    | * snapshot as of 2024-02-22 (HEAD@{2})\n>    |/\n>    * add 'bar' (HEAD~1)\n>    o add 'foo' (HEAD~2)\n>\n>to show the same history.\n>\n>Unfortunately, \"--graph\" and \"-g\" does not mix X-<.\n>\n>So, the RFD is,\n>\n> (1) Should \"git log\" learn a trick to show a history like this in a\n>     readable way?  Does it have utility outside this use case of\n>     mine?  I am not interested in adding a new feature just for\n>     myself ;-)\n>\ni'm not sure i fully understand your use case; i failed to extract the\nconceptual requirements from your description.\n\nbut as a \"heavy revisionist\", i would appreciate it very much if there\nwas a convenient way to list and diff revisions of the same logical\ncommit (ideally omitting empty rebases). sort of like a range-diff on\nsteroids.\n\nthis would certainly require correlating the reflog with some stable\ncommit ids, like gerrit and jj maintain.\n\n\n"}]}