From: Steven Michalske <smichalske@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: RFC: Make git bisect submodule aware.
Date: Wed, 9 Jun 2010 05:50:29 -0700 [thread overview]
Message-ID: <6AC4E373-C28F-455E-93A6-6FA5A57723A2@gmail.com> (raw)
When git bisect discovers that the change set that creates the failure
also contains a submodule change, that submodule should then be
bisected starting with the good super modules code and working to a
break in the sub module. If the change contains submodule change and
super code changes than the bisection gets trickier, so we need some
ideas on how to solve that search.
Example:
Super: A-B-C-D-E
Sub: s-s-y-y-z
Where s is not required to be a parent of y, meaning that there might
be 300 commits or just 1 between s and y in the submodule or they are
disjoint then the bisecting should happen both routes into the
submodule.
So the git bisect found that the offending commit is C
Now if the offending commit only changes 1 submodule than it is a
normal bisect for the changed submodule.
If in commit C file foo.c changed and the submodule changed a bit more
work is needed.
If foo.c is not dependent on a new feature from between s and y than
we are good, otherwise I feel a bit of human intervention might be
needed for marking a 'good' version in the submodule. Otherwise we
have to search for a 'good' starting point, a binary bisection
probably won't help much but probably would not hurt, since you need a
'good' commit to start the bisection from.
So for the not dependent on new feature/bugfix in the submodule.
B's foo.c and s -> good/bad?
B's foo.c and y -> good/bad?
C's foo.c and s -> good/bad?
C's foo.c and y -> good/bad?
have fun bisecting.....
It might be good to interactively ask, for this bisection will file
foo.c have an affect?
If the file has an effect:
Ask if C's foo.c will work with range s..y, if not what is the
expected range for operation, we know that we need version u of
submodule to compile C's foo.c. Or we have to search (linear from s)
to where we can work.
otherwise, just bisect the submodule.
Steve
next reply other threads:[~2010-06-09 12:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 12:50 Steven Michalske [this message]
2010-06-09 14:57 ` RFC: Make git bisect submodule aware Johan Herland
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6AC4E373-C28F-455E-93A6-6FA5A57723A2@gmail.com \
--to=smichalske@gmail.com \
--cc=git@vger.kernel.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).