"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> Commit 62b339a5 added a warning for git-pull to notify the user when
> they have not configured the setting 'branch.<n>.merge' (where <n>
> is the current branch) and no arguments were given to git-pull to
> specify the branches to merge.
Let's step back a bit. I have a question that affects the
design level.
To people who interact with more than one remote repositories
regularly, how would you normally work, and how well does the
current configuration mechanism help you? I am not interested
in somebody who cut & paste full URL and branch name from pull
request e-mail, but those who interact with the same remotes
regularly and have entries in $GIT_DIR/remotes/ for them (or
their moral equivalent remote.* configuration).
You can have one "default remote" per branch (and it being the
default, one is the only number that can make sense), and you
can say:
$ git pull
without saying anything about which remote, and it does "git
pull origin" or whatever the default remote is. That's a good
thing.
Also, the change by 62b339a5 makes it an error not to have the
corresponding branch.$current.merge, if the above syntax that
does not say any remote nor branches is used. That's also a
good thing.
But if you regularly interact with two remote repositories, and
the second one (which by definition cannot be the default for
the current branch) has $GIT_DIR/remotes/second (again, or its
moral equivalent, remote.second.* configuration), then wouldn't
you expect that when you say:
$ git pull second
some mechanism protects you from merging "the first remote
branch listed in $GIT_DIR/remotes/" the same way?
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.
-
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