[Buildroot] [PATCH 1/2] git: fix handling of git repos using master as version

Baruch Siach baruch at tkos.co.il
Tue Jun 5 03:26:19 UTC 2018


Hi Arnout,

On Tue, Jun 05, 2018 at 12:19:41AM +0200, Arnout Vandecappelle wrote:
> On 04-06-18 18:52, Gary Bisson wrote:
> > On Mon, Jun 04, 2018 at 05:32:41PM +0100, Bob Beckett wrote:
> >> Thanks for the more in depth explanation.
> >>
> >> I agree with all of the reasons outlined for the purpose of being purely a
> >> reproducible build manager, which buildroot only ever aimed to be.
> >>
> >> However, people do use it during development, and with a reasonably large
> >> number of custom packages all in development at the same time, using the
> >> _OVERRIDE_SRCDIR method to test latest versions of multiple packages
> >> becomes very unwieldy.
> >> My solution so far has been to point the version at the branch that active
> >> development is taking place on, and removing the build directories and
> >> packages for the specific projects each time.
> >> When I am not the one doing the development on each package's source, but
> >> am developing the rootfs, this means I dont have to manually keep updating
> >> my local git repositories for each project.
> >> Once each package has hit their first release version, they do get tagged
> >> and the release branch for the project's BR2_EXTERNAL directory gets
> >> updated with those versions, and each version thereafter, but the
> >> development branch for the external directory persistently stays on the
> >> development branch head for each package.
> >>
> >> Regarding not knowing the sha before a checkout, would git ls-remote not
> >> suffice for this? e.g.
> >>
> >> $ git ls-remote git at gitlab.com:adhlinux/buildroot/buildroot.git master
> >> 407fb2fe202aaeb273e4986dc88c30596a7fe8db    refs/heads/master
> >> 407fb2fe202aaeb273e4986dc88c30596a7fe8db    refs/remotes/upstream/master
> > 
> > Yes 'ls-remote' is actually a good option. 
> 
>  It's a bit racy though. By the time you do the actual fetch, the remote branch
> may already have been updated by someone else.

Someone might update the branch while you are fetching as well. As long as you 
fetch a valid commit ID that is known to have been at the branch tip at some 
point in the recent past, it should be fine from the user perspective.

baruch

> You could have the following
> > package version during development:
> > FOO_VERSION = $(shell git ls-remote URL branch | awk '{ print $$1 }')
> > 
> > Then it would pick up any change automatically until you finish your dev
> > and change the FOO_VERSION to a proper ID.
> > 
> >> It would allow you to check for changes in sha without doing a new fetch.
> >>
> >> Oh well, not to worry. Ill keep it as a local patch, as I suspect I am
> >> treading old ground of "buildroot is not a development platform" (Ive seen
> >> this discussion come up multiple times before).
> > 
> > Yes that will most likely not be included inside BR infrastructure but that
> > should be a perfectly fine option for your custom package.
> > 
> > Regards,
> > Gary

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


More information about the buildroot mailing list