git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: Kernel headers git tree
Date: Fri, 14 Jul 2006 10:38:35 +0100	[thread overview]
Message-ID: <1152869915.3191.12.camel@pmac.infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0607132251310.5623@g5.osdl.org>

On Thu, 2006-07-13 at 22:52 -0700, Linus Torvalds wrote:
> Btw, I'm actually surprised that my path simplification didn't filter out 
> the "." and make it mean exactly the same as not giving a path at all. I 
> thought I had done that earlier, but if you say "-- ." matters, then it 
> obviously does..

In this specific case where I have a whole bunch of commits which don't
actually change anything, it definitely does make a difference...

hera /home/dwmw2 $ export GIT_DIR=/pub/scm/linux/kernel/git/dwmw2/kernel-headers.git
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1
e4e2fcc2c333aac5f6331c1df256ff28d7ee76d7
32ca8021c5ab7b9d44e8a08aeb53e52af5223fec
6b8380885464e069ae22e1e04f4a905c9e918f4e
2dee58696cab32506f655cb94a63cf4b18a13b37
402429bc9ac5eb891f253f6dae1228338f7f0ea5
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1 -- .
d1aba9314210d616cd2aa9ee91176c1dba6d3834
0b627fd403d6319fe50fbd8b95d5ea02017731fa
b29cfa21bbdfc25271ef446b9df94ed8b5425711
e2407b6a9a643b378700474c9079dd8620e820ed
c0df084d3e2ec0df6dafda8099e7c27c29760843

Junio is right -- if I can avoid creating commits that don't change any
files in the stage1 branch, then I don't have to do this. That would be
_hard_ though...

Currently, the selection of commits from your original tree to be
represented in the stage1 branch is simple -- it's "those commits which
touch include/". And 'rev-list -- include'  works nicely for that.

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.

-- 
dwmw2

  reply	other threads:[~2006-07-14  9:39 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 [this message]
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           ` Kernel headers git tree Junio C Hamano
2006-07-14 18:21             ` 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=1152869915.3191.12.camel@pmac.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.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).