git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: David Woodhouse <dwmw2@infradead.org>
Cc: git@vger.kernel.org
Subject: Re: Kernel headers git tree
Date: Fri, 14 Jul 2006 11:01:54 -0700	[thread overview]
Message-ID: <7v64i0qd4d.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <1152869915.3191.12.camel@pmac.infradead.org> (David Woodhouse's message of "Fri, 14 Jul 2006 10:38:35 +0100")

David Woodhouse <dwmw2@infradead.org> writes:

> Yet what I actually want in the final result is "those commits which
> change the result of the _exported_ headers". It's slightly less
> realistic to want rev-list to find that for me directly from the
> original kernel tree without having done the export step in stage1 --
> what I need to do is create the exported header tree for each commit
> which _might_ change it, then filter out the commits which don't
> _actually_ change it.
>
> The extra commits in the stage1 branch are cheap enough -- by definition
> they don't lead to any extra tree or blob objects. I think the two-stage
> export is probably the best approach, unless I'm missing something.

Since you are not building an exact parallel history with the
same topology (you are trying to cull the commits in the new
tree that do not change the resulting header files), I do not
see much point in the parent conversion loop in the first script
to compute CONVERTEDPARENTS.

How about making it simpler?

	* Keep the current HEAD of the "headers" branch at in
          refs/heads/kernel-headers

	* Whenever you see $UPSTREAM_GITDIR/refs/heads/master
          changes, you do your converttree to come up with the
          new header tree

	* See if the resulting tree changed by doing something
          like this:

                TREE=`converttree $INCDIR $KBUILDASMSHA`
                case "`git diff-tree --name-only kernel-headers $TREE`" in
                '')
                        # No changes in the result
                        exit
                esac

	  Stop processing here if there is no change.

	* Make a new commit, with its parent set to the current
          value of refs/heads/kernel-headers, perhaps with the
          same message as $UPSTREAM_GITDIR/refs/heads/master
          has as you do already.

	* Advance refs/heads/kernel-headers only when you
          actually make a new commit.

I would further suggest to record the value of the upstream
commit object name, $UPSTREAM_GITDIR/refs/heads/master,
somewhere in the commit message, by using "git describe".  This
will help people who use your converted headers to know which
released version of the Linus kernel the headers correspond to,
and also help you notice when the upstream is updated during the
next run.

  parent reply	other threads:[~2006-07-14 18:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-13 23:59 Kernel headers git tree David Woodhouse
2006-07-14  0:39 ` Junio C Hamano
2006-07-14  0:56   ` David Woodhouse
2006-07-14  1:08     ` Linus Torvalds
2006-07-14  2:37     ` Junio C Hamano
2006-07-14  1:05   ` Linus Torvalds
2006-07-14  1:27     ` David Woodhouse
2006-07-14  5:16       ` Linus Torvalds
2006-07-14 10:23         ` David Woodhouse
2006-07-14 15:57           ` Linus Torvalds
2006-07-14 17:51             ` Daniel Barkalow
2006-07-14 17:58               ` David Woodhouse
2006-07-14 18:21                 ` Daniel Barkalow
2006-07-14  5:52       ` Linus Torvalds
2006-07-14  9:38         ` David Woodhouse
2006-07-14 15:39           ` Linus Torvalds
2006-07-17 22:34             ` [PATCH] Trivial path optimization test Alex Riesen
2006-07-24  6:41               ` Junio C Hamano
2006-07-24 23:23                 ` Alex Riesen
2006-07-24 23:23             ` Alex Riesen
2006-07-14 18:01           ` Junio C Hamano [this message]
2006-07-14 18:21             ` Kernel headers git tree David Woodhouse
2006-07-14  7:20 ` Ian Campbell
2006-07-14  7:52   ` Junio C Hamano
2006-07-14 18:05 ` Ingo Oeser
2006-07-14 18:16   ` David Woodhouse
2006-07-18 21:15     ` Ingo Oeser

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

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

  git send-email \
    --in-reply-to=7v64i0qd4d.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=dwmw2@infradead.org \
    --cc=git@vger.kernel.org \
    /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.
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 NNTP newsgroup(s).