Petr Baudis <pasky@xxxxxxx> writes: > On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote: >> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves? > > It is dangerous to introduce new options just because we think someone, > sometimes might find it useful, especially if they potentially encourage > a bad workflow. Adding options and commands is expensive since it > complicates the UI further, thus we should add further only when we have > good reason for it. > >> > That also was the reason I did not add any documentation to it. > > I was actually looking for something like this based on some question on > #git (about git pull -s theirs possibility), and did stumble upon these > patches, but quickly gave up on them since it wasn't immediately clear > for me from the patch description exactly how the workflow looks like > (it doesn't really seem to work like the opposite of -s ours nor is it a > separate strategy... huh) and the options were completely undocumented. Heh, now you have some readings to do ;-) I tried not to sound too negative when describing -Xours and -Xtheirs there, but actually I think "-s theirs" is even worse. It is how you would discard what you did (perhaps because the other side has much better solution than your hack), but that can be much more easily and cleanly done with: $ git reset --hard origin Some poeple might say "But with 'merge -s theirs', I can keep what I did, too". That reset is simply discarding what I did. That logic also is flawed. You can instead: $ git branch i-was-stupid $ git reset --hard origin if you really want to keep record of your failure. One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you _cannot_ offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all. -- 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