Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>,
	binutils@sourceware.org,        gdb@sourceware.org
Subject: Re: File missing from the git: texinfo/texinfo.tex
Date: Thu, 24 Oct 2013 09:56:00 -0000	[thread overview]
Message-ID: <5268EEBF.2040805@redhat.com> (raw)
In-Reply-To: <874n88dj74.fsf@fleche.redhat.com>

On 10/23/2013 05:51 PM, Tom Tromey wrote:
>>>>>> "Hans-Peter" == Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
> Hans-Peter> Just a heads-up.
> Hans-Peter> Looks like at least one file didn't make it in the git
> Hans-Peter> conversion; worse, one needed by the src-release targets (which
> Hans-Peter> is used to build releases and snapshots): texinfo/texinfo.tex.
> 
> Hans-Peter> This will cause problems with people's autotesters and snapshot
> Hans-Peter> creation.  (Tom Tromey is alerted and on it; the git may have to
> Hans-Peter> be re-created or something like that.)
> 
> I had put texinfo into the list of directories to remove before
> conversion.  This caused the problem.
> 
> I think there are two choices to fix it.
> 
> One, fix my script and redo the conversion.  This is easy, though (1) it
> takes quite a lot of time, (2) any git commits since the first
> conversion will have to be re-applied (there aren't many -- I can handle
> it), and (3) any work anybody else has done on a clone of the repository
> will have to be redone.
> 
> The argument for this choice is mainly that it is more true to the
> history.  E.g., with the current git repository you can't faithfully
> re-create old releases.

Yeah.   If it were up to me, I'd just bite the bullet and do this.  The
existing repo doesn't need to be shut down while the recreation takes
place.  That can be done offline while the current repo is still up,
until a point when the git commits are re-applied (and git here
allows easily preserving all the commit's info: authors, dates, etc.).

So it seems to me the only downside is requiring people to refetch and
rebase.  Personally, I think the repo is young enough for that to not
be a real problem.  I have 180 local branches and with the approach
I sent the other day in the "git is live" thread, it just takes me
a couple minutes, and the occasional rebase ("git rebase --onto",
or if use stgit like me, just plain "stg rebase").

-- 
Pedro Alves


  parent reply	other threads:[~2013-10-24  9:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 16:40 Hans-Peter Nilsson
2013-10-23 16:51 ` Tom Tromey
2013-10-23 16:55   ` Fred Cooke
2013-10-23 17:05     ` Tom Tromey
2013-10-23 17:00   ` Paul Smith
2013-10-23 17:04   ` Hans-Peter Nilsson
2013-10-24  9:56   ` Pedro Alves [this message]
2013-10-24 11:37     ` Joel Brobecker
2013-10-24 13:50     ` Tom Tromey
2013-10-24 15:50       ` Hans-Peter Nilsson

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=5268EEBF.2040805@redhat.com \
    --to=palves@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=tromey@redhat.com \
    /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