onwards to git
Jim Meyering
jim@meyering.net
Tue May 12 14:47:00 GMT 2009
Thomas Schwinge wrote:
> Hello!
> On Mon, May 11, 2009 at 10:49:32PM +0200, Jim Meyering wrote:
>> I've converted the trunk and all branches, filtering
>> to aggregate commits, and cleaning up by removing empty commits
>> and applying heuristics to use reasonable commit messages
>> derived from ChangeLog entries.
>
> This indeed looks very nice in the vast majority of cases! I'm sure
> there are a number of people who are interested in seeing the scripts and
> techniques you used. I am, for sure. :-)
Hi Thomas,
Thanks for the feedback!
I'll post the scripts, of course ;-)
If I don't do it this week it's because I forgot or didn't
find the time, so a ping would be welcome.
> In case that you go over it again, here are three things you may want to
> consider, or, of course, declare that they don't matter too much:
>
> You may want to have your script filter out duplicate bugzilla ids, like
> in 66ade7948c17d0d5d2b624226b81805a169747dd: ``[BZ #4465, BZ #4465, BZ
> #4465, BZ #4465, BZ #4465]''. But that is completely a minor thing.
Good one.
There's worse: for ChangeLog-only changes
(rotation of ChangeLog to ChangeLog.N), we have subjects like this:
[BZ #1079, BZ #1080, BZ #1101, BZ #1097, BZ #653, BZ #1088, BZ #1088, BZ #10
85, BZ #1096, BZ #1086, BZ #1086, BZ #1086, BZ #1083, BZ #1093, BZ #1094, BZ #10
81, BZ #1090, BZ #1082, BZ #1087, BZ #1098, BZ #549, BZ #1101, BZ #1095, BZ #110
0, BZ #1103, BZ #1100, BZ #1099]
It's obviously not useful to list all of those BZ numbers with every
ChangeLog-rotation delta. In fact, it'd be misleading/time-wasting
for anyone searching for changes relating to the listed BZ numbers.
So for ChangeLog-rotation deltas (detected by > 1000 lines of added
ChangeLog lines), I refrain from hoisting BZ numbers from diffs into
commit-log. For others, I eliminate duplicate BZ numbers and sort.
> Another thing I noticed by pure chance: around / with
> cvs/glibc-2_6-branch there is an out-of-order commit:
>
> RMG 2007-07-10 02:39:31 518d13d01b384f9ba702f6e18aa8af478838e8c6
> UD 2007-07-09 18:12:05 0935b78139037f52f204ee1a66e095e616403e65
> JJ 2007-07-31 15:39:49 3bc457a5d8a75d82213e3cd7b20219dedcd6fe09
> UD 2007-07-09 18:11:50 85b0053cd3d3d92de8088974c97a934f2c0ce981
>
> The 3bc45 commit introduces a huge amount of changes that are undone in
> the 0935b one again:
Well spotted!
That is due to the fact that the aggregation script was preserving
all GIT_AUTHOR_DATEs, but missed particular, aggregation-related
GIT_COMMITTER_DATEs. I think I've just fixed the script to deal with that.
I've confirmed via a partial conversion that JJ's commit is now up
around other July-31 changes, where it belongs.
Now, I'm about re-convert from scratch -- and then I'll repeat
the branch/tag-renamings.
> $ git diff 85b00..0935b --stat
> ChangeLog | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> I did not systematically search for other problems like this.
>
>
> The branch-off for cvs/glibc-2_10-branch is done too early; this is a
> problem with the
> sysdeps/unix/sysv/linux/powerpc/powerpc*/power6/fpu/*context.S files:
> compare commit 1a345b10310e0290d5b2e0030acf148e496cefcb to
> e54e51a1929135737ee49bc4bbf57bfee00a8eab -- which should be the same.
Good catch.
This has a story behind it:
- for the "final" rsync (to sync CVS repo to local) I forgot to use
rsync's --delete option, and thus did not record locally the
movement of those .S,v files into Attic/.
- as such, upon cvs-to-git conversion, they were still present, and when
I checked out "master" from git and compared, I noticed the difference.
- I compensated by manually rebasing the removal into the master BZ
commit, and manually re-applying the tags and branch.
I didn't realize I'd need to make the same manual change on the branch.
Obvious moral: don't do it manually ;-)
It'll be at least 3 hours.
More information about the Libc-alpha
mailing list