<div dir="ltr"><div><div>My specific questions:</div><div>- is there a Git command that will tell me the revision closest to HEAD which has both A and B as ancestors? Kind of the opposite of `git merge-base`.</div><div>- I'm trying `git bisect`, but this seems more useful if I'm not already sure which revisions are the source of the bug. Would you use `git bisect` in a situation like this?</div>
</div><div><br></div><div>Here is my situation to provide some context:</div><div><br></div><div>- I have a bug in my code which causes a crash.</div><div>- The offending line of code is identified in the stack trace</div>
<div>- Using `git blame HEAD <source file>`, I can see when the offending line was last changed. (commit A)</div><div>- I can also determine that this is a problem due to integration of a new feature. (commit B)</div>
<div><br></div><div>I think the best practices approach would be to create a branch starting with the revision where this feature was introduced (commit B), fix the bug, then merge the fix in to whichever other branches need it.</div>
<div><br></div><div>To complicate matters a bit, there are three branches involved - master, rc (release candidate) and fb (feature branch).</div><div><br></div><div>The original change which conflicts with the feature was merged into master.</div>
<div>The feature branch was originally merged into rc, which has since merged into and from master a few times.</div><div><br></div><div>So I'm not certain if rc contained commit A when commit B was introduced. I'm finding it difficult to trace the history using `gitk` to determine this visually.</div>
<div><br></div><div>More generally, is my bugfix branching approach reasonable? It seems like an awful lot of work for a very minor bugfix, will it make my life easier in the future? I haven't used Perl for a while, but I do see laziness as a virtue. Perhaps this last question is too off-topic, feel free not to answer this.</div>
</div>