On Mon, 22 Oct 2007, 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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
