Menu
▾
▴
Re: [Kaldi-developers] Git upstream
|
From: Kirill K. <kir...@sm...> - 2015-07-24 02:43:04
|
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 > > > > > |