public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg•org>
To: Christian Couder <chriscool@tuxfamily•org>
Cc: Jon Seymour <jon.seymour@gmail•com>,
	git@vger•kernel.org, gitster@pobox•com, jnareb@gmail•com,
	jrnieder@gmail•com
Subject: Re: [PATCH v17 1/7] bisect: move argument parsing before state modification.
Date: Wed, 07 Sep 2011 20:07:46 +0200	[thread overview]
Message-ID: <4E67B2F2.9070806@kdbg.org> (raw)
In-Reply-To: <201109070816.16655.chriscool@tuxfamily.org>

Am 07.09.2011 08:16, schrieb Christian Couder:
> If we start bisecting like this:
> 
> $ git bisect start HEAD HEAD~20
> 
> and then we decide that it was not optimum and we want to start again like 
> this:
> 
> $ git bisect start HEAD HEAD~6
> 
> then issuing the latter command might not work as it did before this patch.
>  
> Before this patch the latter command would do a "git checkout $start_head" 
> before the repeated rev=$(git rev-parse -q --verify "$arg^{commit}") to 
> convert arguments into sha1. And after this patch the order is reversed.
> 
> This means that before this patch "HEAD" in the arguments to "git bisect 
> start" would refer to $start_head because the "git checkout $start_head" 
> changes HEAD. After this patch "HEAD" in the arguments to "git bisect start" 
> would refer to the current HEAD.

But isn't this an improvement? HEAD denotes the current head. After the
first 'bisect start HEAD HEAD~20', HEAD is somewhere in the middle, not
the original HEAD anymore; I would *expect* that a different commit is
checked out if I just repeat the command.

IOW, I think the new behavior is *much* better than the old behavior.

-- Hannes

  parent reply	other threads:[~2011-09-07 18:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 12:00 [PATCH v17 0/7] bisect: Add support for --no-checkout option Jon Seymour
2011-08-04 12:00 ` [PATCH v17 1/7] bisect: move argument parsing before state modification Jon Seymour
2011-09-07  6:16   ` Christian Couder
2011-09-07 11:29     ` Junio C Hamano
2011-09-07 18:07     ` Johannes Sixt [this message]
2011-09-08  1:23       ` Jon Seymour
2011-08-04 12:00 ` [PATCH v17 2/7] bisect: use && to connect statements that are deferred with eval Jon Seymour
2011-08-04 12:00 ` [PATCH v17 3/7] bisect: add tests to document expected behaviour in presence of broken trees Jon Seymour
2011-08-04 12:01 ` [PATCH v17 4/7] bisect: introduce support for --no-checkout option Jon Seymour
2011-08-04 12:01 ` [PATCH v17 5/7] bisect: introduce --no-checkout support into porcelain Jon Seymour
2011-08-04 12:01 ` [PATCH v17 6/7] bisect: add tests for the --no-checkout option Jon Seymour
2011-08-04 12:01 ` [PATCH v17 7/7] bisect: add documentation for " Jon Seymour

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E67B2F2.9070806@kdbg.org \
    --to=j6t@kdbg$(echo .)org \
    --cc=chriscool@tuxfamily$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=jnareb@gmail$(echo .)com \
    --cc=jon.seymour@gmail$(echo .)com \
    --cc=jrnieder@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox