On Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:
On 10/22/07, Andreas Ericsson <ae@xxxxxx> 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. Git knows when I haven't got any changes on my local
branches, and it can be fairly safely assumed that when I feel like
making any, I'd like to make them off as fresh a tip as possible
unless
I explicitly tell git otherwise.
[cut]
It would be I think possible to make git behave as you want,
although I'd rather
(at least at first) have behaviour described above turned on by
some option
or config variable. I guess that it would be not that hard to make
script to do
what you ant (and probably it would be best if you tried your idea
that way).
There are the following caveats.
1. For each local branch that is to be updated on pull, this branch
must be marked as tracking some branch of some repository. This has to
be explicitely done; for example by creating those branches using
--track option.
True, and only the branches matching the remote currently pulled
should be considered. Tracking branches pointing to a different
remote need to be skipped.
2. Git can do a merge with conflicts _only_ if that branch is checked
out.
Andreas' proposal contains an important requirement that
avoids this problem. His proposal states "when they, prior
to fetching, pointed to the same commit [the head in remotes
pointed to]". That is only fast-forwards are needed, which
never have merge conflicts.
So for all local branches which you want to get updated using
"git pull --update-all <repo>" (or something like that), the merge
with remote branch should be either fast-forward, trivial merge, or
merge without conflicts. "git pull --update-all <repo>" would return
then list of updated branches and list of branches which cannot be
updated.
Maybe Andreas' proposal could be extended as you describe.
But I don't think any merging should automatically be done. I'd
only support fast forwards. Merging always includes a risk
of unexpected changes to the code; even if there are no merge
conflicts detected by git. I think it is reasonable to leave
all such cases to the user for manual resolution. Supporting
fast-forward should be sufficient.
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
