Граф коммитов

100 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano ad7ace714d Merge branch 'rs/work-around-grep-opt-insanity'
* rs/work-around-grep-opt-insanity:
  Protect scripted Porcelains from GREP_OPTIONS insanity
  mergetool--lib: simplify guess_merge_tool()

Conflicts:
	git-instaweb.sh
2009-11-25 11:45:07 -08:00
Junio C Hamano e1622bfcba Protect scripted Porcelains from GREP_OPTIONS insanity
If the user has exported the GREP_OPTIONS environment variable, the output
from "grep" and "egrep" in scripted Porcelains may be different from what
they expect.  For example, we may want to count number of matching lines,
by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.

The approach taken by this change to address this issue is to protect only
our own use of grep/egrep.  Because we do not unset it at the beginning of
our scripts, hook scripts run from the scripted Porcelains are exposed to
the same insanity this environment variable causes when grep/egrep is used
to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
hook scripts to protect themselves.

On the other hand, applypatch-msg hook may want to show offending words in
the proposed commit log message using grep to the end user, and the user
might want to set GREP_OPTIONS=--color to paint the match more visibly.
The approach to protect only our own use without unsetting the environment
variable globally will allow this use case.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-23 16:31:07 -08:00
Christian Couder fc13aa3d09 bisect: simplify calling visualizer using '--bisect' option
In commit ad3f9a7 (Add '--bisect' revision machinery argument) the
'--bisect' option was added to easily pass bisection refs to
commands using the revision machinery.

So it is now shorter and safer to use the new '--bisect' revision
machinery option, than to compute the refs that we must pass.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-22 22:59:05 -08:00
Anders Kaseorg 6b87ce231d bisect reset: Allow resetting to any commit, not just a branch
‘git bisect reset’ accepts an optional argument specifying a branch to
check out after cleaning up the bisection state.  This lets you
specify an arbitrary commit.

In particular, this provides a way to clean the bisection state
without moving HEAD: ‘git bisect reset HEAD’.  This may be useful if
you are not interested in the state before you began a bisect,
especially if checking out the old commit would be expensive and
invalidate most of your compiled tree.

Clarify the ‘git bisect reset’ documentation to explain this optional
argument, which was previously mentioned only in the usage message.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13 23:19:02 -07:00
Nanako Shiraishi 21d0bc2f9a git-bisect: call the found commit "*the* first bad commit"
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-26 12:05:57 -07:00
Christian Couder 0871984d30 bisect: make "git bisect" use new "--next-all" bisect-helper function
This patch replace the "--next-exit" option of "git bisect--helper"
with a "--next-all" option that does merge base checking using
the "check_good_are_ancestors_of_bad" function implemented in
"bisect.c" in a former patch.

The new "--next-all" option is then used in "git-bisect.sh" instead
of the "--next-exit" option, and all the shell functions in
"git-bisect.sh" that are now unused are removed.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-10 14:30:33 -07:00
Christian Couder de52f5a806 bisect: use "git rev-parse --sq-quote" instead of a custom "sq" function
As the "sq" function was the only place using Perl in "git-bisect.sh",
this removes the Perl dependency in this script.

While at it, we also remove the sed instruction in the Makefile that
substituted @@PERL@@ with the Perl path in shell scripts, as this is
not needed anymore. (It is now only needed in "git-instaweb.sh" but
this command is dealt with separately in the Makefile.)

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-10 00:30:28 -07:00
Christian Couder 5a1d31c7e4 bisect: use "git bisect--helper --next-exit" in "git-bisect.sh"
instead of "git bisect--helper --next-vars".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-10 00:30:28 -07:00
Junio C Hamano 6e353a5e5d Merge branch 'cc/bisect-filter'
* cc/bisect-filter: (21 commits)
  rev-list: add "int bisect_show_flags" in "struct rev_list_info"
  rev-list: remove last static vars used in "show_commit"
  list-objects: add "void *data" parameter to show functions
  bisect--helper: string output variables together with "&&"
  rev-list: pass "int flags" as last argument of "show_bisect_vars"
  t6030: test bisecting with paths
  bisect: use "bisect--helper" and remove "filter_skipped" function
  bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES"
  bisect--helper: implement "git bisect--helper"
  bisect: use the new generic "sha1_pos" function to lookup sha1
  rev-list: call new "filter_skip" function
  patch-ids: use the new generic "sha1_pos" function to lookup sha1
  sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
  rev-list: pass "revs" to "show_bisect_vars"
  rev-list: make "show_bisect_vars" non static
  rev-list: move code to show bisect vars into its own function
  rev-list: move bisect related code into its own file
  rev-list: make "bisect_list" variable local to "cmd_rev_list"
  refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions
  quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
  ...
