Re: Access to CVS

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

On 7 Dec, Peter Stephenson wrote:
> I'm expecting (from my limited knowledge of git) that git-aware people
> will do the following:
> 
> - Play with the change locally, committing it, possibly multiple times.
>   I don't see any reason you'd *have* to do this, it just strikes me
>   as the natural way a developer used to git would work, so you have
>   a record in the archive of what went to the list.  The ability to
>   do this is one of the big advantages of the distributed system.
> - Send the overall diff of the changes to the mailing list.
> - If it needs tweaking, there might be further local commits.
> - When it looks OK, push the set of changes to the main repository.

But would you want the "set of changes" to appear as several changes or
one single change in the main repository? And if other changes have been
applied since the patches were posted to the mailing list, would you
prefer that checksums are preserved but you have a merge commit?

For a project like zsh which has a small number of developers, I think
it is better to keep things simple and have a linear history (avoiding
merge commits). To produce that overall diff Peter mentions in the
second stage, you would probably use rebase to squash all your
intermediate steps. As with our current cvs practices, big changes that
warrant multiple patches, also warrant multiple mailing list posts. I
would also be happy if later tweaks also get squashed, especially if
we're stuffing X-Seq numbers in commit messages and checksums from a git
am are already invalidated. (The main advantage of git notes is that
checksums are preserved so you can apply a change from the mailing list
and it is handled more cleanly when the patch appears in the main
repository.)

Are people happy enough with the history as it is in the Sourceforge
mirror. Using it as-is has advantages for people that already use it.
I think that to make the switch, we essentially just need to ask Wayne
to turn off his cron job.

Oliver