help: bisect single file from repos

help: bisect single file from repos

[walter harms]

Hi list,
i am new to git (using: git version 1.6.0.2).

I would like to bisect a single file but i have only commit id, no tags.

Background:
I have a copy of the busybox git repos, and i know there is (perhaps) a bug
in ash.c.

how can i do that ?

re,
 wh

Re: help: bisect single file from repos

[Michael J Gruber]

walter harms venit, vidit, dixit 07.12.2009 13:59:
> Hi list,
> i am new to git (using: git version 1.6.0.2).

though your git is not that new ;)

> I would like to bisect a single file but i have only commit id, no tags.
> 
> Background:
> I have a copy of the busybox git repos, and i know there is (perhaps) a bug
> in ash.c.
> 
> how can i do that ?

You don't need any tags for bisecting. The man page of git-bisect has
several examples on how to use it. Do you have a test script which
exposes the bug?

Michael

Re: help: bisect single file from repos

[walter harms]

Michael J Gruber schrieb:
> walter harms venit, vidit, dixit 07.12.2009 13:59:
>> Hi list,
>> i am new to git (using: git version 1.6.0.2).
> 
> though your git is not that new ;)
> 
>> I would like to bisect a single file but i have only commit id, no tags.
>>
>> Background:
>> I have a copy of the busybox git repos, and i know there is (perhaps) a bug
>> in ash.c.
>>
>> how can i do that ?
> 
> You don't need any tags for bisecting. The man page of git-bisect has
> several examples on how to use it. Do you have a test script which
> exposes the bug?
> 

unfortunately no, the error shows up very nicely when booting my embdedded system
but not else (this is the reason i would to bisect that file only and not busybox
completely). And from the man pages i got the impression that it is only possible the
start with a tag.

i already had the hint that i need to do:
git bisect start bad_commit_id good_commit_id -- ash.c

Ntl, there is one more question, how can i make sure that
i use the right version ? first i toughed  that cherry-pick is the right idea
but it seems that that will apply onyl certain patches ?

re,
 wh

Re: help: bisect single file from repos

[Christian Couder]

Hi,

On lundi 07 décembre 2009, walter harms wrote:
> Michael J Gruber schrieb:
> > walter harms venit, vidit, dixit 07.12.2009 13:59:
> >> Hi list,
> >> i am new to git (using: git version 1.6.0.2).
> >
> > though your git is not that new ;)
> >
> >> I would like to bisect a single file but i have only commit id, no
> >> tags.
> >>
> >> Background:
> >> I have a copy of the busybox git repos, and i know there is (perhaps)
> >> a bug in ash.c.
> >>
> >> how can i do that ?
> >
> > You don't need any tags for bisecting. The man page of git-bisect has
> > several examples on how to use it. Do you have a test script which
> > exposes the bug?
>
> unfortunately no, the error shows up very nicely when booting my
> embdedded system but not else (this is the reason i would to bisect that
> file only and not busybox completely). And from the man pages i got the
> impression that it is only possible the start with a tag.

The man page says:

git bisect start [<bad> [<good>...]] [--] [<paths>...]

and then:

"This command uses git rev-list --bisect to help drive the binary search 
process to find which change introduced a bug, given an old "good" commit 
object name and a later "bad" commit object name."

> i already had the hint that i need to do:
> git bisect start bad_commit_id good_commit_id -- ash.c

So did you try that?

> Ntl, there is one more question, how can i make sure that
> i use the right version ?

If you mean the right git version, then I think any 1.6.X should be enough.

> first i toughed  that cherry-pick is the right 
> idea but it seems that that will apply onyl certain patches ?

If you want to find the commit that introduced a bug, then you should not 
need cherry-pick.

Regards,
Christian.

Re: help: bisect single file from repos

[walter harms]

Christian Couder schrieb:
> Hi,
> 
> On lundi 07 décembre 2009, walter harms wrote:
>> Michael J Gruber schrieb:
>>> walter harms venit, vidit, dixit 07.12.2009 13:59:
>>>> Hi list,
>>>> i am new to git (using: git version 1.6.0.2).
>>> though your git is not that new ;)
>>>
>>>> I would like to bisect a single file but i have only commit id, no
>>>> tags.
>>>>
>>>> Background:
>>>> I have a copy of the busybox git repos, and i know there is (perhaps)
>>>> a bug in ash.c.
>>>>
>>>> how can i do that ?
>>> You don't need any tags for bisecting. The man page of git-bisect has
>>> several examples on how to use it. Do you have a test script which
>>> exposes the bug?
>> unfortunately no, the error shows up very nicely when booting my
>> embdedded system but not else (this is the reason i would to bisect that
>> file only and not busybox completely). And from the man pages i got the
>> impression that it is only possible the start with a tag.
> 
> The man page says:
> 
> git bisect start [<bad> [<good>...]] [--] [<paths>...]
> 
> and then:
> 
> "This command uses git rev-list --bisect to help drive the binary search 
> process to find which change introduced a bug, given an old "good" commit 
> object name and a later "bad" commit object name."


i am sorry, i am not familiar with git and when i am stating i am looking
for examples first. the examples in my man page are like
git bisect start v2.6.20-rc6 v2.6.20-rc4
there is nothing like:
git bisect start 6a87a68a6a8 65a76a8a68a7

I ASSUME that you can use tags like "v2.6.20-rc6" and commit-id like "6a87a68a6a8"
interchangeable but that was not clear from beginning.
BTW did you notice the sentence says "commit object name" not "commit id" ? when
you are starting you are not familiar with the wording so you do not make the connection.


>> i already had the hint that i need to do:
>> git bisect start bad_commit_id good_commit_id -- ash.c
> 
> So did you try that?
> 

not yet, we are still using an older version of BB for production. So there is no hurry.
The problem is that we can not found the reason for the bug. NTL i plan for this week.


>> Ntl, there is one more question, how can i make sure that
>> i use the right version ?
> 
> If you mean the right git version, then I think any 1.6.X should be enough.
> 
>> first i toughed  that cherry-pick is the right 
>> idea but it seems that that will apply onyl certain patches ?
> 
> If you want to find the commit that introduced a bug, then you should not 
> need cherry-pick.
> 

mmh, no, the idea was to use something like

git "checkou" <id>  and having a version that represents THAT moment.


re,
 wh

> Regards,
> Christian.
> 

Re: help: bisect single file from repos

[Junio C Hamano]

walter harms <wharms@bfs.de> writes:

> Christian Couder schrieb:
> ...
> i am sorry, i am not familiar with git and when i am stating i am looking
> for examples first. the examples in my man page are like
> git bisect start v2.6.20-rc6 v2.6.20-rc4
> there is nothing like:
> git bisect start 6a87a68a6a8 65a76a8a68a7
>
> I ASSUME that you can use tags like "v2.6.20-rc6" and commit-id like "6a87a68a6a8"
> interchangeable but that was not clear from beginning.

The misconception here is "naming commit is done completely differently
from naming branches and tags", which is false in the git land, but it may
hold true in some other systems (e.g. Subversion, which made them into
different dimensions by making branches and tags into a location in a
larger whole tree namespace when their commits are named by serial version
number of that whole tree namespace).

We can call this a misconception, tell users to learn how things work
before using git (sometimes unlearning CVS and Subversion helps for this
exact reason), dismiss the issue and move on.  But I wonder if there is
something we _could_ have done better in the documentation area to avoid
this from the beginning, iow, make it easier to "learn how things work
before using"?  I think there is a lesson to be learned by us in here, and
I'd like to hear comments and improvement suggestions, especially from
"usability" and "friendly to new people" advocates.

Re: help: bisect single file from repos

[SZEDER Gábor]

Hi,


On Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:
> But I wonder if there is
> something we _could_ have done better in the documentation area to avoid
> this from the beginning, iow, make it easier to "learn how things work
> before using"?  I think there is a lesson to be learned by us in here, and
> I'd like to hear comments and improvement suggestions, especially from
> "usability" and "friendly to new people" advocates.

when a git command accepts a commit as command line option, the
documentation usually refers to the "Specifying revisions" section of
'git rev-parse's docs for "a more complete list of ways to spell
commits"[1].  Even the docs of porcelain commands and the user manual
do that.  But 'git rev-parse' is plumbing, and we actively advertise
that avarage users don't really need to know about plumbing at all.
While new to git I repeatedly encountered this reference to 'git
rev-parse' all over the porcelain manpages, and it was a real burden
for me back then.  I was like "but I don't want to know about all the
glory details, just give me a short summary".

I think the user should not refer to plumbing manpages to be able to
use porcelain commands.  Therefore, the manpage of every command
accepting a commit option need to have a section about specifying
these commits.  This section doesn't need to be as detailed as 'git
rev-parse'; perhaps we don't need to discuss the ^{} notation there.
Also, the precedence in case of an ambiguous symbolic ref name should
be described without reference to the internal $GIT_DIR/refs/
directory structure.

Furthermore, some manpages use the term "<commit>", while others
"<committish>" or "<rev>".  The same term should be used everywhere.


Best,
Gábor


[1] - 'git cherry-pick' doc says the following:

  <commit>
    Commit to cherry-pick. For a more complete list of ways to spell
    commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).

What?  "A _more_ complete list"!?  Well, it's not very hard to be more
complete than this, there is not a single way described here (;

Re: help: bisect single file from repos

[Nanako Shiraishi]

Quoting SZEDER Gábor <szeder@ira.uka.de>

> [1] - 'git cherry-pick' doc says the following:
>
>   <commit>
>     Commit to cherry-pick. For a more complete list of ways to spell
>     commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
>
> What?  "A _more_ complete list"!?  Well, it's not very hard to be more
> complete than this, there is not a single way described here (;

I agree that "more" shouldn't be in that sentence, and I understand your hesitation to read plumbing manual pages, but I don't think it is a sane solution to the issue to repeat how to name a commit in manual pages for every single command to bloat the two line description you quoted into a half-page paragraph. Even within that two lines, the real information that should be in the manual for cherry-pick is only three words "Commit to cherry-pick" and the rest is to help people who don't know.

Maybe it is a better idea to rewrite this to "See 'basic concepts' manual for how to specify a commit", and create a new 'basic concepts' manual that describes these things the readers must know to effectively use the main part of the manual.  And make sure that we try very hard to keep the 'basic concepts' manual short, by eg. making a goal to keep it less than N printed pages.

To decide the value of 'N', somebody needs to first think and list the topics that need to be covered by 'basic concepts'. Something like this?

 * What are committed states, the state in the index and the state in the working tree.
 * How to name a commit.
 * How to name a range of commit (move part from the rev-parse manual).
 * How to specify options, revisions and files on command line (move part from the gitcli manual).

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: help: bisect single file from repos

[SZEDER Gábor]

Hi,


On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
> Quoting SZEDER Gábor <szeder@ira.uka.de>
> 
> > [1] - 'git cherry-pick' doc says the following:
> >
> >   <commit>
> >     Commit to cherry-pick. For a more complete list of ways to spell
> >     commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
> >
> > What?  "A _more_ complete list"!?  Well, it's not very hard to be more
> > complete than this, there is not a single way described here (;
> 

> I agree that "more" shouldn't be in that sentence, and I understand
> your hesitation to read plumbing manual pages, but I don't think it
> is a sane solution to the issue to repeat how to name a commit in
> manual pages for every single command to bloat the two line
> description you quoted into a half-page paragraph.  Even within that
> two lines, the real information that should be in the manual for
> cherry-pick is only three words "Commit to cherry-pick" and the rest
> is to help people who don't know.

I agree, that's why I proposed "a _section_ about specifying these
commits" in the more relevant part of my previous email you did not
quote.

The description of the "<commit>" option would remain almost the same,
but it will now refer to a dedicated section about specifying commits
below, but still in the same manpage.  This new dedicated section
would contain the list of three, five, N most common ways to specify a
commit, avoiding the bloatage in the options section.  And for those
who really want to dig deep, this dedicated section will refer to 'git
rev-parse' for the complete list.

And this would not be the first time we document something in many
places, think of '--pretty' and diff options, for example.


Best,
Gábor

Re: help: bisect single file from repos

[walter harms]

SZEDER Gábor schrieb:
> Hi,
> 
> 
> On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
>> Quoting SZEDER Gábor <szeder@ira.uka.de>
>>
>>> [1] - 'git cherry-pick' doc says the following:
>>>
>>>   <commit>
>>>     Commit to cherry-pick. For a more complete list of ways to spell
>>>     commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
>>>
>>> What?  "A _more_ complete list"!?  Well, it's not very hard to be more
>>> complete than this, there is not a single way described here (;
> 
>> I agree that "more" shouldn't be in that sentence, and I understand
>> your hesitation to read plumbing manual pages, but I don't think it
>> is a sane solution to the issue to repeat how to name a commit in
>> manual pages for every single command to bloat the two line
>> description you quoted into a half-page paragraph.  Even within that
>> two lines, the real information that should be in the manual for
>> cherry-pick is only three words "Commit to cherry-pick" and the rest
>> is to help people who don't know.
> 
> I agree, that's why I proposed "a _section_ about specifying these
> commits" in the more relevant part of my previous email you did not
> quote.
> 
> The description of the "<commit>" option would remain almost the same,
> but it will now refer to a dedicated section about specifying commits
> below, but still in the same manpage.  This new dedicated section
> would contain the list of three, five, N most common ways to specify a
> commit, avoiding the bloatage in the options section.  And for those
> who really want to dig deep, this dedicated section will refer to 'git
> rev-parse' for the complete list.
> 
> And this would not be the first time we document something in many
> places, think of '--pretty' and diff options, for example.
> 
> 

It would be no problem when you have the description multiple times.
Important is that they use the same words for the same things
and add examples. Most people that use git have a fair idea what they
want but not how to do it. git is new an you can not assume that
even basic principles are known to the general (programmer) community.
So you need to make extra effort to explain it all over again.

re,
 wh