2009-04-12 16:46:40 -07:00
Christian Couder e89aa6d2f5 bisect--helper: string output variables together with "&&"
When doing:

eval "git bisect--helper --next-vars" | {
        while read line
        do
                echo "$line &&"
        done
        echo ':'
}

the result code comes from the last "echo ':'", not from running
"git bisect--helper --next-vars".

This patch gets rid of the need to string together the line from
the output of "git bisect--helper" with "&&" in the calling script
by making "git bisect--helper --next-vars" return output variables
already in that format.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-05 01:29:45 -07:00
Christian Couder 23b5f18b50 bisect: use "bisect--helper" and remove "filter_skipped" function
Use the new "git bisect--helper" builtin. It should be faster and
safer instead of the old "filter_skipped" shell function. And it
is a first step to move more shell code to C.

As the output is a little bit different we have to change the code
that interpret the results. But these changes improve code clarity.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-05 01:29:44 -07:00
Christian Couder f3a186ffad bisect: improve error message when branch checkout fails
In "git-bisect.sh" the "git checkout" command is only used to
change the current branch, but it is used like this:

git checkout "$branch"

which will output the following misleading error message when
it fails:

error: pathspec 'foo' did not match any file(s) known to git.

This patch change the way we use "git checkout" like this:

git checkout "$branch" --

so that we will get the following error message:

fatal: invalid reference: foo

which is better.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-05 00:25:08 -07:00
Christian Couder 9f199b1595 rev-list: estimate number of bisection step left
This patch teaches "git rev-list --bisect-vars" to output an estimate
of the number of bisection step left _after the current one_ along with
the other variables it already outputs.

This patch also makes "git-bisect.sh" display this number of steps left
_after the current one_, along with the estimate of the number of
revisions left to test (after the current one).

Here is a table to help analyse what should be the best estimate for
the number of bisect steps left.

N : linear case                    --> probabilities --> best
-------------------------------------------------------------
1 : G-B                            --> 0             --> 0
2 : G-U1-B                         --> 0             --> 0
3 : G-U1-U2-B                      --> 0(1/3) 1(2/3) --> 1
4 : G-U1-U2-U3-B                   --> 1             --> 1
5 : G-U1-U2-U3-U4-B                --> 1(3/5) 2(2/5) --> 1
6 : G-U1-U2-U3-U4-U5-B             --> 1(2/6) 2(4/6) --> 2
7 : G-U1-U2-U3-U4-U5-U6-B          --> 1(1/7) 2(6/7) --> 2
8 : G-U1-U2-U3-U4-U5-U6-U7-B       --> 2             --> 2
9 : G-U1-U2-U3-U4-U5-U6-U7-U8-B    --> 2(7/9) 3(2/9) --> 2
10: G-U1-U2-U3-U4-U5-U6-U7-U8-U9-B --> 2(6/10)3(4/10)--> 2

In the column "N", there is the number of revisions that could _now_
be the first bad commit we are looking for.

The "linear case" column describes the linear history corresponding to
the number in column N. G means good, B means bad, and Ux means
unknown. Note that the first bad revision we are looking for can be
any Ux or B.

In the "probabilities" column, there are the different outcomes in
number of steps with the odds of each outcome in parenthesis
corresponding to the linear case.

The "best" column gives the most accurate estimate among the different
outcomes in the "probabilities" column.

We have the following:

best(2^n) == n - 1

and for any x between 0 included and 2^n excluded, the probability for
n - 1 steps left looks like:

P(2^n + x) == (2^n - x) / (2^n + x)

and P(2^n + x) < 0.5 means 2^n < 3x

So the algorithm used in this patch calculates 2^n and x, and then
choose between returning n - 1 and n.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 00:56:52 -08:00
Junio C Hamano 48fce93565 Merge branch 'cc/maint-1.6.0-bisect-fix'
* cc/maint-1.6.0-bisect-fix:
  bisect: fix another instance of eval'ed string

Conflicts:
	git-bisect.sh
2009-02-27 16:00:33 -08:00
Christian Couder cce074a276 bisect: fix another instance of eval'ed string
When there is nothing to be skipped, the output from
rev-list --bisect-vars was eval'ed without first being
strung together with &&; this is probably not a problem
as it is much less likely to be a bad input than the list
handcrafted by the filter_skip function, but it still is
a good discipline.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27 14:30:34 -08:00
Junio C Hamano 0c34735616 Merge branch 'cc/maint-1.6.0-bisect-fix'
* cc/maint-1.6.0-bisect-fix:
  bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped

Conflicts:
	git-bisect.sh
2009-02-27 01:03:21 -08:00
Christian Couder 1b249ffe8d bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
When the "bad" commit was also "skip"ped and when more than one
commit was skipped, the "filter_skipped" function would have
printed something like:

    bisect_rev=<hash1>|<hash2>

(where <hash1> and <hash2> are hexadecimal sha1 hashes)

and this would have been evaled later as piping "bisect_rev=<hash1>"
into "<hash2>", which would have failed.

So this patch makes the "filter_skipped" function properly quote
what it outputs, so that it will print something like:

bisect_rev='<hash1>|<hash2>'

which will be properly evaled later.  The caller was not stopping
properly because the scriptlet this function returned to be evaled
was not strung together with && and because of this, an error in
an earlier part of the output was simply ignored.

A test case is added to the test suite.

And while at it, we also initialize the VARS, FOUND and TRIED
variables, so that we protect ourselves from environment variables
the user may have with these names.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27 00:57:28 -08:00
Johannes Schindelin 22b3ddd508 bisect view: call gitk if Cygwin's SESSIONNAME variable is set
It seems that Cygwin sets the variable SESSIONNAME when an interactive
desktop session is running, and does not set it when you log in via ssh.

So we can use this variable to determine whether to run gitk or git log
in git bisect view.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-03 14:25:27 -08:00
Christian Couder 5413812f08 Documentation: describe how to "bisect skip" a range of commits
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
2008-12-02 15:29:12 -08:00
Christian Couder 1a66a489d0 bisect: fix "git bisect skip <commit>" and add tests cases
The patch that allows "git bisect skip" to be passed a range of
commits using the "<commit1>..<commit2>" notation is flawed because
it introduces a regression when it was passed a simple rev or commit.

"git bisect skip <commit>" doesn't work any more, because <commit>
is quoted but not properly unquoted.

This patch fixes that and add tests cases to better check when it is
passed commits and range of commits.

While at it, this patch also properly quotes the non range arguments
using the "sq" function.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
2008-12-02 15:29:12 -08:00
Christian Couder ee2314f59a bisect: teach "skip" to accept special arguments like "A..B"
The current "git bisect skip" syntax is "git bisect skip [<rev>...]"
so it's already possible to skip a range of revisions using
something like:

$ git bisect skip $(git rev-list A..B)

where A and B are the bounds of the range we want to skip.

This patch teaches "git bisect skip" to accept:

$ git bisect skip A..B

as an abbreviation for the former command.

This is done by checking each argument to see if it contains two
dots one after the other ('..'), and by expending it using
"git rev-list" if that is the case.

Note that this patch will not make "git bisect skip" accept all
that "git rev-list" accepts, as things like "^A B" for exemple
will not work. But things like "A B..C D E F.. ..G H...I" should
work as expected.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-25 21:51:05 -08:00
Christian Couder d2d188d922 bisect: fix missing "exit"
Check to see given bad/good/skip sets are valid commit and to exit
otherwise was broken by 6a54d97 (bisect: remove "checkout_done" variable
used when checking merge bases, 2008-09-06).

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-09 10:23:37 -08:00
Christian Couder 6a54d976f6 bisect: remove "checkout_done" variable used when checking merge bases
Using return values from the following functions:

- check_merge_bases
- check_good_are_ancestors_of_bad

