merge noise in git-shortlog output

Looking at the shortlog information for 2.6.13 there are a lot (eleven) of changes attributed to me that look like: Auto merge with /home/aegl/GIT/linus This is valid (I really did make all those commits, they happen every time I merge the linus branch into my release branch, which I like to

RE: [PATCH] Fix pulling into the same branch.

I am tempted to move this logic to git fetch instead, because it has the same issue. Tony's linus branch example has been updated to do a git fetch instead of git pull from the earlier description in his howto, but if he happens to be on the linus branch, he would still have this same problem. I

RE: baffled again

I think git did the right thing, it just happened to be the thing that Tony didn't want. Which makes it the wrong thing, of course, but from a purely technical standpoint, I don't think there's anything really wrong with the merge. On the plus side ... at least it wasn't a dumb user error this

[PATCH] updates for Documentation/howto/using-topic-branches.txt

Small fix (use git branch to make branches, rather than git checkout -b). Optimization for trivial patches (apply to release and merge to test). Three sample scripts appended. Signed-off-by: Tony Luck [EMAIL PROTECTED] --- diff --git a/Documentation/howto/using-topic-branches.txt

git-whatchanged -p anomoly?

Yesterday I was all happy ... Linus pulled a couple of changes from my tree, and after I did a pull back from his tree into my linus tracking branch, my status scripts correctly identified the branches that I'd been using to track those changes as being no longer needed. But this morning I ran

RE: [3/5] Add http-pull

But if you download 1000 files of the 1010 you need, and then your network goes down, you will need to download those 1000 again when it comes back, because you can't save them unless you have the full history. So you could make the temporary object repository persistant between pulls to avoid

RE: Date handling.

I'd prefer not to lose the information. If someone has committed a change at 2am, I like to know that it was 2am for _them_. It helps me decide where to look first for the cause of problems. :) I'd think the 8:00am-before-the-first-coffee checkins would be the most worrying :-) It also helps