On Mon, 22 Oct 2007, Johannes Schindelin wrote:

quoted text
> 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.  What you describe suggests that you should 
> not use the branch name "master" at all, but "origin/master".

If you push your changes to the origin soon after making them, you'll only 
have local changes if somebody else changed something while you were 
working on a change. You're expected to create local changes in the local 
branches, but you shouldn't generally sit on them forever, and when you've 
pushed them, you no longer have any difference in content between local 
and remote.

If the project has multiple branches in the central repository, and you 
make changes for each of them at different times, but only one each day, 
the normal case will be to have local changes sitting in at most one of 
the branches, and, in particular, no local changes left in any branch 
other than HEAD.

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html