All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Ke <ke.yu@intel.com>
To: poky@yoctoproject.org
Subject: Re: [PATCH 1/1] fetcher2/git: add document for git fetcher supported options
Date: Wed, 25 May 2011 10:15:03 +0800	[thread overview]
Message-ID: <4DDC6627.3070908@intel.com> (raw)
In-Reply-To: <20110524171702.GB18086@sakrah.homelinux.org>

on 2011-5-25 1:17, Khem Raj wrote:
> On (24/05/11 14:58), Yu Ke wrote:
>> CC: Khem Raj<raj.khem@gmail.com>
>> CC: Darren Hart<dvhart@linux.intel.com>
>>
>> Signed-off-by: Yu Ke<ke.yu@intel.com>
>> ---
>>   bitbake/lib/bb/fetch2/git.py |   37 ++++++++++++++++++++++++++++++++++---
>>   1 files changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
>> index 82721c6..b07298d 100644
>> --- a/bitbake/lib/bb/fetch2/git.py
>> +++ b/bitbake/lib/bb/fetch2/git.py
>> @@ -3,6 +3,40 @@
>>   """
>>   BitBake 'Fetch' git implementation
>>
>> +git fetcher support the SRC_URI with format of:
>> +SRC_URI = "git://some.host/somepath;OptionA=xxx;OptionB=xxx;..."
>> +
>> +Supported SRC_URI options are:
>> +
>> +- branch
>> +   The git branch to retrieve from. The default is "master"
>> +
>> +   this option also support multiple branches fetching, branches
>> +   are seperated by comma. in multiple branches case, the name option
>> +   must have the same number of names to match the branches, which is
>> +   used to specify the SRC_REV for the branch
>> +   e.g:
>> +   SRC_URI="git://some.host/somepath;branch=branchX,branchY;name=nameX,nameY"
>> +   SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx"
>> +   SRCREV_nameY = "YYYYYYYYYYYYYYYYYYYY"
>> +
>> +- tag
>> +    The git tag to retrieve. The default is "master"
>> +
>> +- protocol
>> +   The method to use to access the repository. Common options are "git",
>> +   "http", "file" and "rsync". The default is "rsync"
>> +
>> +- rebaseable
>> +   rebaseable indicates that the upstream git repo may rebase in the future,
>> +   and current revision may disappear from upstream repo. This option will
>> +   reminder fetcher to preserve local cache carefully for future use.
>> +   The default value is "0", set rebaseable=1 for rebaseable git repo
>
> for consistency why not make rebaseable=true/false as well ?
>
>> +
>> +- nocheckout
>> +   Don't checkout source code when unpacking. set this option for the recipe
>> +   who has its own routine to checkout code. The default is false
>                                                                  ^^^^
> may be it should be in '' or quotes

Good catch. my description is not 100% accurate here. Actually this 
parameter has no default value. According to the nocheckout handling code:
"
         ud.nocheckout = False
         if 'nocheckout' in ud.parm:
             ud.nocheckout = True
"
the value does not matter, what matters is that if the SRC_URI have this 
option set. In another word, "nocheckout=0" also lead to ud.nocheckout=True.

So I am thinking if it is better to make the nocheckout format the same 
as rebaseable, e.g.
"
	ud.nocheckout = ud.parm.get("nocheckout","0") == "1"
"
i.e. the default value is "0", and set nocheckout=1 for nocheckout 
recipe. In this case, we have consistency format. And this format also 
consist with other bitbake variable, for example, 
BB_GENERATE_MIRROR_TARBALLS. Also the current existing recipes are 
already using the "nocheckout=1" format, so this change require no 
recipe change.

Comments?

Regards
Ke


      reply	other threads:[~2011-05-25  2:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24  6:58 [PATCH 0/1] git fetcher: add doc for supported options Yu Ke
2011-05-24  6:58 ` [PATCH 1/1] fetcher2/git: add document for git fetcher " Yu Ke
2011-05-24  7:43   ` Koen Kooi
2011-05-24  7:54     ` Yu Ke
2011-05-24 17:17   ` Khem Raj
2011-05-25  2:15     ` Yu Ke [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DDC6627.3070908@intel.com \
    --to=ke.yu@intel.com \
    --cc=poky@yoctoproject.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.