{"thread":{"id":"9165","subject":"What is a reasonable mixed workflow for git/git-cvsserver?","startedAt":"2007-07-23T06:28:17Z","lastAt":"2007-07-23T15:06:01Z","messageCount":6,"participants":["Steffen Prohaska","Johannes Schindelin","Martin Langhoff","Brian Gernhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48267","messageId":"E8B0B250-A428-4CDC-A4D2-FFCF45953076@zib.de","threadId":"9165","inReplyTo":null,"subject":"What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-23T06:28:17Z","receivedAt":"2007-07-23T06:28:17Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"I plan to migrate a project from cvs to git and provide\nlegacy support for cvs users through git-cvsserver. It's\nnot realistic to teach all people at the same time to use\ngit. We need some early adopters first. It is also likely\nthat we start migrating only parts of the repository and\nkeep some other parts in cvs. I plan to start with parts\nfor which the benefits of git's support for merging are\nmost obvious.\n\nWhat's a reasonable workflow when some people use git and\nother people use git-cvsserver simultaneously?\n\nI can imaging that we try the typical git model with\ndevelopers who are using git. Developers would clone to\nprivate repositories and ask upstream maintainers to merge.\n\nI'm wondering how to integrate people that will not yet use\ngit but checkout and commit through git-cvsserver?\n\nWe could easily arrange a stable branch for cvs access that\nshould be accessed read-only. Work merged using git would\nbe published to this branch. I can also think of specific\ntopic branches that are created upon request by a git\nexpert and accessed from cvs through git-cvsserver. Merging\ncould be done by a git expert using git. An inconvenience\nis that people must do a fresh checkout to switch to a\ntopic branch but can not use 'cvs up -r'. At least this is\nmy understanding of git-cvsserver's documentation.\n\nI have no clear idea how to deal with the shared rest. We\ntypically share work in an unsorted way on a cvs branch,\nwhich everyone commits to. I think we'll need a similar\npossibility, at least for a transition period. We could\ncreate such a shared branch for access from git-cvsserver.\n\nWhat is a reasonable way to handle the unsorted commits\nfrom a shared branch in a more git-ish way? I googled a bit\nbut didn't find a good explanation on the web.\n\nAny ideas, any real-world experiences?\n\n\tSteffen\n"},{"id":"48293","messageId":"Pine.LNX.4.64.0707231106590.14781@racer.site","threadId":"9165","inReplyTo":"E8B0B250-A428-4CDC-A4D2-FFCF45953076@zib.de","subject":"Re: What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-23T10:16:52Z","receivedAt":"2007-07-23T10:16:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 23 Jul 2007, Steffen Prohaska wrote:\n\n> What's a reasonable workflow when some people use git and other people \n> use git-cvsserver simultaneously?\n\nThis is what we did here:\n\nWe cvsimported the whole stuff (but we did not have your problems, since \nthere was only one branch).  Then we initialised a shared repository with \nthat branch, turned on git-cvsserver (and found a few bugs, but that was \nlong ago, and AFAIR all our issues were fixed) and went to work.\n\nThere were a few committing via cvs, and a few others committing via git.  \nOne person only tracked via cvs, not contributing code, just reviewing \nand testing.\n\nWe did not have the need to impose certain restrictions, such as git-shell \n(to prevent invoking other programs), or hooks refusing a push that \ntouches parts the person pushing has no business changing.\n\nBut we had the option to go there, if needed.  So far, all went fine.  And \nI'm convinced that it is partly because of the trust model.  After all, I \nstill have my local repository.  And that I can trust at all times.\n\nSo if a poisonous person (instead of thrashing the mailing list with long \nmails) would have decided to corrupt the repo, we would have realised that \npretty quickly, repaired the damage without much effort, and kicked out \nthat person.\n\nNeedless to say that all our devs converted to Git.  And I'm happy to say \nthat they're all happy with it.\n\nCiao,\nDscho\n"},{"id":"48300","messageId":"46a038f90707230359u5fac77a4i7b6a350d3bb29e3b@mail.gmail.com","threadId":"9165","inReplyTo":"E8B0B250-A428-4CDC-A4D2-FFCF45953076@zib.de","subject":"Re: What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-07-23T10:59:26Z","receivedAt":"2007-07-23T10:59:26Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:\n> What's a reasonable workflow when some people use git and\n> other people use git-cvsserver simultaneously?\n\nIt was written on the concept that the core developers would switch to\ngit and occassional committers and less sophisticated SCM users like\ntranslators would be able to continue using cvs.\n\nBasically, cvs users can no longer tag or open new branches. So your\nplan is exactly what we set out to support. Switching branches is not\npossibe -- that's unfortunate, but emulating CVS's branching is a\nbridge too far :-)\n\n> What is a reasonable way to handle the unsorted commits\n> from a shared branch in a more git-ish way? I googled a bit\n> but didn't find a good explanation on the web.\n\nI am not sure what you mean by unsorted commits... \"proposed patches\"?\nThe git project itself has a proposed-updates branch that might serve\nas an example. And repo.or.cz has the strange concept of the mob\nbranch that you might want to have a look at.\n\ncheers,\n\n\nmartin\n"},{"id":"48302","messageId":"AD8AD244-0B20-44E9-AEE6-9D2A75BC5091@zib.de","threadId":"9165","inReplyTo":"46a038f90707230359u5fac77a4i7b6a350d3bb29e3b@mail.gmail.com","subject":"Re: What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-23T11:34:56Z","receivedAt":"2007-07-23T11:34:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 23, 2007, at 12:59 PM, Martin Langhoff wrote:\n\n>> What is a reasonable way to handle the unsorted commits\n>> from a shared branch in a more git-ish way? I googled a bit\n>> but didn't find a good explanation on the web.\n>\n> I am not sure what you mean by unsorted commits... \"proposed patches\"?\n> The git project itself has a proposed-updates branch that might serve\n> as an example. And repo.or.cz has the strange concept of the mob\n> branch that you might want to have a look at.\n\nThe mob branch seems to be related, although I do not plan for\nan anonymous mob but only for the cvs mob ...\n\nIf several people commit to the same shared branch exported by\ngit-cvsserver they most likely will generate a series of unsorted\ncommits, as they did in the past on a single cvs branch. The\ncommits will probably deal with various topics, include bug fixes,\nand some are likely more experimental and not really ready for a\nstable branch.\n\nMy question is how to deal with this shared branch on the git\nside. Should a core developer rebuild a sane history from such\na shared/mixed/unsorted branch by cherry picking the commits\nto one or more topic branches? If one did so, how could one\nbring the git-ish history back to the people connected by cvs?\nAm I allowed to reset branches exported by git-cvsserver?\nProbably not?\n\n\tSteffen\n"},{"id":"48309","messageId":"46a038f90707230719i106e0576j2868548ef0cb1739@mail.gmail.com","threadId":"9165","inReplyTo":"AD8AD244-0B20-44E9-AEE6-9D2A75BC5091@zib.de","subject":"Re: What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-07-23T14:19:56Z","receivedAt":"2007-07-23T14:19:56Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:\n> If several people commit to the same shared branch exported by\n> git-cvsserver they most likely will generate a series of unsorted\n> commits, as they did in the past on a single cvs branch. The\n> commits will probably deal with various topics, include bug fixes,\n> and some are likely more experimental and not really ready for a\n> stable branch.\n\nKeep the good commit message practices ;-) in my projects I tend to\nmimic the linux and git \"style\" for commit msgs.\n\n> My question is how to deal with this shared branch on the git\n> side. Should a core developer rebuild a sane history from such\n> a shared/mixed/unsorted branch by cherry picking the commits\n> to one or more topic branches?\n\nI think that's usually frowned upon. As the committer did his/her work\non a particular state of the tree, and tested it. So every commit at\nleast *should* be of a working state. Once you rewrite history as a\n\"normal\" practice, that flies out of the window. And it's a big loss.\n\nIn a sense, it's  a \"history that looks tidy but is false\". And it's\nextra work too. I very strongly prefer good commit messages, and the\nreal history.\n\n> If one did so, how could one\n> bring the git-ish history back to the people connected by cvs?\n> Am I allowed to reset branches exported by git-cvsserver?\n> Probably not?\n\nIndeed not. Junio rewinds/rebases pu (the proposed updates branch\nmentioned earlier) regularly,  but you can only do that in a pure-git\nproject, and with fairly experienced git users (so if they get caught\nwith commits on top of a rewound pu branch they'll know what to do).\ncvsserver doesn't know what to do with rewinds/rebases and, more\nimportantly, cvs clients can't cope with it. And that is something we\ncannot fix, unfortunately.\n\ncheers,\n\n\nmartin\n\n\n\n>         Steffen\n>\n>\n"},{"id":"48311","messageId":"7D018B3B-CE12-46C4-87EA-9BE14EC415E4@silverinsanity.com","threadId":"9165","inReplyTo":"46a038f90707230719i106e0576j2868548ef0cb1739@mail.gmail.com","subject":"Re: What is a reasonable mixed workflow for git/git-cvsserver?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-07-23T15:06:01Z","receivedAt":"2007-07-23T15:06:01Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 23, 2007, at 10:19 AM, Martin Langhoff wrote:\n> On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:\n>> My question is how to deal with this shared branch on the git\n>> side. Should a core developer rebuild a sane history from such\n>> a shared/mixed/unsorted branch by cherry picking the commits\n>> to one or more topic branches?\n>\n> I think that's usually frowned upon. As the committer did his/her work\n> on a particular state of the tree, and tested it. So every commit at\n> least *should* be of a working state. Once you rewrite history as a\n> \"normal\" practice, that flies out of the window. And it's a big loss.\n\nThat's only somewhat true.  First, there's never a guarantee that the  \ncommitter tested it, especially if they had to pull before committing  \n(less likely they tested the resulting merge than tested their  \noriginal code).  Second, rewriting history isn't a big loss.  It's  \ndone all the time here on this list.  The patches I've sent in rarely  \nappear applied on top of the commit I made them from.  The mob branch  \ncould just be viewed as a set of patches to use, and it becomes the  \nmaintainer's job to test the results after cherry-picking from them.\n\n~~ Brian\n"}]}