Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [commit 1/3] Import gnulib's update-copyright script
Date: Wed, 18 Apr 2012 15:10:00 -0000	[thread overview]
Message-ID: <4F8ED7F3.8010708@redhat.com> (raw)
In-Reply-To: <20120418145225.GC2852@adacore.com>

On 04/18/2012 03:52 PM, Joel Brobecker wrote:

>> I don't see how that scripts would have prevented the selective
>> check-in.  :-)
> 
> Perhaps not, but what I would have done was doing an update first,
> check that in, and then add the new module. WDYT?


Yes, that or the other way around, is the right way to do update gnulib.
We should never end up with a mix of files from different versions,
as that gets messy and undone with the next import.  See how Yao imported
inttypes recently -- he imported it from that same 2010 version.

> 
>> It may help by keeping the git version in some script variable, that
>> the script checks, instead of having to fetch the version from the
>> ChangeLog?  The new gnulib/ parent directory seems like a good place
>> for this stuff.
> 
> Sure. Since there does not appear to be gnulib releases, I was
> under the impression that we'd always go with the current head,
> somehow. 


Yeah, but of the whole gnulib as a unit.  There's a lot of dependencies
between the modules.  And there's no telling if some random import
would break some host, due to some gnulib, so it's best if we know
exactly which version was used.

> Having the hash in the script is a good idea, makes
> things completely reproduceable...


Exactly.

Okay, we're in violent agreement at this point.  :-)

I'll go update gnulib to the current version.

-- 
Pedro Alves


  reply	other threads:[~2012-04-18 15:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04  8:20 New procedure for updating copyright years Joel Brobecker
2012-01-04  8:20 ` [RFA/doco 3/3] Document new " Joel Brobecker
2012-01-04 18:24   ` Eli Zaretskii
2012-01-05  3:34     ` Joel Brobecker
2012-01-05  5:44       ` Eli Zaretskii
2012-01-05  9:42         ` Joel Brobecker
2012-01-04  8:20 ` [commit 2/3] use gnulib's update-copyright script to update " Joel Brobecker
2012-01-04  8:20 ` [commit 1/3] Import gnulib's update-copyright script Joel Brobecker
2012-04-18 12:41   ` Pedro Alves
2012-04-18 14:37     ` Joel Brobecker
2012-04-18 14:52       ` Pedro Alves
2012-04-18 14:54         ` Joel Brobecker
2012-04-18 15:10           ` Pedro Alves [this message]
2012-04-18 15:12           ` Tom Tromey
2012-04-18 20:52     ` Import gnulib's update-copyright whole module Pedro Alves

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=4F8ED7F3.8010708@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.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