Shawn Pearce wrote: > Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> Junio C Hamano wrote: >> >>> I am not sure if 'merge in corresponding branch' is the only >>> valid workflow, however. I am reluctant to make the system >>> automatically do so if the solution makes other workflows more >>> painful to follow. Automatically merging remotes/origin/$foo >>> when on $foo branch is not good enough, in other words (also, >>> there may be a hierarchy under remotes/ other than origin). It >>> might make sense to introduce "Merge: " in remotes/ file and if >>> they are present use "Pull: " only to decide what are fetched >>> and use "Merge: " to decide what is merged (if we were doing the >>> system from scratch, the former would have been named "Fetch: " >>> but it is too late now). >> >> If you add "Merge: " in remotes/, then please add it also in >> remote section in config file. Config file has now >> branch.<branchname>.merge (and it would be nice if clone would >> set ou this for local branches corresponding to remote branches), >> but it is not the same. > > I'm against adding anything to the remotes/ file format. > > We already have branch.<name>.merge to indicate what the default > source for a git-pull on the branch named <name> should be. > git-branch probably should fill that entry in when a branch is > created from a remotes ref. As I said, branch.<name>.merge is about something else: it just means that if we are on <name> branch "git pull" will merge branch.<name>.merge branch into it. I think the "Merge: " or remote.<repo>.merge is about changing current implicit rule: first branch is to be merged with current branch (if not specified otherwise) when pull-ing, into explicit rule: branch marked as "Merge: " is to be merged with current branch (unless specified otherwise). Correct me if I'm wrong, Junio. -- Jakub Narebski Poland - 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