From: Martin Langhoff Date: Mon, 23 Jul 2007 14:19:56 GMT Subject: Re: What is a reasonable mixed workflow for git/git-cvsserver? Message-ID: <46a038f90707230719i106e0576j2868548ef0cb1739@mail.gmail.com> In-Reply-To: On 7/23/07, Steffen Prohaska 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 > >