Proposal that we now create two branches - 2_5 and head

[Craig Barratt]

> I have several patches that I'm planning to check in soon (I'm waiting
> to see if we have any post-release tweaking to and/or branching to do).
> This list is off the top of my head, but I think it is complete:

And I have several things I would like to work on and submit:

 - Fix the MD4 block and file checksums to comply with the rfc
   (currently MD4 is wrong for blocks of size 64*n, or files
   longer than 512MB).

 - Adaptive first pass checksum lengths: use 3 or more bytes of the MD4
   block checksum for big files (instead of 2).  This is to avoid almost
   certain first pass failures on very large files.  (The block-size is
   already adaptive, increasing up to 16K for large files.)

 - Resubmit my --fixed-checksum-seed patch for consideration for 2.6.x.

 - Resubmit my buffering/performance patch for consideration for 2.6.x.

 - For --hard-links it is only necessary to send <dev,inode> for files
   that have at least 2 links.  Currently <dev,inode> is sent for
   every file when the file list is sent.  In a typical *nix file
   system only a very small percentage of files have at least 2
   links.  Unfortunately all the bits in the flag byte are used,
   so another flag byte (to indicate whether <dev,inode> is
   present) would be necessary with --hard-links (unless someone
   has a better idea).  This would save sending up to 7 bytes
   per file (or actually as many as 23 bytes per file for 64 bit
   <dev,inode>).

Except for the last, all these items were discussed in this group over
the last few months.  The first two items and last item require a bump
in the protocol number, so I would like to include all of them together.

But before I work on these I would like to make sure there is interest
in including them.

Craig