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 do quite often so I'm working near the bleeding edge), but it doesn't seem all that useful in the "short" log output[1] If "Auto merge" isn't a good string to match for the purposes of trimming, then I can make my scripts use something else. -Tony [1] unless I can persuade Intel to base my bonus on the number of commits I get included into the base :-) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 don't spend much time on the linus branch (just to build an updated cscope database, etc.). I never want to check anything in on that branch [sometime I should figure out how use the "hooks" to keep me from shooting myself in the foot here]. >In the meantime, warning the user about the issue and suggesting >how to do the fast-forwarding of the working tree himself in the >warning message might be the safest and the most sensible thing >to do. Yes please ... a big fat warning with coloured flashing lights and explosions from the sound card. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: cache status after git pull
>To set up "linus" short-hand to be updated with "master" branch >head from Linus, you would do one of the following: > > * Using new style shorthand > >$ cat >$GIT_DIR/remotes/linus \ >URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ >Pull: master:linus >$ git fetch linus This sounds like it does what I want ... so I'd like to confirm before wiring this into my scripts and fingers. What I want is to get the latest from kernel.org...linus...master and update my .refs/heads/linus with the new SHA1. I'd like to be able to do that without touching what is in my index, and without changing the state of any checked out files. If that is what the above does, then you are my hero for today :-) -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 time [unless you count merging the incorrect patch in the first place, and then having to revert it :-) ]. Could GIT be smarter here? Perhaps it could pick a few likely ancestors and run the merge with each ... and then give some warnings if there are files that come out differently? -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
>Yup. Think of it as a good exercise in git ;) Fixed now (I hope). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
>Now, I suspect you didn't mean to commit that thing: it really looks like >you've mixed up your patches somehow, because the commit message seems to >match only a very small portion of the patch. > >Did you perhaps have a failed merge or something that was in your index >when you applied that patch? If you have a dirty index when you do >"git-applymbox", it the commit done as part of the applymbox might commit >other state too. Yes I had a failed merge ... I thought that I had cleaned up from it, but clearly I hadn't. Bother. I guess I have a bit of tree maintenance to do ... But I think that it should be easy ... I can just step "test" back to before I merged in the Alex patch. Redo the Alex patch properly. Then re-merge all the branches that happened after this. Followed by crossing my fingers and running "git prune". Maybe I'll try all that in a *copy" of my GIT tree first! -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 another one of my status scripts that does $ git-whatchanged -p test ^linus | diffstat -p1 and was surprised when it reported changes in 10 files that I knew I hadn't touched (the other 18 files it reported looked correct). So I ran: $ git-whatchanged test ^linus | git-shortlog and this just reported the changesets that I expected. $ git-diff-tree -p linus test | diffstat -p1 shows what I expect to see. The current heads of the two branches are: linus=30d5b64b63fa69af31b2cba32e6d71d68526eec9 test=0e595ad82db1b42d631e581630eb3fbeebb3c285 my tree is at: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git The spurious changes reported by "git-whatchanged -p" are: > Documentation/acpi-hotkey.txt |3 > Documentation/kernel-parameters.txt|5 > drivers/acpi/osl.c |6 > fs/jfs/inode.c |4 > fs/jfs/jfs_logmgr.c| 36 - > fs/jfs/jfs_logmgr.h|2 > fs/jfs/jfs_txnmgr.c| 12 > fs/jfs/super.c |4 > include/asm-i386/processor.h |2 > include/asm-x86_64/processor.h |2 Is this a bug, or am I just confused about how "git-whatchanged" works? -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
b/Documentation/howto/using-topic-branches.txt
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -70,8 +70,8 @@ them too:
Now create the branches in which you are going to work, these start
out at the current tip of the linus branch.
- $ git checkout -b test linus
- $ git checkout -b release linus
+ $ git branch test linus
+ $ git branch release linus
These can be easily kept up to date by merging from the "linus" branch:
@@ -144,6 +144,11 @@ is empty. At this point the branch can
$ rm .git/refs/heads/branchname
+Some changes are so trivial that it is not necessary to create a separate
+branch and then merge into each of the test and release branches. For
+these changes, just apply directly to the "release" branch, and then
+merge that into the "test" branch.
+
To create diffstat and shortlog summaries of changes to include in a "please
pull" request to Linus you can use:
@@ -151,3 +156,109 @@ pull" request to Linus you can use:
and
$ git-whatchanged release ^linus | git-shortlog
+
+Here are some of the scripts that I use to simplify all this even further.
+
+ update script
+# Update a branch in my GIT tree. If the branch to be updated
+# is "linus", then pull from kernel.org. Otherwise merge local
+# linus branch into test|release branch
+
+case "$1" in
+test|release)
+ git checkout $1 && git resolve $1 linus "Auto-update from upstream"
+ ;;
+linus)
+ before=$(cat .git/HEAD)
+ git checkout linus && git pull linus
+ after=$(cat .git/HEAD)
+ if [ $before != $after ]
+ then
+ git-whatchanged $after ^$before | git-shortlog
+ fi
+ ;;
+*)
+ echo "Usage: $0 linus|test|release" 1>&2
+ exit 1
+ ;;
+esac
+
+ merge script
+# Merge a branch into either the test or release branch
+
+pname=$0
+
+usage()
+{
+ echo "Usage: $pname branch test|release" 1>&2
+ exit 1
+}
+
+if [ ! -f .git/refs/heads/"$1" ]
+then
+ echo "Can't see branch <$1>" 1>&2
+ usage
+fi
+
+case "$2" in
+test|release)
+ if [ $(git-rev-list $1 ^$2 | wc -c) -eq 0 ]
+ then
+ echo $1 already merged into $2 1>&2
+ exit 1
+ fi
+ git checkout $2 && git resolve $2 $1 "Pull $1 into $2 branch"
+ ;;
+*)
+ usage
+ ;;
+esac
+
+ status script
+# report on status of my ia64 GIT tree
+
+gb=$(tput setab 2)
+rb=$(tput setab 1)
+restore=$(tput setab 9)
+
+if [ `git-rev-tree release ^test | wc -c` -gt 0 ]
+then
+ echo $rb Warning: commits in release that are not in test $restore
+ git-whatchanged release ^test
+fi
+
+for branch in `ls .git/refs/heads`
+do
+ if [ $branch = linus -o $branch = test -o $branch = release ]
+ then
+ continue
+ fi
+
+ echo -n $gb === $branch == $restore " "
+ status=
+ for ref in test release linus
+ do
+ if [ `git-rev-tree $branch ^$ref | wc -c` -gt 0 ]
+ then
+ status=$status${ref:0:1}
+ fi
+ done
+ case $status in
+ trl)
+ echo $rb Need to pull into test $restore
+ ;;
+ rl)
+ echo "In test"
+ ;;
+ l)
+ echo "Waiting for linus"
+ ;;
+ "")
+ echo $rb All done $restore
+ ;;
+ *)
+ echo $rb "<$status>" $restore
+ ;;
+ esac
+ git-whatchanged $branch ^linus | git-shortlog
+done
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
git checkout -f branch doesn't remove extra files
I've just got around to noticing some of the new (to me) features in git, and started experimenting with branches. I see that when I switch view to a different branch with: $ git checkout -f someoldbranch that any files that exist in my previous branch view but not in "someoldbranch" are not deleted. I can find and remove them easily with: $ git-ls-files --others | xargs rm -f but I wondered whether this was a deliberate choice (to avoid clobbering .o files etc. for people who have run a make in their tree). Currently git-ls-files doesn't have a way to specify a branch ... but it it did, the something like: comm -1 <(git-ls-files -b oldbranch) \ <(git-ls-files -b newbranch) | xargs rm -f would clean up the spurious files. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 reloading them across the wire. Something like:
get_commit(sha1)
{
if (sha1 in real_repo) -> done
if (!(sha1 in tmp_repo))
load sha1 to tmp_repo
get_tree(sha1->tree)
for each parent
get_commit(sha1->parent)
move sha1 from tmp_repo to real_repo
}
get_tree(sha1)
{
if (sha1 in real_repo) -> done
if (!(sha1 in tmp_repo))
load sha1 to tmp repo
for_each (sha1->entry) {
case blob: if (!sha1 in real_repo) load to real_repo
case tree: get_tree()
}
move sha1 from tmp_repo to real_repo
}
The "load sha1 to xxx_repo" needs to be smarter than my dumb wget
based script ... it must confirm the sha1 of the object being loaded
before installing (even into the tmp_repo).
-Tony
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 disambiguate certain comments, especially those involving >words or phrases such as "yesterday" or "this afternoon". This is a very good point ... but this still has problems with the "git is a filesystem, not a SCM" mantra. Timezone comments don't belong in the git inode. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
