Re: [Kaldi-developers] Testing Github repository

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

I am entirely with you. Rebasing is changing history. It is totally OOK and useful to requite history to squash commits, fix unintended check-ins of huge binaries etc. Absolutely OK before you pushed your changes anywhere. But if there is a chance that the branch (simply speaking) was shared, then rebasing would create a problem for the sharing party, and must be closely coordinated with them, or better abandoned altogether.

 -kkm

> -----Original Message-----
> From: Ondrej Platek [mailto:ond...@gm...]
> Sent: 2015-04-07 0304
> To: Vassil Panayotov
> Cc: Alexander Solovets; kal...@li...; Kirill
> Katsnelson
> Subject: Re: [Kaldi-developers] Testing Github repository
> 
> Hi,
> 
> I just want to mentioned that I like git rebase for cleaning of my
> messy LOCAL history into much cleaner one.
> On the other hand, AFAIK github does not support rebasing as accepting
> somebodies work very well, and generally rebasing is sometimes
> discourage for public repositories.
> 
> There is quite nice comparison at
> https://www.atlassian.com/git/articles/git-team-workflows-merge-or-
> rebas
> e/
> 
> 
> Personally, I see the problem elsewhere with merging a PR.
> Let say that the PR branch history is clean at the beginning and a user
> submitted PR.
> The problem with merging and PR is when you decide not to merge the PR
> immediately and substantial work is needed.
> Probably multiple people will work on the PR branch and multiple
> branches will be created.
> Rebasing is now dangerous since it is already published, and the
> history gets messy.
> 
> Still I find it far more trivial than svn branching.
> 
> Ondra
> 
> 
> 
> 
> On Tue, Apr 7, 2015 at 11:24 AM, Vassil Panayotov
> <vas...@gm...> wrote:
> 
> 
> 	FWIW +1 from me to the migration to Git. Don't know if that will
> really encourage people to contribute more, but some say the ease of
> creating pull requests is helpful... Having a "Kaldi" GitHub
> organization may also increase the visibility of projects, built on top
> of Kaldi(e.g. Tanel Alumae's ASR server), or related to Kaldi(like PDNN
> or the Python wrappers that were discussed here not long ago). GitHub's
> support for organizations is really basic (AFAIK they don't even
> support following an organization), but hopefully they will (finally)
> improve that.
> 
> 	IMHO the workflow suggested by Kirill, where everyone submits
> pull requests to the "official" repository, that are merged (possibly
> after a review) seems good. I don't think the branching will be a
> problem. As I understand it, in the proposed workflow the history of
> the official repo will be entirely linear(fast forward commits into
> "master"). I've mostly used Git with single-user(i.e. me) repositories
> so far, but AFAIK it only becomes problematic if you rewrite the
> history by rebasing or amending commits in a branch that is jointly
> worked on with others. And even if that happens it should be easy to
> recover, because with Git everyone has the full project history on his
> desktop.
> 
> 	It's not very clear to me if this transition period of few months
> is needed and how it would be helpful if people are still using only
> SVN? I'd say if everyone agrees that Git is the way to go, the switch
> can be made as soon as the process of switching and the new workflow
> are documented. From the user's viewpoint it probably won't matter much
> if they type "svn up" or "git pull origin master". Also, I agree with
> Kirill that keeping SVN in sync after the switch could be probably an
> unnecessary hassle. Having a backup is obviously not a problem, because
> in couple of days of migration to Git, there will be enough full copies
> of the history distributed around the world to survive a dinosaur
> extinction- causing event (even though the usefulness of Kaldi in the
> aftermath is uncertain...).
> 
> 	I haven't been involved with such migrations though, so maybe I'm
> overlooking something...
> 
> 	Vassil
> 
> 
> 
> 	On Tue, Apr 7, 2015 at 9:12 AM, Alexander Solovets
> <aso...@gm...> wrote:
> 
> 
> 		Jan, I don't know how Nikolay does it, but I simply
> download and
> 		apply the diff, and then run `git svn dcommit`. I know that
> you can
> 		also accept the pull request into a custom branch (i.e.
> non-master).
> 		In this case you can do it via GitHub's UI, and then rebase
> that
> 		branch on top of master and push changes.
> 
> 		Kirill, by "branching hell" I meant non-linear history with
> a lot of
> 		"merge" points. You not only loose the linearity, but also
> the merge
> 		conflict resolution becomes way more complex, the chance to
> 		accidentally drop someone else's changes increases. I do
> know about
> 		variety of git workflows and different techniques of
> accepting new
> 		commits, and I'm not going to argue, I just wanted to share
> my
> 		experience.
> 
> 
> 		On Tue, Apr 7, 2015 at 1:47 AM, Kirill Katsnelson
> 		<kir...@sm...> wrote:
> 		>> -----Original Message-----
> 		>> From: Daniel Povey [mailto:dp...@gm...]
> 		>> 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.
> 		>
> 		> Let me set up a pair of cloned demo repositories to show
> different practices, as time permits. Give me a day or two.
> 		>
> 		>  -kkm
> 		>
> -----------------------------------------------------------------------
> -
> ------
> 		> 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
> 
> 
> 
> 
> 		--
> 		Sincerely, Alexander
> 
> 
> 
> -----------------------------------------------------------------------
> -
> ------
> 		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
> 
> 
> 
> 
> 
> -----------------------------------------------------------------------
> -
> ------
> 	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
> 
> 
> 
> 
> 
> 
> --
> 
> Ondřej Plátek, +420 737 758 650, skype:ondrejplatek,
> ond...@gm...