Re: [ANNOUNCE] xfsprogs for-3.1.12 branch has been updated to 40c65a7

From: Ben Myers <bpm@sgi.com>
To: Rich Johnston <rjohnston@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [ANNOUNCE] xfsprogs for-3.1.12 branch has been updated to 40c65a7
Date: Tue, 28 Jan 2014 10:54:43 -0600	[thread overview]
Message-ID: <20140128165443.GO1935@sgi.com> (raw)
In-Reply-To: <52E7CE68.6030207@sgi.com>

Hey Rich,

On Tue, Jan 28, 2014 at 09:36:08AM -0600, Rich Johnston wrote:
> On 01/27/2014 10:20 PM, Dave Chinner wrote:
> >On Mon, Jan 27, 2014 at 12:46:58PM -0600, Rich Johnston wrote:
> >>Arkadiusz,
> >>
> >>Thanks for compiling the list.
> >>
> >>The for-3.1.12  Branch created from "a547280... 3.1.11 release"
> >>
> >>If there are others you want committed, please let me know.
> >
> >What testing have you done on the branch?
> 
> Just a quick test.  I wanted to get it out for others who are
> interested in this branch to start testing.
> 
> >
> >>40c65a7... xfs_metadump: Make -F (force) optional
> >>ec3a1f1... xfs_repair: suggest reboot after dangerous repair
> >>8660952... xfsprogs: suggest "-d" option for repair of RO mount
> >>5a8206c... xfs_repair: correct docs for "-t" units
> >>0d5c444... xfs_fsr: fix SWAPEXT failures under selinux
> >>f3d3dae... libxfs: fix root inode handling inconsistencies
> >>cf507b6... xfsprogs: remove xfs_check references from fsck.xfs
> >>script & manpage
> >>6e2f2d1... xfsprogs: fix resource leak in longform_dir2_rebuild()
> >>ecde3f9... xfs_repair: test for bad level in dir2 node
> >>d299df7... xfs_repair: avoid segfault if reporting progress early in repair
> >>e660c2e... Sent: Friday, October 11, 2013 12:38:11 AM Subject:
> >>Bug#725971: xfsprogs: config.guess/config.sub out of date for arm64
> >
> >Can you fix the subject line of this commit, please?
> 
> Sorry I missed that.
> 
> I can, but a git rebase --interactive e660c2e^ will change the
> commit ids after it.  Is there another way to do this that does not
> change the commit ids?

Any way you do it will change the commit ids.  Just don't worry about it.  If
you really don't want to lose those old commits, you can create a tag
for-3.1.12.bad to keep those old commits pinned in the repo, and then just
force replace the branch after your rebase.  Then you can remove the 'bad' tag
after the release is completed.  No big deal.

Regards,
	Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs