Re: Access to CVS

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:
> 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).

I agree.

> To produce that overall diff Peter mentions in the
> second stage, you would probably use rebase to squash all your
> intermediate steps.

Just to clarify: You don't mean to squash everything to one blob of
changes, if there were logically separated changeset in the commits
before, right?

You mean to use interactive rebasing to get rid of those "Crap, forgot a
semicolon here and there." commits before submitting to the list?

> 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.

I think git-am would still work if we had something that would scan a
saved mail for the X-Seq: header, amend Subject and then feed that into
git-am.

> (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.)

Sure, but how well are notes supported within git as a whole? Also, who
would we make sure adding notes isn't forgotten?

I think everything, that saves a manual step should be encouraged.

> 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.

Pretty much, except for re-doing the $ZSH_PATCHLEVEL variable, which
currently is fed the patchlevel from CVS.

Regards, Frank