On Mon, 10 Mar 2008 14:37:43 +0200 Peter Gordon <peter@xxxxxxxxxxxxxxxxxx> wrote: > Hi. > > There are a number of us working on a project. We each have a HEAD, > and work on branches, using git-checkout -b MyPatch. When we have > finished working on the branch, we move back to the HEAD, with > git-checkout master, do a > git-pull > and then git-cherry-pick sha1..... > > I have two questions. > > 1) Is this the normal way to work with git. Since you always work on your own 'branch', you have no need to check out a new branch to be independent of others. If you 'do' work on your own branch, the easier way would be to do one of the following: a) git pull b) Separate branches for separation.. git checkout master git pull -- may cause a merge git merge <your branch> -- if you worked on your own branch..git pull c) Get the latest changes and linearize history git fetch git rebase origin/master a - Easiest and more sane If you want to work on your own branches you can always work on that branch and pull updates from the master b - Might keep workflow simpler and follows your workflow without cherry-picks c - Might be good if you create a simple patch and don't care about the history and haven't published the branch > > 2) Also, we sometimes get a log of > Merge branch 'master' of git://sgit/MyProject which has no commits. > Why does this happen? git pull performs explicit merges if your repository is not at the exact same point as another. Depending on what has happened, there might be no code changes, but the history is different (perhaps out-of-order 'cherry-picks') -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
