Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > I wonder if it would make sense to teach the revision walking machinery > about reflogs. A commit could be marked as coming from a reflog entry, and > in that case the parents could be determined by the reflog rather than the > commit itself. The revision machinery already knows about reflogs with --reflog, used by git-pack-objects via git-repack. But here its really only useful to seed the list of commits to be walked as part of a pack generation, to make sure the things referenced by the reflog stay around after a repacking. And it implies --all. Rewriting the commits in memory to appear to have parents based on their order of appearence in the reflog would nicely generate a single strand of perls, but it makes it difficult to then access the same commit's real parents, doesn't it? So that may make the revision machinary somewhat limited in some applications. Besides we want the reflog message entry and not the commit message when we perform pretty output, etc. So really we are then talking about generating synthetic commit objects for the reflog data. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html