seems simpler.

While at it, let's add some comments to better document the above
functions.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 22:31:43 -07:00
Christian Couder c9c4e2d5a2 bisect: only check merge bases when needed
When one good revision is not an ancestor of the bad revision, the
merge bases between the good and the bad revision should be checked
to make sure that they are also good revisions.

A previous patch takes care of that, but it may check the merge bases
more often than really needed. In fact the previous patch did not try
to optimize this as much as possible because it is not so simple. So
this is the purpose of this patch.

One may think that when all the merge bases have been checked then
we can save a flag, so that we don't need to check the merge bases
again during the bisect process.

The problem is that the user may choose to checkout and test
something completely different from what the bisect process
suggested. In this case we have to check the merge bases again,
because there may be new merge bases relevant to the bisect
process.

That's why, in this patch, when we detect that the user tested
something else than what the bisect process suggested, we remove
the flag that says that we don't need to check the merge bases
again.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-27 18:08:06 -07:00
Christian Couder f821d08921 bisect: test merge base if good rev is not an ancestor of bad rev
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.

But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there, for example) instead of one
rev becoming bad in the branch of the bad rev.

For example, if there is the following history:

    A--B--C--D
	\
	 E--F

and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This could
invite user errors; F could be the commit that fixes the bug that exists
everywhere else.

The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestors of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.

If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.

These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-27 18:08:04 -07:00
Junio C Hamano 7e4ad90872 Merge branch 'maint'
* maint:
  git-bisect: fix wrong usage of read(1)
2008-08-11 19:24:28 -07:00
Francis Moreau e5d3afd78b git-bisect: fix wrong usage of read(1)
Signed-off-by:  Francis Moreau <francis.moro@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-11 16:48:11 -07:00
Miklos Vajna 6c98c0548a git-bisect: use dash-less form on git bisect log
Given that users are supposed to type 'git bisect' now, make the output
of 'git bisect log' consistent with this.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-11 21:13:16 -07:00
Christian Couder 823ea1211c bisect: use "$GIT_DIR/BISECT_START" to check if we are bisecting
It seems simpler and safer to use the BISECT_START file everywhere
to decide if we are bisecting or not, instead of using it in some
places and BISECT_NAMES in other places.

In commit 6459c7c678 (Nov 18 2007,
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.),
we decided to use BISECT_NAMES but code changed a lot and we now
have to check BISECT_START first in the "bisect_start" function
anyway.

This patch also makes things a little bit safer by creating
the BISECT_START file first and deleting it last, and also by
adding checks in "bisect_clean_state".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28 11:47:58 -07:00
Christian Couder 634f246444 bisect: use a detached HEAD to bisect
When "git bisect" was first written, it was not possible to
checkout a detached HEAD. The detached feature appeared latter.

That's why before this patch the "git bisect" process used a
"bisect" branch to checkout new revisions to be tested (and also
a "new-bisect" one to check if the checkouts could work).

This patch makes "git bisect" checkout revisions to be tested on
a detached HEAD. This simplifies the code a bit.

The tests to check that "git bisect" does not start if a
"bisect" or a "new-bisect" branch exists are removed as they
are not relevant any more.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22 22:45:03 -07:00
Christian Couder ba963de859 bisect: trap critical errors in "bisect_start"
Before this patch, when using "git bisect start" with mistaken revs
or when the checkout of the branch we want to test failed, we exited
after having written files like ".git/BISECT_START",
".git/BISECT_NAMES" and after having written "refs/bisect/bad" and
"refs/bisect/good-*" refs.

With this patch we trap all errors that can happen when writing the
new state and when we are in "bisect_next". So that we can try to
clean up everything in case of problems, using "bisect_clean_state".

This patch also contains a "bisect_write" cleanup to make it exit
on error and return 0 otherwise.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22 22:24:16 -07:00
Christian Couder 9d0cd91c4e bisect: fix left over "BISECT_START" file when starting with junk rev
Before this patch, when using for example:

$ git bisect start <stuff1> <stuff2>

with <stuff1> or <stuff2> that cannot be parsed as a revision, we
could leave a ".git/BISECT_START" file, from a previous
"git bisect start", alone.

