On 7/23/07, Steffen Prohaska <prohaska@xxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
