Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux