git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jacob Stopak <jacob@initialcommit.io>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Newbie contribution idea for 'git log --children': input requested
Date: Thu, 15 Sep 2022 00:08:10 -0500	[thread overview]
Message-ID: <YyKzOk5AQBz1pmAh@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqillth1am.fsf@gitster.g>

On Sun, Sep 11, 2022 at 05:41:21PM -0700, Junio C Hamano wrote:

> > But I'm wondering if it could be addressed by simply adding a
> > discrete check to see if any commits point to HEAD as a parent,
> > (only when the --children option is used of course), and if so,
> > populate those ids into the log message.
> 
> In a history where all commits and their parent-child relationship
> can be enumerated and the links can be reversed in-core, it would be
> trivial to implement.  The challenge is to make sure it works
> without wasting unusably large resources to do so in a real world
> project.  Having a commit-graph might help.

I talked a little with Jacob about this at the contributor summit. As
I don't think I've ever used --children myself, I was curious about the
use case. :)

I think it is that one might want to do something like:

   git log --children $some_old_oid

and get a better idea of what was going on around the commit, both
before and after. And there I think that yeah, enumerating all available
commits to build the reverse index would make sense.

I don't think it would be a strict fix for --children, though, for two
reasons:

  - the current --children is free-ish because we're marking the commits
    as we traverse, so no extra parsing is required (just some storage
    for the reverse index)

  - the semantics aren't quite the same. One obvious issue is that you
    might care more about children reachable from your starting tips
    than arbitrary (possibly unreachable) children in your object store.
    But another is that --children implies parent rewriting, so it's not
    a strict reversal of the parent-child links.

So we'd want to retain the existing --children, and this new mode might
become --children=all or something.

Just sketching out an implementation, I think it is kind of similar to
the "decorate" mechanism, where we build the commit->metadata mapping
ahead of time, and then add output to the commits that we show. So we'd
probably want to load it around the same time we call
load_ref_decorations().

The next question is: what do we put in it?

One idea is to just reverse all the commits we know about. I.e., use
for_each_loose_object() and for_each_packed_object(), similar to the way
"cat-file --batch-all-objects" works. Use lookup_commit_in_graph() to
use the commit-graph when we can, and check object types via
oid_object_info() before trying to parse them (so we can avoid loading
non-commits from disk entirely).

But another idea is to do a _separate_ traversal in order to decide
which commits to care about. Then we have to know which tips to start
that traversal from, and we may end up with something similar to
--decorate-refs in terms of expressing that traversal. But I suspect the
output here is more interesting to the user, because now you can ask
just about reachable children, or children reachable from release tags,
or from a specific branch, etc.

So you could do something like:

  git show --children=refs/heads/* $some_old_commit

and see where we went from $some_old_commit that eventually ended up on
a branch.

But getting back to the original use case, which is about providing
context for a commit: now we have the child commit id, but it's still a
bit of a pain to actually see what it's in it.

I usually solve this by doing a single traversal, and asking the pager
to jump straight to the commit of interest, at which point I can scroll
up and down to see the context. Like:

  git log --color | less +/$some_old_commit

I'm not 100% sure I understand the original use case. But if I do, and
that solves it, I wonder if we could make it more ergonomic somehow.
Likewise, I think using something like "tig" would be nice for viewing
context, but AFAIK it does not have an option to jump to a specific
commit. You can jump by line number, but it would be nice to be able to
do:

  tig --highlight=1234abcd

and get a graph starting at HEAD, but jump immediately to the line for
1234abcd.

-Peff

  reply	other threads:[~2022-09-15  5:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-11 23:09 Newbie contribution idea for 'git log --children': input requested Jacob Stopak
2022-09-12  0:41 ` Junio C Hamano
2022-09-15  5:08   ` Jeff King [this message]
2022-09-15 17:08     ` Junio C Hamano
2022-09-18  3:19     ` Jacob Stopak
2022-09-20 22:28       ` Jeff King
2022-09-21  0:24         ` Jacob Stopak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YyKzOk5AQBz1pmAh@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob@initialcommit.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).