On Tue, 14 Nov 2006, Jakub Narebski wrote: > Nicolas Pitre wrote: > > On Tue, 14 Nov 2006, Jakub Narebski wrote: > > >> We can always have --merge arguments to git-pull, and --fetch argument to > >> git-merge. > > > > That would be a complete abomination if you want my opinion. > > > > Please let git-pull actually pull stuff from a remote place, and > > git-merge actually merge stuff only. Let's keep simple concepts mapped > > to simple commands please. Nothing prevents _you_ from scripting more > > involved operations with a single command of your liking afterwards. > > Do we want to abandon completely "single-branch" workflow, where you > don't use tracking branch, only merge directly into your working branch? I really think we should. Let's admit it: such a work flow has nothing to do with the tool. It would certainly be much easier to teach new users about "this is a read-only view of the remote content that you can merge into your working branch" than trying to explain why the tool is so weird for the sake of supporting different work flows directly. Again I think it is easier to grasp two simple commands than a single but complex one with multiple ramifications. > That is the cause to (unused by most) future git-merge (replacement for > git-pull .) --fetch=<remote>[#<branch>] option. > > I'm not that sure about --merge option, but it could be useful, at least > to have current automatic "Merge branch '<branch>' of <URL>" commit message. A "remote" branch should obviously have a corresponding URL. So if you do "git-merge remote" then you may as well prepare a commit message with that URL given the local name for that branch if you want. Nicolas - 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