Re: What is a reasonable mixed workflow for git/git-cvsserver?

["Martin Langhoff" <martin.langhoff@gmail.com>]

On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:
> If several people commit to the same shared branch exported by
> git-cvsserver they most likely will generate a series of unsorted
> commits, as they did in the past on a single cvs branch. The
> commits will probably deal with various topics, include bug fixes,
> and some are likely more experimental and not really ready for a
> stable branch.

Keep the good commit message practices ;-) in my projects I tend to
mimic the linux and git "style" for commit msgs.

> My question is how to deal with this shared branch on the git
> side. Should a core developer rebuild a sane history from such
> a shared/mixed/unsorted branch by cherry picking the commits
> to one or more topic branches?

I think that's usually frowned upon. As the committer did his/her work
on a particular state of the tree, and tested it. So every commit at
least *should* be of a working state. Once you rewrite history as a
"normal" practice, that flies out of the window. And it's a big loss.

In a sense, it's  a "history that looks tidy but is false". And it's
extra work too. I very strongly prefer good commit messages, and the
real history.

> If one did so, how could one
> bring the git-ish history back to the people connected by cvs?
> Am I allowed to reset branches exported by git-cvsserver?
> Probably not?

Indeed not. Junio rewinds/rebases pu (the proposed updates branch
mentioned earlier) regularly,  but you can only do that in a pure-git
project, and with fairly experienced git users (so if they get caught
with commits on top of a rewound pu branch they'll know what to do).
cvsserver doesn't know what to do with rewinds/rebases and, more
importantly, cvs clients can't cope with it. And that is something we
cannot fix, unfortunately.

cheers,


martin



>         Steffen
>
>