This patch makes sure that it does not happen by removing the
"BISECT_START" file in "bisect_clean_state" and then always writing
it again at the end of "bisect_start".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22 22:16:45 -07:00
Junio C Hamano eafa29b7cb Merge branch 'gp/bisect-fix'
* gp/bisect-fix:
  bisect: print an error message when "git rev-list --bisect-vars" fails
  git-bisect.sh: don't accidentally override existing branch "bisect"
2008-05-12 15:44:43 -07:00
Christian Couder 42ba5ee776 bisect: print an error message when "git rev-list --bisect-vars" fails
Before this patch no error was printed when "git rev-list --bisect-vars"
failed. This can happen when bad and good revs are mistaken.

This patch prints an error message on stderr that describe the likely
failure cause.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08 17:50:00 -07:00
Gerrit Pape ee831f7ddf git-bisect.sh: don't accidentally override existing branch "bisect"
If a branch named "bisect" or "new-bisect" already was created in the
repo by other means than git bisect, doing a git bisect used to override
the branch without a warning.  Now if the branch "bisect" or
"new-bisect" already exists, and it was not created by git bisect itself,
git bisect start fails with an appropriate error message.  Additionally,
if checking out a new bisect state fails due to a merge problem, git
bisect cleans up the temporary branch "new-bisect".

The accidental override has been noticed by Andres Salomon, reported
through
 http://bugs.debian.org/478647

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05 17:18:20 -07:00
Junio C Hamano a17b1d2f0b Merge branch 'maint'
* maint:
  git-bisect: make "start", "good" and "skip" succeed or fail atomically
  git-am: cope better with an empty Subject: line
  Ignore leading empty lines while summarizing merges
  bisect: squelch "fatal: ref HEAD not a symref" misleading message
  builtin-apply: Show a more descriptive error on failure when opening a patch
  Clarify documentation of git-cvsserver, particularly in relation to git-shell
2008-04-16 00:45:52 -07:00
Junio C Hamano 464509f790 Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
  git-bisect: make "start", "good" and "skip" succeed or fail atomically
  git-am: cope better with an empty Subject: line
  Ignore leading empty lines while summarizing merges
  bisect: squelch "fatal: ref HEAD not a symref" misleading message
  builtin-apply: Show a more descriptive error on failure when opening a patch
  Clarify documentation of git-cvsserver, particularly in relation to git-shell
2008-04-16 00:37:33 -07:00
Christian Couder d3e54c8829 git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".

This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.

While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-16 00:11:37 -07:00
Christian Couder 48949a18c8 bisect: squelch "fatal: ref HEAD not a symref" misleading message
To get the current HEAD when we start bisecting using for example
"git bisect start", we first try "git symbolic-ref HEAD" to get a
nice name, and if it fails, we fall back to "git rev-parse
--verify HEAD".

The problem is that when "git symbolic-ref HEAD" fails, it
displays "fatal: ref HEAD not a symref", so it looks like "git
bisect start" failed and does not accept detached HEAD, even if
in fact it worked fine.

This patch adds "-q" option to the "git symbolic-ref" call to
get rid of the misleading error message.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-15 22:42:19 -07:00
Junio C Hamano f43e2fd43b Merge branch 'maint'
* maint:
  t7401: squelch garbage output
  Documentation/git-submodule: typofix
  Fix config key miscount in url.*.insteadOf
  Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)
  Document -w option to shortlog
  bisect: report bad rev better
2008-04-12 19:17:51 -07:00
Junio C Hamano d6d96f835c Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
  Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)
  Document -w option to shortlog
  bisect: report bad rev better
2008-04-12 15:41:19 -07:00
Christian Couder a179a30352 bisect: report bad rev better
The previous one overwrote the variable used to report the bad input
when the input is actually bad, and we did not give a useful enough
information.  This corrects it.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12 15:16:13 -07:00
Junio C Hamano 4cdda2b895 Merge branch 'maint'
* maint:
  bisect: fix bad rev checking in "git bisect good"
  revision.c: make --date-order overriddable
  git-submodule: Avoid 'fatal: cannot describe' message
  Force the medium pretty format on calls to git log
  Fix section about backdating tags in the git-tag docs
  Document option --only of git commit
  Documentation/git-request-pull: Fixed a typo ("send" -> "end")
