Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 8月, 2011 1 次提交
  3. 05 8月, 2011 3 次提交
  5. 22 5月, 2011 11 次提交
  7. 22 3月, 2011 1 次提交
  9. 14 10月, 2010 3 次提交
    • S
      bisect: check for mandatory argument of 'bisect replay' · 2c7c3877
      由 SZEDER Gábor 提交于 
      'git bisect replay' has a mandatory logfile argument, but the current
implementation doesn't check whether the user has specified one.  When
the user omits the logfile argument, this leads to the following
unhelpful error message:

  cannot read  for replaying

So, check for the mandatory argument first, and provide a more
meaningful error message when it is omitted.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2c7c3877
    • S
      bisect: improve error msg of 'bisect reset' when original HEAD is deleted · 3bb8cf88
      由 SZEDER Gábor 提交于 
      'git bisect reset' (without the optional <commit> argument) returns to
the original HEAD from where the bisection was started.  However,
when, for whatever reason, the user deleted the original HEAD before
invoking 'git bisect reset', then all he gets is an error message from
'git checkout':

  fatal: invalid reference: somebranch

Let's try to be more helpful with an error message better describing
what went wrong and a suggestion about how to resolve the situation:

  Could not check out original HEAD 'somebranch'. Try 'git bisect reset <commit>'.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3bb8cf88
    • S
      bisect: improve error message of 'bisect log' while not bisecting · 412ff738
      由 SZEDER Gábor 提交于 
      'git bisect log' is implemented by a direct invocation of 'cat
"$GIT_DIR/BISECT_LOG"', without any sanity checks.  Consequently,
running 'git bisect log' while not bisecting leads to an error,
because the bisect logfile doesn't exists.  The accompanying error
message

  cat: /path/to/repo/.git/BISECT_LOG: No such file or directory

is neither very helpful nor very friendly.

Instead of blindly trying to cat the log file, first check whether
there is a bisection going on (i.e. the bisect logfile exists), and
die with a more appropriate error message when not.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      412ff738
  11. 24 11月, 2009 1 次提交
    • J
      Protect scripted Porcelains from GREP_OPTIONS insanity · e1622bfc
      由 Junio C Hamano 提交于 
      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: NJunio C Hamano <gitster@pobox.com>
      e1622bfc
  13. 23 11月, 2009 1 次提交
  15. 14 10月, 2009 1 次提交
    • A
      bisect reset: Allow resetting to any commit, not just a branch · 6b87ce23
      由 Anders Kaseorg 提交于 
      ‘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: NAnders Kaseorg <andersk@mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6b87ce23
  17. 27 8月, 2009 1 次提交
  19. 11 5月, 2009 1 次提交
  21. 10 5月, 2009 2 次提交
  23. 05 4月, 2009 3 次提交
  25. 04 3月, 2009 1 次提交
    • C
      rev-list: estimate number of bisection step left · 9f199b15
      由 Christian Couder 提交于 
      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: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9f199b15
  27. 28 2月, 2009 1 次提交
  29. 27 2月, 2009 1 次提交
    • C
      bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped · 1b249ffe
      由 Christian Couder 提交于 
      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: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1b249ffe
  31. 04 1月, 2009 1 次提交
  33. 03 12月, 2008 2 次提交
  35. 26 11月, 2008 1 次提交
    • C
      bisect: teach "skip" to accept special arguments like "A..B" · ee2314f5
      由 Christian Couder 提交于 
      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: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ee2314f5
  37. 10 11月, 2008 1 次提交
  39. 06 9月, 2008 1 次提交
  41. 28 8月, 2008 2 次提交
    • C
      bisect: only check merge bases when needed · c9c4e2d5
      由 Christian Couder 提交于 
      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: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c9c4e2d5
    • C
      bisect: test merge base if good rev is not an ancestor of bad rev · f821d089
      由 Christian Couder 提交于 
      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: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f821d089