Re: [Kaldi-developers] Testing Github repository

[Kirill K. <kir...@sm...>]

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.

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