Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

Johannes Schindelin wrote:

diff qgit commit fetch rebase merge status push cherry-pick grep bisect add show-ref

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.

This would save me from this command sequence, which I currently have to do for git.

git fetch git checkout next git merge spearce/next git checkout master git merge spearce/master git checkout maint git merge spearce/maint git checkout pu git reset --hard spearce/pu

<rinse and repeat for every tracked branch>

git could definitely help here. I want the local branches to be up-to-date with the remote ones, because I frequently run diffs against the various branches to see if anything that I should be aware of has changed, and just as frequently I forget to add that 'origin/' prefix, which means I *might* be looking at old code.

I usually do that on internal projects, where we have "master", "next", "testing", and "stable" branches for pretty much every repo. We have 54 git repos. The typing adds up. This is also one of the most frequent causes of confusion for my (even) less git-savvy co-workers. The argument usually goes like this: "Umm... Peter, why did you commit your fix on top of 7 weeks old code?" "Oh? I did git-pull first, just as you said, so it should have been the latest, shouldn't it?" "Well, what branch were you on when you pulled?" "Err.. does that matter? I didn't have any local modifications on the branch when I pulled, so it should have just updated it."

What's happened prior to such an argument is usually this: next or master is inevitably checked out. The user does git-pull to get up to date. They then change branch and get down to business with rebasing, merging and editing. When it's time to push, git tells them "not a strict subset. use git-pull!", and they do, and sometimes it fails, and I have a hard time explaining why since I really don't see a reason for *not* updating all "to-merge" branches when they point to the same commit as their tracking-branch before the pull.

Patch to follow (at some point), although it's likely to make git-pull a built-in since I have no idea how to maintain coupled lists in shell.