Hallo Johannes, Johannes Schindelin schrieb am Tue 25. Mar, 21:04 (+0100): > On Tue, 25 Mar 2008, Jörg Sommer wrote: > > Junio C Hamano schrieb am Mon 24. Mar, 09:45 (-0700): > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > > On Sun, 23 Mar 2008, Junio C Hamano wrote: > > > > > > > >> I unfortunately do not recall why _prepend_, and not _replace_, had > > > >> to be the right behaviour. > > > > > > > > http://article.gmane.org/gmane.comp.version-control.git/31896/match=git+merge+make+usable > > > > > > So it was "my suspicion that people who would want to pass -m would > > > want it to behave this way". > > > > > > I do not care deeply either way myself, as I never have found use for > > > -m to the merge command, but I think it could have been argued either > > > way. > > > > I would like to argue for the replace way. :) Take git rebase -p as an > > example. If a merge is included in the rebase, it's redone with git > > merge -m. Because git rebase works with detached heads you get merge > > messages like this: [...] > > That only means that the original author of rebase -p was a lazy bastard > and did not use the proper way to call git-merge, namely > > git <msg> HEAD <the-other-branch> It this really a proper way to call git merge? The manpage says: The second syntax (<msg> HEAD <remote>) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as git merge -m <msg> <remote>. And how would you pass the option for the strategy to this form? Git rebase calls git merge with -s. Bye, Jörg. -- But in the case of "git revert", it should be an ancestor (or the user is just insane, in which case it doesn't matter - insane people can do insane things) Linus Torvalds <alpine.LFD.1.00.0801041031590.2811@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
