Hi, On Tue, 29 Jul 2008, Jeff King wrote: > On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote: > > > > So the logical sequence was: > > > > > > git checkout production > > > git merge -s theirs master > > > > To me, this suggests that they were too married to 'production' being > > the "dominant" branch. > > Perhaps. But I see this as an operation on the production branch: "pull > in master's changes, forgetting ours". First of all, I cannot say how wrong it is to forget any changes in a production branch without proper explanation. I.e. without a commit message explaining _why_ the change was wrong to begin with. It is messy at best, and I am happy that Git does not make that easy. > In your workflow (git checkout master && git merge -s ours production && > git push origin master:production) we perform an operation on master, > which doesn't seem as intuitive to me. But why? Isn't the _content_ of "master" what we want? > Not to mention that we might not _control_ master. This is Git. We control all local branches. > What about (and I think Sverre mentioned something like this > previously): > > I forked the kernel and made some changes. Some of my changes got > applied upstream. The others are now obsolete. Now I want to bring > myself in sync with Linus, but I want to keep my history (either > because the history is interesting to me, or because others are basing > their work on it). > > Then your workflow, while still possible within the local repository, > means you are munging the "linus" branch, which seems wrong. That branch > is probably even just a tracking branch, which you would not want to > build on, anyway. No, this workflow almost _dictates_ a plain "pull" into your local branch. The fact that a few commits were applied to upstream usually only means that your merge succeeds trivially, since the merged branches contain the _same_ changes. Ciao, Dscho -- 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
