Introductory mail

[Manoj Srivastava]

On Wed, Oct 01 2008, Guido Günther wrote:

> On Wed, Oct 01, 2008 at 08:33:56AM -0500, Manoj Srivastava wrote:
>> On Wed, Oct 01 2008, Guido Günther wrote:
>> 
>> > Patches are easily accesible from within gitweb (using Vcs-Browser) when
>> > the package uses git-dch to generate the changelog. Git-dch allows to
>> > store the abbreviated commit id in the changelog so people can find
>> > patches easily by looking at the changelog first:
>> >
>> > libvirt (0.4.6-1) experimental; urgency=low
>> >
>> >   * [e20d3d4] Imported Upstream version 0.4.6
>> >   * [0c840ab] disable numactl
>> 
>>         Darn. Yet another neat tool I have to rewrite (because of
>>  assumptions it makes about ./debian being in a branch).
> This can probably be fixed. We just need to find a way to tell git-dch
> were to look for changes, that could very well be in a repo +
> submodules.

        My first thought was to make is less clever. Assuming it is run
 from the integration (debian) branch, it can first find the top of the
 tree :
,----
|     base_dir=$(git-rev-parse --show-cdup 2>/dev/null) || return 1
|     if [[ -n "$base_dir" ]]; then
|         base_dir=$(readlink -f "$base_dir")
|     else
|         base_dir=$PWD
|     fi
`----

        Then it can explicitly look for $base_dir/.gitmodules, and for
 path = debian in there, to see if it is a module (alternately, simply
 look for $base_dir/debian/.git, which is less clever, but still works).

        Then it can just cd $base_dir/debian/, and gather more things to
 add. The problem probably is keeping track of a second set of commits;
 we need not just the build branch, we now need a ./debian submodule
 branch,

        I would code this up, but I would first have to write up git-dch
 in perl.

        manoj
-- 
The core is not frozen, but slushy. Larry Wall in
<199705101952.MAA00756 at wall.org>
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C