tgover1/repo-plugin — comment on commit bc24a03e8e033f6c4365558e348ab0ad96491373
File:  line 0
By tgover1:

Hi Brad,

Congratulations on the infant, I know the feeling about the lack of free
time ;-)

The direct usage of git is to workaround this bug in repo
http://code.google.com/p/git-repo/issues/detail?id=46

The problem occurs when you have

1) An upstream build that just syncs the code, and checks in a full
specified manifest for the synced code in a new repository. It creates also
creates a tag.

2) Downstream build(s) that do repo init -b refs/tags/${TAG_NAME} where
TAG_NAME is defined by the upstream build.

For some reason rather than just switching to the manifest specified repo
attempts to merge the changes between the manifest for the old tag and the
manifest for the new tag in it's private "default" branch. If the manifest
has changed enough then a merge conflict occurs.

Ideally, the Jenkins repo plug-in wouldn't use git directly because as you
say it makes it fragile to change to the repo python scripts. I tried
commenting out the code and upgrading to the latest version of repo but the
bug is still present. There may be another workaround, I just don't know
what it is would be.

The best I can think of is to make this behaviour conditional on a flag
configured in Advanced Settings. At least, that would avoid breaking simple
Jenkins repo configurations if repo itself changes.

On 9 December 2011 22:51, Brad Larson <
reply@reply.github.com
> wrote:

> I'm very sorry it has taken so long to get to this. Having an infant
> really changes the amount of free time one has. Do you have any thoughts
> on my comment above?
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/tgover1/repo-plugin/commit/bc24a03e8e033f6c4365558e348ab0ad96491373#commitcomment-783337
>