Re: [PATCH] Only warn about missing branch.<n>.merge in pull.

[Shawn Pearce <spearce@spearce.org>]

"Michael S. Tsirkin" <mst@mellanox.co.il> wrote:
> > Quoting r. Junio C Hamano <junkio@cox.net>:
> > I can see a few possibilities:
> > 
> >  (1) people do not interact with multiple remote repositories
> >      regularly, so this is not a problem in practice.
> > 
> >  (2) people do, but "the first branch listed" rule is good
> >      enough in practice.  Because they would always say "git
> >      pull second which-branch" instead if they want something
> >      different, this is a non-issue.
> > 
> >  (3) branch.$current.merge was a mistake.  It should have been
> >      branch.$current.merge.$remote.  In other words, the
> >      configuration should have been about the current branch and
> >      the remote repository pair.
> > 
> >  (4) the current configuration mechanism is fine, but the code
> >      is not.  We should forbid "the first branch listed" rule
> >      from being applied for "git pull second", and require the
> >      users to explicitly say which branch(es) to merge.
> > 
> > I am inclined to say that (1) is possible, (2) is implausible
> > (otherwise we would not have done 62b339a5 for the same reason),
> > (3) is confused, and probably (4) is what we need.
> 
> As a person who tracks multiple remotes in one repository,
> I would say (4) best matches what I do.
> 
> So I currently always do git fetch <remote> to download changes,
> and always use git pull . <branch> to merge a specific branch.

Agreed; #4 best matches what I (and those I work with on that ugly
repository of mine) do.

My git.git repository currently just fetches all of Junio's branches
right into my local refs/heads.  I fetch every day or so, but never
merge from next into any branch.  Though I create branches off next,
master, or some select commit based on whatever topic I'm hacking.

In my other repositories I tend to fetch before merging, for a
number of reasons:

 a) Its distributed backup; if I fetch the branch that's one more copy.

 b) I can easily view a branch's recent changes, but not affect my
    own topics until I'm ready to take them in.  People often ask
	me to look at their changes, or wonder why something is suddenly
	acting odd - looking at the commits in gitk usually tells me
	quite quickly who did what.  :-)

 c) I can easily start a new topic off any recent change.

 d) I can easily merge topics once they are local and reviewed.

a,b,d are not quite as necessary in an email-patch based group such
as git itself, as the mailing list offers most of the reasons I
fetch first.  b and c are just convience there.

--