On Tue, Jul 29, 2008 at 01:05:11PM +0200, Johannes Schindelin wrote: > > 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. Of course; I even mentioned the same in another part of the thread. But that isn't a difference between "ours" and "theirs"; any time you are discarding some changes, you should mention why. > > 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? Sure, which means we must _read_ from master. But you are _changing_ master. Whereas I view this as an operation on the production branch. Please don't misunderstand me. I am not saying your way of thinking about it is wrong (or even less right than mine). What I have been trying to say this whole thread is that it is reasonable for a user to model the goal as I have described, and that git can easily support the direct implementation of achieving that goal (which is what Sverre asked originally -- is this useful to people?). > > Not to mention that we might not _control_ master. > > This is Git. We control all local branches. Sort of. Consider the kernel example I gave. A "linus" branch represents "this is where Linus is." But that _isn't_ where Linus is if you have added an extra merge commit to it. So either we throw away the change made to the "linus" branch, or we forever have extra merges that Linus does not have. So yes, obviously you can do whatever you like with your local branches. But you complained in my example that the "production" branch was unnecessarily being treated as "dominant". My example was meant to indicate that the "thrown away" branch is dominant for a reason (in this case, it is my work branch, while the other is a tracking branch). > 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. I don't see the point in talking about "usually". In the scenario in which I used it, the merge _didn't_ succeed trivially. Of course, usually you would not use "-s theirs". But the question was "is this ever useful?" and my answer was "rarely, but here is an example of when I wanted it." If you are using "-s theirs" frequently, you are probably doing something wrong. But that doesn't mean it is wrong for it to exist. -Peff -- 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
