From: Junio C Hamano <junkio@cox.net> To: git@vger.kernel.org Cc: Christian Couder <chriscool@tuxfamily.org> Subject: Automated bisect success story Date: Sat, 21 Apr 2007 13:36:06 -0700 Message-ID: <7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net> (raw) In-Reply-To: <7v7is6wjx6.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Fri, 20 Apr 2007 19:17:09 -0700") Learning from example by Steven Grimm, let me share a success story. Earlier I noticed that "fsck --full" from 'master' took forever in linux-2.6 repository, but the one from 'maint' finished in 2 to 3 minutes. We recently had a few enhancements by Christian Couder to git-bisect, and this was a perfect opportunity to see how well they worked: (1) "git bisect start" now takes one bad and then one or more good commits, before suggesting the first revision to try. Traditionally, immediately after you gave a bad and a good commit, it did a single bisection and then a checkout. This avoids repeated bisect computation and checkout when you know more than one good revisions before starting to bisect, and also let you bootstrap with a single command (you could instead give one good commit at a time and then finally a single bad commit to avoid the waste). Not only I know 'maint' is good, I also know that the tips of "foreign projects" merged to git.git, that do not share any codepath the fsck takes, are irrelevant to the problem. So I want to mark tips of commit ancestry I merged from git-gui projects as good. Hence: $ git bisect start master maint remotes/git-gui/master Mnemonic. Start takes a Bad before Goods, because B comes before G. (2) "git bisect run <script>" takes a script to judge the goodness of the given revision. Because I know each round of test takes around 3 minutes, I wrote a little script to automate the process and gave it to "git bisect run": $ git bisect run ./+run-script This ran for a while (I do not know how long it took -- I was away from the machine and doing other things) and came back with the "object decoration" one Linus has fixed yesterday with his patch. Here is the "+run-script". I have git.git repository and linux-2.6 repository next to each other. -- >8 -- #!/bin/sh # Build errors are not what I am interested in. make git-fsck && cd ../linux-2.6 || exit 255 # We are checking if it stops in a reasonable amount of time, so # let it run in the background... ../git.git/git-fsck --full >:log 2>&1 & # ... and grab its process ID. fsck=$! # ... and then wait for sufficiently long. sleep 240 # ... and then see if the process is still there. if kill -0 $fsck then # It is still running -- that is bad. # Three-kill is just a ritual and has no real meaning. # It is like "sync;sync;sync;reboot". kill $fsck; sleep 1; kill $fsck; sleep 1; kill $fsck; exit 1 else # It has already finished (the $fsck process was no more), # and we are happy. exit 0 fi
prev parent reply other threads:[~2007-04-21 20:36 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-04-21 0:30 [RFH] WTF did we change in git-fsck recently? Junio C Hamano 2007-04-21 1:24 ` Linus Torvalds 2007-04-21 1:30 ` Linus Torvalds 2007-04-21 2:17 ` Junio C Hamano 2007-04-21 20:36 ` Junio C Hamano [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net \ --to=junkio@cox.net \ --cc=chriscool@tuxfamily.org \ --cc=git@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
git@vger.kernel.org list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git