On 10/04/2008, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm interested in hacking on a project that uses git and although I > have used cvs, sccs, GNU arch, bzr, svn, perforce, darcs and others, > git seems to have gotten the better of me. > > What I would like to do is the following: > > a) Pull the upstreams sources (this I can already do).
git clone <upstream-repo> > > b) Create branch of the upstream sources for my own hacking (I > think this is "git clone upstream hacking"). git branch my-hacking-branch This will create a branch from the tip of the master branch, which it the branch you will be on immediately after a clone. You then run git checkout my-hacking-branch Note: you don't need to create a separate branch to do you hacking on. Your master branch will be setup to track remotes/origin/master (the master branch of the repo you cloned from). You can make your commits on your local master just fine. to switch to that branch, make you changes and commit them. > > c) Hack on my hacking branch and commit stuff as I see fit. You can use you local master, as mentioned above. > > d) Routinely update my upstream source branch (this I can do with > "git fetch ; git rebase origin" but I'm not entirely sure what > these commands do). You'll notice that if you run the command git branch -r you will see a list of the remote branch references that are store in you local repo. These references store where the remote repo was up to since you last fetched or pulled. When you have made you changes on your master branch and committed them, run git fetch -v (the -v is verbose, I use it to be convinced that fetch actually did anyting, as it doesn't usually print anything to the console unless something went wrong) That command will update the remote/origin/master etc in you local repo by downloading all of the commits that you don't have that have been committed in the remote repo since you last pulled/fetched. It won't change your local master branch or perform a merge in any way. Which is a good thing, as we'll see, as it allows you to rebase you commits on top of the tip of the remote repos master branch. > > e) Merge from the updated upstream into my hacking branch. rather than a merge, just run git rebase origin/master That will rewrite your commits in terms of the tip of the remote master branch, which makes a linear history, instead of a merge commit with two lines of ancestory. After the rebase, you local master branch will be up to date with the remote master branch, and you commits will be on top. You can have a look with gitk. > > f) Generate diffs between the upstream branch to my hacking branch > to send upstream. > I am in unfamiliar territory here, as at work we use the Git daemon protocol which allows us to send commits directly to the remote repo without having to generate patches. But I think what you need is something like this: git diff -p master origin/master That will generate a patch on STDOUT that will contain the differences between you repo and the remote repo. > It would be much appreciated if someone could clue me in on this > stuff. For instance, I'm not sure the above is even the right way > to work with git. I have found dozens of supposed explanations and > howtos on the net and none of then are anywhere near a complete > picture. many of them are not even helpful. There is no 'right' way to work in git. It's designed to be workflow agnostic. For the project you are involved with, it's best to ask one of the existing developers what workflow they use and get them to describe it. > > Cheers, > Erik > > -- > ----------------------------------------------------------------- > Erik de Castro Lopo > ----------------------------------------------------------------- > "Islam wishes to destroy all states and governments anywhere on the face > of the Earth which are opposed to the ideology and program of Islam, > regardless of the country or the nation which rules it." > -- Syed Abul Ala Maududi, founder of Pakistan's Jamaat-e-Islami, April 1939 > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
