Johannes Schindelin wrote:
Hi,
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.
Nice hint though. I'm working on a patch for it now but I've only looked
at it 15 minutes over lunch today, so it'll probably be a few days.
What you describe suggests that you should
not use the branch name "master" at all, but "origin/master".
No. I want the ability to commit locally without it affecting my
upstream tracking branches, but I also want to make sure that when I
want to work on some branch I don't frequently touch, git will make sure
it's kept up-to-speed with the branch I explicitly have told it to merge
with, without me having to remember if I was on that branch when I last
did git-pull (I might not have a network connection), and without having
to remember what I decided to call my locally-modifiable branch.
That said, there is a pretty simple way to achieve what you want (even if
it does not help the confusion you create between local and remote
branches):
git config --add remote.origin.fetch master:master
Of course, when you checkout "master" and pull then, you'll get even more
problems, _exactly_ because you muddled up the clear distinction between
local and remote branches.
That's not what I want at all. I must have been unclear in my original
post. I'm talking about git doing automatically what every single user
I've ever talked to wants it to do, which is to maintain the state of
sync that the "local-and-modifiable" branches had with the
"local-non-modifiable-aka-remote-tracking" branches. Note that the state
of sync is more important to users than git never ever touching the
branches that they *could* have (but don't have) changes on.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
