On 09/04/2014 10:12 PM, Burton, Ross wrote:
Hi,
Quick question of style for the community to bikeshed on: in the
general case should recipes be split into foo_1.2.bb and foo.inc, or
should they only split to bb/inc if there are multiple versions and
generally there should just be foo_1.2.bb.
On 09/04/2014 08:03 AM, Robert Yang wrote:
On 09/04/2014 10:12 PM, Burton, Ross wrote:
Hi,
Quick question of style for the community to bikeshed on: in the
general case should recipes be split into foo_1.2.bb and foo.inc, or
should they only split to bb/inc if there are multiple versions an
"Burton, Ross" writes:
> Quick question of style for the community to bikeshed on: in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
>
> Specifically I'm
On 4 September 2014 16:41, akuster808 wrote:
> This is the same reason why I have split a bb into two parts when I submit
> upgrades. I feel it makes reviewing easier the next time a package gets
> upgraded. Trying to find the actual changes between a file being deleted and
> the new one being add
On 4 September 2014 17:07, Enrico Scholz
wrote:
> .inc files make sense with current packaging because they are revision
> control friendly. E.g. you can put the logic into .inc and follow its
> history with 'git log' which is not possible when there are only the
> versioned .bb files.
You can f
On 09/04/2014 11:29 AM, Burton, Ross wrote:
On 4 September 2014 17:07, Enrico Scholz
wrote:
.inc files make sense with current packaging because they are revision
control friendly. E.g. you can put the logic into .inc and follow its
history with 'git log' which is not possible when there are o
"Peter A. Bigot" writes:
>>> .inc files make sense with current packaging because they are revision
>>> control friendly. E.g. you can put the logic into .inc and follow its
>>> history with 'git log' which is not possible when there are only the
>>> versioned .bb files.
>> You can follow change
On Thu, Sep 4, 2014 at 7:00 PM, Enrico Scholz
wrote:
> "Peter A. Bigot" writes:
>
.inc files make sense with current packaging because they are revision
control friendly. E.g. you can put the logic into .inc and follow its
history with 'git log' which is not possible when there ar
Andreas Müller
writes:
>> it's not only 'git log'; it is 'git blame' too and because git does not
>> support renaming of files natively, the 'git log --follow' method is
>> error prone and might compare the wrong files resp. fail completely when
>> there are too much changes.
>>
> Did you ever us
On 4 September 2014 19:36, Enrico Scholz
wrote:
>> Did you ever use 'git blame' for few lines most recipes have?
>
> In other projects (e.g. linux kernel) I am using C-x v g in emacs very
> often to see when/why a certain line was added. In some OE recipes I
> would like to do the same...
Person
On 09/04/2014 09:26 AM, Burton, Ross wrote:
On 4 September 2014 16:41, akuster808 wrote:
This is the same reason why I have split a bb into two parts when I submit
upgrades. I feel it makes reviewing easier the next time a package gets
upgraded. Trying to find the actual changes between a fil
On Thursday 04 September 2014 15:12:02 Burton, Ross wrote:
> Quick question of style for the community to bikeshed on: in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just b
On 09/04/14 15:12, Burton, Ross wrote:
> If someone knows a good UI for blame-digging then please let me know!
http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-git-repository/
http://vimcasts.org/episodes/fugitive-vim-browsing-the-git-object-database/
--
__
13 matches
Mail list logo
