Re: onwards to git

[Jim Meyering <jim at meyering dot net>]

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.