On Fri, Apr 22, 2016 at 5:29 PM, Dale R. Worley <wor...@alum.mit.edu> wrote:
> Ram Rachum <ram.rac...@gmail.com> writes:
> > Then, as I said in the beginning, a friend pointed me towards the
> > `--full-history` flag:
> > $ git log --full-history --graph coffee
> > * commit 0aa833916e908ea93902a6c4c227f9a884a1bcef
> > |\ Merge: cf02fbb 3068c7d
> > | | Author: Ram Rachum <r...@rachum.com>
> > | | Date: Tue Apr 19 17:44:31 2016 +0300
> > | |
> > | | Merge branch 'master' into development
> > | |
> > | * commit 3068c7d2548f1798b6840f73b13a649937339f28
> > |/ Author: Ram Rachum <r...@rachum.com>
> > | Date: Tue Apr 19 16:02:27 2016 +0300
> > |
> > | Adding sugar to coffee
> > |
> > * commit cf02fbbc40104cd02eea4c7c6f134ef1fd7b5661
> > Author: Ram Rachum <r...@rachum.com>
> > Date: Tue Apr 19 16:00:47 2016 +0300
> > Create coffee
> > This makes me happy because it shows the two relevant commits, the one
> > adding sugar and the merge that removed it. So my problem is solved.
> > I really wish I could know how to make `git bisect` as well.** Does
> > happen to know?
> You have to be careful here. You *think* of commit 0aa833 as removing
> sugar, but it only removes sugar with respect to commit 3068c7. It's
> *other* parent doesn't have sugar, in fact, has the same file tree as
> 0aa833. When you look at 0aa833 as a child of cf02fb, what you see is a
> merge that didn't insert sugar that was present in the merged commit.
> And if sugar was some debugging print that you added to the branch to
> test it, you'd think of things the second way.
> The deep question is "What is the (linear) history of this commit?" You
> *think* of the history being 0aa833-3068c7-cf02fbbc, but it's equally
> valid to think of it as 0aa833-cf02fbbc.
> Now with regard to git-bisect, how do you define it? The binary search
> for "Where was this introduced?" only makes sense along a linear path.
> So which linear path should git-bisect choose through the directed
> acyclic graph of commits?
The first thing you do with bisect is define a good commit (3068) and a bad
commit (b7a8). Any linear path you draw between these two commits will land
on the merge (which is the commit that you want to find.) I don't know
which linear path git-bisect uses today, but I'm not seeing how it can use
a linear path that skips the bad merge. In any case, it would be nice if
it'll have an option similar to `--full-history` that'll make it not skip
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.