Menu
▾
▴
Re: [Kaldi-developers] Git upstream
|
From: Alexander S. <aso...@gm...> - 2015-07-24 05:15:11
|
How's about `git pull --rebase`? Will be able to keep the history linear as before. On Fri, Jul 24, 2015 at 3:42 AM, Kirill Katsnelson < kir...@sm...> wrote: > Dan, I am suspecting a bit of misunderstanding here. I am not sure I am > reading your intention here: > > $ git diff master remotes/upstream/master > > This compares the tip of your master branch with the tip of the remote > branch. Generally, this comparison does not make much sense. You'll see > your additions as '-', and master additions as a '+'. Then, you are not > probably doing work on master anyway. > > Let's begin from the beginning. When you go 'git clone', you do not "check > out;" rather you create *another repository* with its own set of branches. > Git is distributed, and there is not a server-sandbox relationship; rather, > the two are just two repos (with a lot of common history, of course), but > none of these is "more important." > > *Important note 1*: Many people ask how do they keep their GitHub clone's > master branch in synch with the "golden" master branch. The answer is: > please do not. There is no point in spending your time on keeping two > identical branches in sync! > > *Important note 2*: You do not need to involve your personal fork in > development at all until you are ready to send a PR. > > So how you do the work, generally? > > You already have a repo with 2 remotes. This is what you need. > > origin = gi...@gi...:/danpovey/kaldi.git > upstream = gi...@gi...:/kaldi-asr/kaldi.git > > Next, you want to design a feature. Just branch off the upstream/master, > because this is where the most up-to-date code is: > > $ git fetch upstream > $ git co upstream/master -b my-feature > > The 'git fetch' will fetch all commits that are not yet there in your > local repo. The ref 'upstream/master' will point to the tip of the master > branch. > > Work on your branch. Do commits on it once in a while. Maybe you even > fetch the upstream again, so that upstream/master and my-feature diverge. > This is ok. > > Now, we are back at diffing. The question "what is the difference between > contents at points in history A and B" is not the best one, because the > point B is often not well known. Subversion thinking goes like this: first > you rebase your changes in sandbox on the trunk, then you do 'svn diff' > which shows your changes only. If you are nimble enough, this is what you > commit, if not, do the update again. In Git, the question is stated > differently: "If I merge all changes from the branch F into branch M, what > is the summary patch that I'll apply to M?" The answer is not identical, of > course, assuming M has likely changed. But it is the most informative > really. > > The way to see that diff is > > $ git diff upstream/master...my-feature > > (or simply "git diff upstream/master..." assuming you are on the > my-feature branch) > > NB: This does not take the *current* state of upstream/master into > account. The golden/master is only used to find the closest common history > point, and the summary diff is given as the sum of commits from that point > on your branch. > > For example, try > > $ git diff upstream/master...upstream/nnet3 > > This is the summary patch that "would be applied" (quotes because it does > not work that way, this is only a way to think about it) to upstream/master > if you merge upstream/nnet3 into it. > > But if you do (your initial idea) > > $ git diff upstream/master upstream/nnet3 > $ git diff upstream/nnet3 upstream/master > > you'll see a *symmetrical* difference: the two diffs will just change > signs. They are generally meaningless. > > Notice something cool? You do not use the master branch in your own repo! > No point, really. > > Now, suppose you want to merge your work with a PR. This is how I do it: > > $ git fetch upstream > $ git upstream/master -b testmerge --no-track > $ git merge my-feature > > (--no-track is optional, as you'll kill the branch soon, but helps keep > your config data tidy). > > At this point, you can run tests to make sure everything is ok. You can > then push your feature branch to create a PR. > > $ git checkout my-feature > $ git push origin HEAD > > This will create the branch in your own GitHub's repo, and you'll send the > PR as the difference between kaldi-asr/kaldi:master and > danpovey/kaldi:my-feature > > And I'll write a short doc on that tonight. I feel how painful the > transition is. I'll put a draft on GitHub, and with somebodys help > doxygenate it later. > > -kkm > > > > -----Original Message----- > > From: Daniel Povey [mailto:dp...@gm...] > > Sent: 2015-07-23 1636 > > To: Jan Trmal > > Cc: kal...@li... > > Subject: Re: [Kaldi-developers] Git upstream > > > > (keeping this discussion on kaldi-developers as I'm sure not everyone > > is a git expert and some might benefit), After doing that, how do I > > compare my current branch from the upstream to see how it differs? > > I tried doing things like > > git diff master remotes/upstream/master > > > > git checkout master; git diff upstream/master and even trying to > > create a branch reflecting upstream, by things like > > > > git branch remotes/upstream/master upstream-master > > > > but none of this worked. I guess there's something I'm missing. > > The state of my setup is as given below. > > Dan > > > > > > > > > > mac:kaldi-git: git branch -a > > * master > > remotes/origin/HEAD -> origin/master > > remotes/origin/master > > mac:kaldi-git: git remote -vv > > origin gi...@gi...:/danpovey/kaldi.git (fetch) origin > > gi...@gi...:/danpovey/kaldi.git (push) > > upstream gi...@gi...:/kaldi-asr/kaldi.git (fetch) > > upstream NOT-ALLOWED (push) > > mac:kaldi-git: > > > > > > On Thu, Jul 23, 2015 at 4:27 PM, Jan Trmal <jt...@gm...> wrote: > > > > > > There is github doc that does the same (using fetch and merge) > > https://help.github.com/articles/syncing-a-fork/ > > y. > > > > > > On Thu, Jul 23, 2015 at 7:24 PM, Jan Trmal <jt...@gm...> > > wrote: > > > > > > I usually do > > git checkout master # just to be sure I'm on master > > git pull upstream master # that will do fetch & merge > > > > # you can do also git pull --all which should give you also > > all branches, but that I dont use. > > > > y. > > > > On Thu, Jul 23, 2015 at 7:13 PM, Daniel Povey > > <dp...@gm...> wrote: > > > > > > I'm sure someone on this list will be able to > answer > > this easily, > > Suppose I have my own clone of > > kaldi-asr/kaldi.git at Sourceforge, as danielpovey/kaldi.git, and have > > checked it out using > > git clone > > gi...@gi...:/danielpovey/kaldi.git > > Suppose I then set the official kaldi-asr as the > > upstream, by doing > > git remote add upstream > > gi...@gi...:/kaldi-asr/kaldi.git > > > > so that > > git remote -vv > > shows me > > git remote -vv > > origin gi...@gi...:/danpovey/kaldi.git > > (fetch) > > origin gi...@gi...:/danpovey/kaldi.git > > (push) > > upstream > > gi...@gi...:/kaldi-asr/kaldi.git (fetch) > > upstream > > gi...@gi...:/kaldi-asr/kaldi.git (push) > > > > Then how do I merge changes from the upstream? > > > > We should have instructions on this somewhere. > > Dan > > > > > > > > > > ----------------------------------------------------------------------- > > - > > ------ > > > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > > > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > -- Sincerely, Alexander |