* Re: [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
From: Andreas Ericsson @ 2007-10-23 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Johannes Schindelin, git
In-Reply-To: <7v640x7a4n.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sort of offtopic, but is "factorise" a correct verb here? I
> thought "factorise" is to express a non prime number as the
> product of prime numbers.
>
It's the reverse of expanding brackets, like so:
2x² + x - 3 = (2x + 3)(x - 1)
> "refactor" is the act of splitting and merging pieces of
> functions for better reuse, isn't it?
>
Yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-23 22:45 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, msysGit
In-Reply-To: <5AD0C329-7136-42A3-9202-865E70A29B65@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 21, 2007, at 8:47 AM, Steffen Prohaska wrote:
>
> >How can I switch msysgit's git-gui to English, independently of
> >the language selected for Windows? I recognized that git-gui
> >adjusts to the 'language selection' of Windows. How can I
> >disable this? I want git-gui to always display English. Nothing
> >else, never! I can't help people who use a different language
> >in the gui, because I'll not understand what they are talking
> >about and they'll not understand me.
>
> And it's even worse. An error in the localization can completely
> break git-gui. Apparently the German localization included in
> msysgit's Git-1.5.3-preview20071019.exe _is_ broken (see
> attached png).
>
> Shouldn't the localization code be a bit more fault tolerant?
Yes. This is a possible workaround:
>From 410aa617e7ca8240500e90f0b0389bde7b7b40aa Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Tue, 23 Oct 2007 18:44:55 -0400
Subject: [PATCH] git-gui: Protect against bad translation strings
If a translation string uses a format character we don't have an
argument for then it may throw an error when we attempt to format
the translation. In this case switch back to the default format
that comes with the program (aka the English translation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 38c6e59..a7227ac 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -88,13 +88,20 @@ if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
package require msgcat
-proc mc {fmt args} {
- set fmt [::msgcat::mc $fmt]
+proc _mc_trim {fmt} {
set cmk [string first @@ $fmt]
if {$cmk > 0} {
- set fmt [string range $fmt 0 [expr {$cmk - 1}]]
+ return [string range $fmt 0 [expr {$cmk - 1}]]
}
- return [eval [list format $fmt] $args]
+ return $fmt
+}
+
+proc mc {en_fmt args} {
+ set fmt [_mc_trim [::msgcat::mc $en_fmt]]
+ if {[catch {set msg [eval [list format $fmt] $args]} err]} {
+ set msg [eval [list format [_mc_trim $en_fmt]] $args]
+ }
+ return $msg
}
proc strcat {args} {
--
1.5.3.4.1324.ga7925
--
Shawn.
^ permalink raw reply related
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-23 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710231214150.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> Ok, the diff looks fine, but now the "list of files" pane on the right is
> empty.
Really? It looks OK here - that is, it lists the names of the files
whose diffs are shown on the left, i.e. the files modified by the
commit that are within the path limit.
Is it completely empty, or does it have just the "Comments" entry at
the top?
Can you give me an example of a gitk command line that shows the
problem on the kernel tree?
Paul.
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-23 23:44 UTC (permalink / raw)
To: Steven Grimm; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <471E6EF0.2060403@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> Also might be worth mentioning the zsh completion support. (I know it's there,
Steven> but haven't used it -- maybe its author would care to describe it a bit?)
Where is it? I'm a zsh user, and would love to have git support.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: gitk patch collection pull request
From: Linus Torvalds @ 2007-10-23 23:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18206.34254.741787.255299@cargo.ozlabs.ibm.com>
On Wed, 24 Oct 2007, Paul Mackerras wrote:
>
> Is it completely empty, or does it have just the "Comments" entry at
> the top?
Just the comment.
> Can you give me an example of a gitk command line that shows the
> problem on the kernel tree?
Happened for just a random directory I tested. According to my bash
history, it seems to have been
gitk v2.6.23.. drivers/char/
which is pretty basic..
Linus
^ permalink raw reply
* Re: UI and git-completion.sh
From: Matthieu Moy @ 2007-10-23 23:54 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <86ve8x9z1f.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
>
> Steven> Also might be worth mentioning the zsh completion support. (I know it's there,
> Steven> but haven't used it -- maybe its author would care to describe it a bit?)
>
> Where is it? I'm a zsh user, and would love to have git support.
In zsh itself.
Completion/Unix/Command/_git
--
Matthieu
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <vpqir4xgzep.fsf@bauges.imag.fr>
>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Matthieu> In zsh itself.
Matthieu> Completion/Unix/Command/_git
Not in my version of zsh. Any chance I can add that to my 4.2.3 installation?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-24 0:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710231647350.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> Happened for just a random directory I tested. According to my bash
> history, it seems to have been
>
> gitk v2.6.23.. drivers/char/
Ahhhh... It's the slash on the end that does it (it works properly
without the slash). I just pushed out a fix for that (and a couple of
other bugs I just found).
Paul.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Salikh Zakirov @ 2007-10-24 0:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021020653.GA14735@spearce.org>
Shawn O. Pearce wrote:
> Hmm. Lets see.
>
> "cvs foo":
> Big spew of commands. Like "git foo".
>
> "svn foo":
> Unknown command: 'foo'
> Type 'svn help' for usage.
>
> Both are considered to be more newbie friendly then Git. So clearly
> SVN's output of almost nothing is friendly. And so is CVS'
> big spew of frequently used commands. Either way is apparently
> newbie friendly.
>
> Though I find SVN's message a little insulting, asking me to type.
> I know I have to type the command, thanks.
On the contrary, I consider CVS and current Git output more insulting,
as it assumes I forgot all the commands every time I made a typo.
The polite part of the message is to point out a typo,
as "Unknown command 'foo'" above. The "Type "svn help" for usage" part
is just a reminder for complete newbies, which doesn't take too much space
and can be reasonably ignored by experienced users.
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:31 UTC (permalink / raw)
To: Steven Grimm; +Cc: Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <471E91C9.3000004@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> And I think we've just proven that more documentation is required
Steven> here! (I have no idea how to enable it myself; I just know I've seen
Steven> it mentioned on the list from time to time.)
Yes, so what is the process of adding the git zsh completion to any relatively
stable version of zsh? Someone here must know.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH 0/9] Make git-svn fetch ~1.7x faster
From: Sam Vilain @ 2007-10-24 0:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, aroben
In-Reply-To: <20071023060812.GA30978@glandium.org>
Mike Hommey wrote:
> On Mon, Oct 22, 2007 at 10:46:28PM -0700, Adam Roben wrote:
>> This patch series makes git-svn fetch about 1.7x faster by reducing the number
>> of forks/execs that occur for each file retrieved from Subversion. To do so, a
>> few new options are added to git-cat-file and git-hash-object to allow
>> continuous input on stdin and continuous output on stdout, so that one instance
>> of each of these commands can be kept running for the duration of the fetch.
>
> You don't need to do this to avoid forks. Just use git-fast-import
> instead.
git-fast-import only covers the hash-object side of things, not cat-file.
git-fast-import does not currently suit 'gradual deployment' for
converters such as git-svn, because it;
- returns object IDs at the end, when you checkpoint.
This could be 'fixed' by allowing a marks log file instead of or in
addition to the current behaviour, though if the exporter is
continually waiting for the tokens rather than using marks, it will
slow it down.
- you can't use plumbing commands, such as rev-parse, cat-file, etc on
objects which have not been checkpointed yet.
- can't just stream a file of unknown length to it as you can to
hash-object
These are the design trade-offs of using fast-import. Using
fast-import, you are creating a 'transaction' area which uses user
sequences instead of (git)database-issued identifiers. And this
transaction is isolated from the other concurrent users of the object
database. However the interface does not have the full git CLI
available to it, so unlike a regular database transaction, you end up
having to care.
Rewriting the importer so as to correctly deal with these problems is
quite challenging, and for slow import sources such as Subversion, of
limited merit.
Sam.
^ permalink raw reply
* Re: UI and git-completion.sh
From: Matthieu Moy @ 2007-10-24 0:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <86prz59y9s.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
> Matthieu> In zsh itself.
>
> Matthieu> Completion/Unix/Command/_git
>
> Not in my version of zsh. Any chance I can add that to my 4.2.3
> installation?
http://zsh.cvs.sourceforge.net/zsh/zsh/Completion/Unix/Command/_git
Try adding it to your $fpath, hopefully, the new _git doesn't use the
other new zsh features, and it will work (I have a CVS _git with a
4.3.4 zsh, and it works like a charm).
--
Matthieu
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <vpqbqapgx0j.fsf@bauges.imag.fr>
>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Matthieu> http://zsh.cvs.sourceforge.net/zsh/zsh/Completion/Unix/Command/_git
Matthieu> Try adding it to your $fpath, hopefully, the new _git doesn't use the
Matthieu> other new zsh features, and it will work (I have a CVS _git with a
Matthieu> 4.3.4 zsh, and it works like a charm).
Do I add it as _git below my $fpath? Or do I need to put it into a subdir?
How will it know it is there?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: UI and git-completion.sh
From: Brian Downing @ 2007-10-24 0:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <86d4v59wvt.fsf@blue.stonehenge.com>
On Tue, Oct 23, 2007 at 05:31:02PM -0700, Randal L. Schwartz wrote:
> Yes, so what is the process of adding the git zsh completion to any
> relatively stable version of zsh? Someone here must know.
I dunno the "right" way to do it, but I had this in my .zshrc file that
I presumably cargo-culted from somewhere:
fpath=( $HOME/.zsh/compfuncs $fpath )
So in addition to that, doing:
wget -O ~/.zsh/compfuncs/_git 'http://zsh.cvs.sourceforge.net/*checkout*/zsh/zsh/Completion/Unix/Command/_git'
might get you something. I guess if your zsh is too old it might be
incompatible with the completion script, though...
-bcd
^ permalink raw reply
* Re: UI and git-completion.sh
From: Brian Downing @ 2007-10-24 0:57 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <20071024005549.GC24924@lavos.net>
On Tue, Oct 23, 2007 at 07:55:49PM -0500, Brian Downing wrote:
> I dunno the "right" way to do it, but I had this in my .zshrc file that
> I presumably cargo-culted from somewhere:
>
> fpath=( $HOME/.zsh/compfuncs $fpath )
I think this has to come before "compinit" or whatever starts up the new
completion engine.
-bcd
^ permalink raw reply
* git-{diff,ls}-files from a subdirectory fails ...
From: Karl Hasselström @ 2007-10-24 1:20 UTC (permalink / raw)
To: git
... when GIT_DIR is specified.
I have a repository at ~/stgit-lib. With cwd at the top of the tree,
things work as expected when I set all those fancy envoronment
variables:
kha@yoghurt:~/stgit-lib> git-diff-files --name-only
stgit/utillib.py
kha@yoghurt:~/stgit-lib> GIT_DIR=/home/kha/stgit-lib/.git GIT_INDEX_FILE=/home/kha/stgit-lib/.git/index GIT_WORK_TREE=/home/kha/stgit-lib git-diff-files --name-only
stgit/utillib.py
However, it doen't seem to work from a subdirectory:
kha@yoghurt:~/stgit-lib/stgit> git-diff-files --name-only
stgit/utillib.py
kha@yoghurt:~/stgit-lib/stgit> GIT_DIR=/home/kha/stgit-lib/.git GIT_INDEX_FILE=/home/kha/stgit-lib/.git/index GIT_WORK_TREE=/home/kha/stgit-lib git-diff-files --name-only | wc
170 170 3560
Instead of just the one changed file, I get a list of what looks like
all the files in the project, suggesting that maybe git assumes I'm at
the root of the worktree when I'm not.
git-ls-files seems to behave the same way. Bug or user error?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-24 2:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
On 10/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So once again, what operations involving git do people use regularly?
>
> <rationale>There is a good chance that git is not optimised for most
> people's daily workflows, as project maintainers seemed to be much more
> forthcoming with patches, and therefore maintainers' tasks are much more
> optimised than in other SCMs.</rationale>
For working on gitweb in git.git repository.
1. Fetch (when I am on topic branch) or pull (in rare cases I am on master)
2. "stg rebase origin"
3. work, work, work, using StGIT to generate perfect patch series
(going back and forth between patches, reordering patches, adding
patch in the middle of series, concatenating two patches, etc.; for
example when I notice that something should be changed in previous
patch, be it either bug noticed just now, or change in preparatory
patch to better suit main one)
4. fetch and rebase just between publishing
5. git format-patch to generate patch series; use git-shortlog or
grepping for patches subjects and git-diff --stat to generate
introductory email. Unfortunately StGIT template for introductory
email does have neither shortlog nor diffstat fields to atomatically
fill. Add comments to patches if needed.
6. Either use KMail + attach inline (no word wrap), or git-send-mail
(with sendmail configured to use gmail account; now I could use simply
git-send-mail configuration in user config) to send patches to git
mailing list
7. Push changes (if I don't forget) to repo.or.cz repository (jnareb-git.git).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 5/9] git-cat-file: Add --separator option
From: Brian Downing @ 2007-10-24 3:43 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio C Hamano
In-Reply-To: <1193118397-4696-6-git-send-email-aroben@apple.com>
On Mon, Oct 22, 2007 at 10:46:33PM -0700, Adam Roben wrote:
> +--separator::
> + A string to print in between the output for each object passed on
> + stdin. A newline will be appended to the separator each time it is
> + printed.
Maybe I'm just unreasonably paranoid, but I don't think I could ever
trust that you'd never find an arbitrary separator in the data. I
suppose if you scanned the files beforehand you could come up with
something guaranteed to be unique, but that seems like a pain (and
doesn't happen regardless in patch 9/9; it just uses
"--------------GITCATFILESEPARATOR-----------") If I were committing to
SVN, it's sure not something I'd like to bet the integrity of my data
on.
I think a far more reasonable output format for multiple objects would
be something like:
<count> LF
<raw data> LF
Where <count> is the number of bytes in the <raw data> as an ASCII
decimal integer.
This is pretty much the spiritual analog to the fast-import "exact byte
count" data input format as well.
-bcd
^ permalink raw reply
* Re: [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
From: Christian Couder @ 2007-10-24 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v640x7a4n.fsf@gitster.siamese.dyndns.org>
Le mercredi 24 octobre 2007, Junio C Hamano a écrit :
> Sort of offtopic, but is "factorise" a correct verb here? I
> thought "factorise" is to express a non prime number as the
> product of prime numbers.
English is not my mother tongue so I very often make mistakes.
Sorry about that.
Anyway my prefered online dictionary finds it:
http://www.wordreference.com/definition/factorise
> "refactor" is the act of splitting and merging pieces of
> functions for better reuse, isn't it?
Yes, it would be better.
I used "factorise" because as a french native speaker, I am always tempted
to use word that sound the same as their french translation.
By the way I realised that the "bisect_write" function is still
missing 'nolog="$3"', so I will send an updated patch.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 5/9] git-cat-file: Add --separator option
From: Adam Roben @ 2007-10-24 4:26 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Junio C Hamano
In-Reply-To: <20071024034301.GE24924@lavos.net>
Brian Downing wrote:
> On Mon, Oct 22, 2007 at 10:46:33PM -0700, Adam Roben wrote:
>
>> +--separator::
>> + A string to print in between the output for each object passed on
>> + stdin. A newline will be appended to the separator each time it is
>> + printed.
>>
>
> Maybe I'm just unreasonably paranoid, but I don't think I could ever
> trust that you'd never find an arbitrary separator in the data. I
> suppose if you scanned the files beforehand you could come up with
> something guaranteed to be unique, but that seems like a pain (and
> doesn't happen regardless in patch 9/9; it just uses
> "--------------GITCATFILESEPARATOR-----------") If I were committing to
> SVN, it's sure not something I'd like to bet the integrity of my data
> on.
>
I had some of the same concerns.
> I think a far more reasonable output format for multiple objects would
> be something like:
>
> <count> LF
> <raw data> LF
>
> Where <count> is the number of bytes in the <raw data> as an ASCII
> decimal integer.
>
This sounds like a much better solution. I'll implement it that way and
send out a new patch. Thanks for the suggestion!
-Adam
^ permalink raw reply
* intended use of "git --exec-path"?
From: Scott Parish @ 2007-10-24 4:32 UTC (permalink / raw)
To: git
"git --exec-path" presently prints out the highest priority path
to find executable in. That's a what; i'm curious why and when it
should be used. Basically i'm wondering if its still useful, and
what, if anything, it should be printing.
Thanks
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: intended use of "git --exec-path"?
From: Shawn O. Pearce @ 2007-10-24 4:38 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071024043224.GR16291@srparish.net>
Scott Parish <sRp@srparish.net> wrote:
> "git --exec-path" presently prints out the highest priority path
> to find executable in. That's a what; i'm curious why and when it
> should be used. Basically i'm wondering if its still useful, and
> what, if anything, it should be printing.
git-gui uses it. git-gui runs git-* by prefixing it with the
exec path. It also scans the first line of the file if we are on
Windows and the "executable" doesn't end in ".exe" so it can figure
out what process to run it through.
So it really can't go away.
--
Shawn.
^ permalink raw reply
* [PATCH 1/3] Bisect: refactor "bisect_write_*" functions.
From: Christian Couder @ 2007-10-24 5:01 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-bisect.sh | 46 ++++++++++++++++++++--------------------------
1 files changed, 20 insertions(+), 26 deletions(-)
This patch series change the title of 3 patches in the
"bisect skip" series from "Bisect: factorise ..." to
"Bisect: refactor ...".
In the second patch in this series a missing line has
also been added back.
diff --git a/git-bisect.sh b/git-bisect.sh
index cd46190..82aa404 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -108,9 +108,9 @@ bisect_start() {
}
if [ $bad_seen -eq 0 ]; then
bad_seen=1
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
else
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
fi
shift
;;
@@ -122,6 +122,18 @@ bisect_start() {
bisect_auto_next
}
+bisect_write() {
+ state="$1"
+ rev="$2"
+ case "$state" in
+ bad) tag="$state" ;;
+ good|skip) tag="$state"-"$rev" ;;
+ *) die "Bad bisect_write argument: $state" ;;
+ esac
+ echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
+ echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_bad() {
bisect_autostart
case "$#" in
@@ -132,17 +144,11 @@ bisect_bad() {
*)
usage ;;
esac || exit
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
bisect_auto_next
}
-bisect_write_bad() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/bad"
- echo "# bad: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_good() {
bisect_autostart
case "$#" in
@@ -153,18 +159,12 @@ bisect_good() {
for rev in $revs
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
-bisect_write_good() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev"
- echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_skip() {
bisect_autostart
case "$#" in
@@ -175,18 +175,12 @@ bisect_skip() {
for rev in $revs
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write_skip "$rev"
+ bisect_write 'skip' "$rev"
echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
-bisect_write_skip() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/skip-$rev"
- echo "# skip: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -395,15 +389,15 @@ bisect_replay () {
eval "$cmd"
;;
good)
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
;;
bad)
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
;;
skip)
- bisect_write_skip "$rev"
+ bisect_write 'skip' "$rev"
echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
;;
*)
--
1.5.3.4.215.g187cf
^ permalink raw reply related
* [PATCH 2/3] Bisect: refactor some logging into "bisect_write".
From: Christian Couder @ 2007-10-24 5:01 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Also use "die" instead of "echo >&2 something ; exit 1".
And simplify "bisect_replay".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-bisect.sh | 47 ++++++++++++++---------------------------------
1 files changed, 14 insertions(+), 33 deletions(-)
The 'nolog="$3"' line is back in this patch.
diff --git a/git-bisect.sh b/git-bisect.sh
index 82aa404..61a2956 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -106,12 +106,11 @@ bisect_start() {
die "'$arg' does not appear to be a valid revision"
break
}
- if [ $bad_seen -eq 0 ]; then
- bad_seen=1
- bisect_write 'bad' "$rev"
- else
- bisect_write 'good' "$rev"
- fi
+ case $bad_seen in
+ 0) state='bad' ; bad_seen=1 ;;
+ *) state='good' ;;
+ esac
+ bisect_write "$state" "$rev" 'nolog'
shift
;;
esac
@@ -125,6 +124,7 @@ bisect_start() {
bisect_write() {
state="$1"
rev="$2"
+ nolog="$3"
case "$state" in
bad) tag="$state" ;;
good|skip) tag="$state"-"$rev" ;;
@@ -132,6 +132,7 @@ bisect_write() {
esac
echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+ test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
bisect_bad() {
@@ -145,7 +146,6 @@ bisect_bad() {
usage ;;
esac || exit
bisect_write 'bad' "$rev"
- echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
bisect_auto_next
}
@@ -160,7 +160,6 @@ bisect_good() {
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write 'good' "$rev"
- echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
@@ -176,7 +175,6 @@ bisect_skip() {
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write 'skip' "$rev"
- echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
@@ -352,10 +350,8 @@ bisect_reset() {
else
branch=master
fi ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" || {
- echo >&2 "$1 does not seem to be a valid branch"
- exit 1
- }
+ 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
+ die "$1 does not seem to be a valid branch"
branch="$1" ;;
*)
usage ;;
@@ -375,10 +371,7 @@ bisect_clean_state() {
}
bisect_replay () {
- test -r "$1" || {
- echo >&2 "cannot read $1 for replaying"
- exit 1
- }
+ test -r "$1" || die "cannot read $1 for replaying"
bisect_reset
while read bisect command rev
do
@@ -386,23 +379,11 @@ bisect_replay () {
case "$command" in
start)
cmd="bisect_start $rev"
- eval "$cmd"
- ;;
- good)
- bisect_write 'good' "$rev"
- echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
- bad)
- bisect_write 'bad' "$rev"
- echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
- skip)
- bisect_write 'skip' "$rev"
- echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
+ eval "$cmd" ;;
+ good|bad|skip)
+ bisect_write "$command" "$rev" ;;
*)
- echo >&2 "?? what are you talking about?"
- exit 1 ;;
+ die "?? what are you talking about?" ;;
esac
done <"$1"
bisect_auto_next
--
1.5.3.4.215.g187cf
^ permalink raw reply related
* [PATCH 3/3] Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
From: Christian Couder @ 2007-10-24 5:01 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-bisect.sh | 82 +++++++++++++++++++++-----------------------------------
1 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 61a2956..f8d0099 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -135,47 +135,33 @@ bisect_write() {
test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
-bisect_bad() {
+bisect_state() {
bisect_autostart
- case "$#" in
- 0)
- rev=$(git rev-parse --verify HEAD) ;;
- 1)
- rev=$(git rev-parse --verify "$1^{commit}") ;;
+ state=$1
+ case "$#,$state" in
+ 0,*)
+ die "Please call 'bisect_state' with at least one argument." ;;
+ 1,bad|1,good|1,skip)
+ rev=$(git rev-parse --verify HEAD) ||
+ die "Bad rev input: HEAD"
+ bisect_write "$state" "$rev" ;;
+ 2,bad)
+ rev=$(git rev-parse --verify "$2^{commit}") ||
+ die "Bad rev input: $2"
+ bisect_write "$state" "$rev" ;;
+ *,good|*,skip)
+ shift
+ revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@"
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") ||
+ die "Bad rev commit: $rev^{commit}"
+ bisect_write "$state" "$rev"
+ done ;;
*)
usage ;;
- esac || exit
- bisect_write 'bad' "$rev"
- bisect_auto_next
-}
-
-bisect_good() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'good' "$rev"
- done
- bisect_auto_next
-}
-
-bisect_skip() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
- esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'skip' "$rev"
- done
bisect_auto_next
}
@@ -405,24 +391,22 @@ bisect_run () {
exit $res
fi
- # Use "bisect_good" or "bisect_bad"
- # depending on run success or failure.
+ # Find current state depending on run success or failure.
if [ $res -gt 0 ]; then
- next_bisect='bisect_bad'
+ state='bad'
else
- next_bisect='bisect_good'
+ state='good'
fi
- # We have to use a subshell because bisect_good or
- # bisect_bad functions can exit.
- ( $next_bisect > "$GIT_DIR/BISECT_RUN" )
+ # We have to use a subshell because "bisect_state" can exit.
+ ( bisect_state $state > "$GIT_DIR/BISECT_RUN" )
res=$?
cat "$GIT_DIR/BISECT_RUN"
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
- echo >&2 "$next_bisect exited with error code $res"
+ echo >&2 "'bisect_state $state' exited with error code $res"
exit $res
fi
@@ -444,12 +428,8 @@ case "$#" in
case "$cmd" in
start)
bisect_start "$@" ;;
- bad)
- bisect_bad "$@" ;;
- good)
- bisect_good "$@" ;;
- skip)
- bisect_skip "$@" ;;
+ bad|good|skip)
+ bisect_state "$cmd" "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
--
1.5.3.4.215.g187cf
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox