[bitbake-devel] [PATCH] bitbake: bb.fetch2.git: Fix _latest_revision function while using tags

[Andrei Gherzan]

On Jan 7, 2014 5:52 PM, "Olof Johansson" <olof.johansson at axis.com> wrote:
>
> On 14-01-07 16:02 +0100, Richard Purdie wrote:
> > On Tue, 2014-01-07 at 15:46 +0100, Olof Johansson wrote:
> > > I agree with your reasoning with regards to not needing a
> > > fallback for Andrei's patch, but my patch tries to first resolve
> > > refs/tags/<tag> (fully qualified) and then falls back to try
> > > refs/heads/<branch>. The reason for this is that ls-remote will
> > > return things like refs/heads/lalala/<tag> if you only do
> > > ls-remote <tag>.
> >
> > Can we somehow anchor the expression instead e.g. refs/*/<xxx>^{}
>
> Sure, we can do ls-remote without any arguments and parse the
> output. But this won't make the patch easier in any way. One less
> fork though.
>
> > > My attempt was also to break out the tasks into simple,
> > > atomic(-ish) functions that would later be easier to write unit
> > > tests for. You complained on IRC that changes to the fetcher
> > > usually comes back to bite you. I believe increased unit test
> > > coverage on low level functions, as a compliment to the existing
> > > more high level suite, can be beneficial in this regard.
> >
> > I believe that my complaint could also be addressed by ensuring the high
> > level tests had more coverage of the variety of supported use cases. In
> > this case a range of tags of differing types, branches and hanging
> > commits would have helped ensure the changes to the fetcher didn't break
> > things.
>
> Yes, that probably possible. *I* find low level unit tests easier
> to work with, and I wanted to do what I could to alleviate the
> situation; making sure that (at least) our use cases are covered
> by automated tests.
>
> > I'm less keen on forcing an atom like set of functions on the fetcher
> > just for the purposes of the test suite. Sorry I was unclear on that, I
> > guess different people have different understandings of what increased
> > coverage would mean.
>
> I find it easier to work in functions with limited scopes, with
> clear purposes --- with or without unittests (unittests being
> preferable, obviously). But then again, I'm not the maintainer,
> so your preferences are more important :-).
>
> > > Also, if you are holding things off, I would really appreciate
> > > you letting us know so that we can make appropriate workarounds
> > > if needed (as in this case, where we have had to supsend testing
> > > on master :-().
> >
> > Well, it wasn't a conscious decision so much as the holidays came along
> > and I ran out of time to look at it. I'm trying to get this resolved now
> > since obviously various people are hitting the problem cases.
>
> I really appreciate the hard work you are doing :-).

Me too :-)

I agree that we really need to fix this as we are breaking layers out in
the wild with this issue.

@olof sorry for duplicate email.

ag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20140107/18eadf6b/attachment-0002.html>