From: Daniel P. <dp...@gm...> - 2015-04-06 18:47:42
|
Totally true. Depending on the type of workflow that Kaldi developers see, > there are up to 3 cloned repositories involved. This is what happens in the > project I maintain (https://github.com/fsprojects/FsLexYacc). We do not > accept any other way to submit changes to the main repository (which is a > bare repo in github) than using github's pull requests. Even people with > write access to the repo must follow this path. Since the pull request may > only be generated in github between 2 branches on repos necessarily stored > on gihub (although the branches may be in different repos, having a common > history fork in the past), the patch submitter must have cloned the main > repo at some point. This is the clone #2. > > Since the submitter obviously has to do some hacking first, he clones his > github clone #2 to a desktop, locally, and this is the clone #3. He > normally pushes into a branch or the master "trunk," and, come time to send > the changes upstream, issues a pull request for a diff between clones #1 > and #2 (or 2 points in history in #2). > > The only tricky part here is merging upstream changes into this train of > clones (analogous to "svn update") in such a way that the upstream changes > would not show up in the resulting pull request. > Perhaps you could explain how this is done? It might help us make an informed decision if you could give us some details on the workflow that you use, at the level of specific commands. Dan > > Another workflow would be allowing changes into the main trunk branch "the > svn way." To me, the main benefit of having the pending commits (as pull > requests) inspected by the peers is lost in this workflow. But the decision > is on Kaldi dev's I any case. > > It perhaps makes sense to write up a walk-through for first time git (or > github) users. I'd take on the task, but I need to play back the > step-by-step as I write, so I need time for the task. A workflow decision > must be done first, however. There might also be an existing guide on the > 'Net for those migrating from svn into the selected git workflow. > > -kkm > > > -----Original Message----- > > From: Phil Garner [mailto:Phi...@id...] > > Sent: 2015-04-05 0622 > > To: kal...@li... > > Subject: Re: [Kaldi-developers] Testing Github repository > > > > > So far, I pushed only the trunk and stable branch -- I'm not sure if > > > import of all sandboxes makes sense. > > > > If I understand the concept of sandboxes well, then in git they may > > better correspond to branches in user clones of the repository. That > > is, the person responsible for the sandbox clones the trunk repo and > > commits to a branch as they wish. Github makes this very easy. > > > > -- > > Phil Garner > > http://www.idiap.ch/~pgarner > > > > > > ----------------------------------------------------------------------- > > ------- > > Dive into the World of Parallel Programming The Go Parallel Website, > > sponsored > > by Intel and developed in partnership with Slashdot Media, is your hub > > for all > > things parallel software development, from weekly thought leadership > > blogs to > > news, videos, case studies, tutorials and more. Take a look and join > > the > > conversation now. http://goparallel.sourceforge.net/ > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > |