On Oct 22, 2007, at 5:16 PM, Andreas Ericsson wrote:
Johannes Schindelin wrote:
Hi,
On Mon, 22 Oct 2007, Andreas Ericsson wrote:
Johannes Schindelin wrote:
On Mon, 22 Oct 2007, Andreas Ericsson wrote:
If I were to suggest any improvements, it'd be to change the
semantics of git-pull to always update the local branches set
up to be merged with the remote tracking branches when they,
prior to fetching, pointed to the same commit, such that when
$ git show-ref master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/
master
refs/heads/master gets set to refs/remotes/origin/master post-
fetch.
In general, this should fail. Because you are expected to have
local changes in the local branches.
BS argument.
Aha. So you want to make sure that the local branches are no
longer "purely" local. And you want to stop updating them when
unpushed changes are in the local branches.
To me, it's more along the lines of "let git help me not make the
mistake of hacking on a six-week old codebase when I've explicitly
asked it to merge these and those remote tracking branches into
these and those local branches". Not updating those branches when
there *are* changes on them is something users can understand and
will probably also appreciate, but the reason for not allowing even
fast-forwards escape me.
Here's also an interesting asymmetry. By default, git push
updates all remote branches matching a local branch. But git
pull "updates" only the current local branch to the state of
the remote head (by updating all local copies of the remote
branches, but merging only a single of these heads).
Maybe this asymmetry adds to the confusion. I see arguments
for both behaviours:
1) In both cases, update only the branch you're on
or
2) in both cases update all matching branches.
(btw, if I do not intend to merge at all, you can always use
"git fetch".)
Steffen
-
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
