From: Andreas Ericsson <ae@op5.se>
To: Tom Prince <tom.prince@ualberta.net>
Cc: Steffen Prohaska <prohaska@zib.de>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
Date: Fri, 02 Nov 2007 14:52:15 +0100 [thread overview]
Message-ID: <472B2B8F.1060203@op5.se> (raw)
In-Reply-To: <20071102132446.GA31758@hermes.priv>
Tom Prince wrote:
> On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>>> you need to start a new bisect for each of the parents included
>>>> in the merge. Hopefully the nature of the merge gives a clue so
>>>> the user can make an educated guess as to which parent introduced
>>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>>> merge had conflicts which were resolved in a buggy way (not
>>>> exactly uncommon), it can be quite a hassle to get things right.
>>>> With a mostly linear history, this problem goes away.
>>> This is really an interesting point. I did not start to use
>>> git bisect regularly. But I certainly plan to do so in the future.
>>> Couldn't bisect learn to better cope with non-linear history?
>> Perhaps it could, but it's far from trivial. I started hacking on
>> a wrapper for git-bisect which would do just that, but gave up
>> rather quickly as the book-keeping required to remember each and
>> every parent-point tried just got out of hand, and it *still*
>> wouldn't run in full automatic. It broke down because I also
>> wanted merges on non-first-line parents to be delved into. If
>> that didn't happen, I wouldn't *know* the bisect would run fine
>> without me watching it, so then it was as useless as if I'd have
>> had to sit there the entire time anyway.
>
> I haven't had occasion to use git-bisect much, but I was under the
> impression that bisect could already handle merges, or any other shaped
> history just fine.
>
It appears the code supports your statement. I started writing on my
hack-around about a year ago, and the merge-handling code got in with
1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
Perhaps I shouldn't be so paranoid about useless merges anymore then.
Hmm. I shall have to look into it. Perhaps Junio can clarify how it
works? The man-page was terribly silent about how git-bisect handles
merges.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2007-11-02 13:52 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-28 17:46 [PATCH 0/10 v3] improve refspec handling in push Steffen Prohaska
2007-10-28 17:46 ` [PATCH 01/10] push: change push to fail if short refname does not exist Steffen Prohaska
2007-10-28 17:46 ` [PATCH 02/10] push: teach push new flag --create Steffen Prohaska
2007-10-28 17:46 ` [PATCH 03/10] push: support pushing HEAD to real branch name Steffen Prohaska
2007-10-28 17:46 ` [PATCH 04/10] push: add "git push HEAD" shorthand for 'push current branch to default repo' Steffen Prohaska
2007-10-28 17:46 ` [PATCH 05/10] rename ref_matches_abbrev() to ref_abbrev_matches_full_with_fetch_rules() Steffen Prohaska
2007-10-28 17:46 ` [PATCH 06/10] add ref_abbrev_matches_full_with_rev_parse_rules() comparing abbrev with full ref name Steffen Prohaska
2007-10-28 17:46 ` [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs Steffen Prohaska
2007-10-28 17:46 ` [PATCH 08/10] push: teach push to accept --verbose option Steffen Prohaska
2007-10-28 17:46 ` [PATCH 09/10] push: teach push to pass --verbose option to transport layer Steffen Prohaska
2007-10-28 17:46 ` [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref Steffen Prohaska
2007-10-30 8:29 ` Junio C Hamano
2007-10-30 10:15 ` Steffen Prohaska
2007-10-30 10:26 ` Andreas Ericsson
2007-10-30 10:53 ` Steffen Prohaska
2007-10-30 19:19 ` Junio C Hamano
2007-10-31 7:53 ` Steffen Prohaska
2007-10-31 8:45 ` Junio C Hamano
[not found] ` <B3C76DB8-076D-4C43-AC28-99119A05325C@z ib.de>
2007-10-31 9:14 ` Junio C Hamano
2007-10-31 10:50 ` Steffen Prohaska
2007-10-31 18:51 ` Junio C Hamano
2007-10-31 21:09 ` Steffen Prohaska
2007-10-31 21:31 ` Junio C Hamano
2007-11-01 7:03 ` Steffen Prohaska
2007-11-01 9:11 ` Andreas Ericsson
2007-11-01 16:43 ` Steffen Prohaska
2007-11-01 20:18 ` Junio C Hamano
2007-11-02 7:21 ` Steffen Prohaska
2007-11-02 7:52 ` Junio C Hamano
2007-11-02 10:03 ` Steffen Prohaska
2007-11-02 10:44 ` Junio C Hamano
2007-11-02 11:40 ` Steffen Prohaska
2007-11-02 10:03 ` Andreas Ericsson
2007-11-02 13:24 ` Tom Prince
2007-11-02 13:52 ` Andreas Ericsson [this message]
2007-11-02 14:49 ` Steffen Prohaska
2007-11-02 19:42 ` Junio C Hamano
2007-11-02 20:19 ` Junio C Hamano
2007-11-01 8:18 ` Andreas Ericsson
2007-11-01 8:36 ` Steffen Prohaska
2007-11-01 9:29 ` Andreas Ericsson
2007-11-02 8:18 ` Wincent Colaiuta
2007-11-02 12:14 ` Johannes Schindelin
2007-11-02 12:48 ` Steffen Prohaska
2007-11-02 13:11 ` Wincent Colaiuta
2007-10-30 18:00 ` Daniel Barkalow
2007-10-30 8:28 ` [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs Junio C Hamano
2007-10-30 8:49 ` Steffen Prohaska
2007-10-30 8:28 ` [PATCH 04/10] push: add "git push HEAD" shorthand for 'push current branch to default repo' Junio C Hamano
2007-10-30 8:28 ` [PATCH 03/10] push: support pushing HEAD to real branch name Junio C Hamano
2007-10-30 8:29 ` [PATCH 01/10] push: change push to fail if short refname does not exist Junio C Hamano
2007-10-30 8:56 ` Steffen Prohaska
2007-10-30 9:22 ` Junio C Hamano
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=472B2B8F.1060203@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=prohaska@zib.de \
--cc=tom.prince@ualberta.net \
/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
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;
as well as URLs for NNTP newsgroup(s).