Johannes Schindelin wrote:
quoted text
> So once again, what operations involving git do people use regularly?
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html