This is the mail archive of the
mailing list for the binutils project.
Re: File missing from the git: texinfo/texinfo.tex
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>, binutils at sourceware dot org, gdb at sourceware dot org
- Date: Thu, 24 Oct 2013 10:56:15 +0100
- Subject: Re: File missing from the git: texinfo/texinfo.tex
- Authentication-results: sourceware.org; auth=none
- References: <201310231640 dot r9NGeOjY029105 at ignucius dot se dot axis dot com> <874n88dj74 dot fsf at fleche dot redhat dot com>
On 10/23/2013 05:51 PM, Tom Tromey wrote:
>>>>>> "Hans-Peter" == Hans-Peter Nilsson <email@example.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").