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

[Olof Johansson]

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 :-).


Regards,
-- 
olofjn