2008-04-11 23:56:09 -07:00
Junio C Hamano eed81838f0 Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
  bisect: fix bad rev checking in "git bisect good"
  revision.c: make --date-order overriddable
  Fix section about backdating tags in the git-tag docs
  Document option --only of git commit
  Documentation/git-request-pull: Fixed a typo ("send" -> "end")
2008-04-11 23:55:55 -07:00
Christian Couder e3389075c6 bisect: fix bad rev checking in "git bisect good"
It seems that "git bisect good" and "git bisect skip" have never
properly checked arguments that have been passed to them. As soon
as one of them can be parsed as a SHA1, no error or warning would
be given.

This is because 'git rev-parse --revs-only --no-flags "$@"' always
"exit 0" and outputs all the SHA1 it can found from parsing "$@".

This patch fix this by using, for each "bisect good" argument, the
same logic as for the "bisect bad" argument.

While at it, this patch teaches "bisect bad" to give a meaningfull
error message when it is passed more than one argument.

Note that if "git bisect good" or "git bisect skip" is given some
proper revs and then something that is not a proper rev, then the
first proper revs will still have been marked as "good" or "skip".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-11 23:54:45 -07:00
Christian Couder 243a60fbb5 bisect: add "git bisect help" subcommand to get a long usage string
Users are not often aware of the fact that "git bisect -h" can give
them a long usage description, as "git bisect" seems to accept only
dashless subcommands like "start", "good", ...

That's why this patch adds a "git bisect help" subcommand that just
calls "git bisect -h". This new subcommand is also fully documented
in the short usage string (that "git bisect" gives), in the long
usage string and in the man page (that "git help bisect" gives).

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-11 23:03:50 -07:00
Jeff King 40a7ce64e1 tr portability fixes
Specifying character ranges in tr differs between System V
and POSIX. In System V, brackets are required (e.g.,
'[A-Z]'), whereas in POSIX they are not.

We can mostly get around this by just using the bracket form
for both sets, as in:

  tr '[A-Z] '[a-z]'

in which case POSIX interpets this as "'[' becomes '['",
which is OK.

However, this doesn't work with multiple sequences, like:

  # rot13
  tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]'

where the POSIX version does not behave the same as the
System V version. In this case, we must simply enumerate the
sequence.

This patch fixes problematic uses of tr in git scripts and
test scripts in one of three ways:

  - if a single sequence, make sure it uses brackets
  - if multiple sequences, enumerate
  - if extra brackets (e.g., tr '[A]' 'a'), eliminate
    brackets

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-12 21:10:00 -07:00
Carl Worth 0f497e75f0 Eliminate confusing "won't bisect on seeked tree" failure
This error message is very confusing---it doesn't tell the user
anything about how to fix the situation. And the actual fix
for the situation ("git bisect reset") does a checkout of a
potentially random branch, (compared to what the user wants to
be on for the bisect she is starting).

The simplest way to eliminate the confusion is to just make
"git bisect start" do the cleanup itself. There's no significant
loss of safety here since we already have a general safety in
the form of the reflog.

Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).

Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27 13:26:30 -08:00
Carl Worth b577bb925e Eliminate confusing "won't bisect on seeked tree" failure
This error message is very confusing---it doesn't tell the user
anything about how to fix the situation. And the actual fix
for the situation ("git bisect reset") does a checkout of a
potentially random branch, (compared to what the user wants to
be on for the bisect she is starting).

The simplest way to eliminate the confusion is to just make
"git bisect start" do the cleanup itself. There's no significant
loss of safety here since we already have a general safety in
the form of the reflog.

Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).

Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-24 17:41:33 -08:00
Johannes Schindelin 508e84a790 bisect view: check for MinGW32 and MacOSX in addition to X11
When deciding if gitk or git-log should be used to visualize the current
state, the environment variable DISPLAY was checked.  Now, we check
MSYSTEM (for MinGW32/MSys) and SECURITYSESSIONID (for MacOSX) in addition.

Note that there is currently no way to ssh into MinGW32, and that
SECURITYSESSIONID is not set automatically on MacOSX when ssh'ing into it.
So this patch should be safe.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-17 19:27:40 -08:00