istr that git reset was chosen for a reason. @mikeb, do you recall the specifics?

It seemed the most likely to work in all cases, as it is documented to bring the working tree and index into sync at that commit. git checkout <commit ID> is documented to retain local modifications. The difference is probably minor since we run it right after git clone -n, so there should be no working tree or local modifications, but it seemed like the safer choice. I'd be reluctant to change it to satisfy this particular use-case.

There should be another way to determine if the current commit is a branch tip, like seeing if the commit hash is in the output of git show-ref.

If you're worried about local modifications you also need to worry about local modifications not known to Git, in which case git reset is not sufficient: you would also need a git clean -fdx

Since that's not happening it seems the git clone -n is always clean, so the use of git checkout would not cause problems.

The problem with the git reset is it destroys the information about which branch was requested; if there are two branches pointing to the same commit there is no way to know which one to use. Since I want to let developers select a branch of the repository Source0 comes from and use its git describe state to generate an interim version number for accumulating test builds in a tag (developing a small chain of packages with BuildRequire dependencies), trying to use git show-ref doesn't solve my problem.

Maybe a better option would be to put some information about the task into the environment that make sources is run in. The task parameters could be exposed there, and your make sources could use that to do whatever operations it needs to.

That would also work if it would be a better fit. It would have the benefit of being useful for other SCMs.

I would need to specify "origin/<branchname>" rather than "<branchname>" in my SCM URL to make the git reset work, but I don't mind doing that.

As long as I can get at the commit portion of the SCM URL originally requested, I can do what I need to.

It means extending mock call to pass some env variables, which is quite simply (just adding env to os.execvp. On the other hand I'm not sure, if we want to go with such changes now (before buildroot API redesign). On the other hand, it seems like direction which is aligned with it. @mikem?

So you deliberately want two builds from the same git commit to build differently?

That sounds very wrong to me.

In our internal system, we have some plugin code that checks what branch is used, but it does this by checking which branches contain the commit. This is possibly multi-valued of course, but we account for that.

So you deliberately want two builds from the same git commit to build differently?

I think of it more as having a "development/hacking mode" selector. Instead of fetching the source as a tarball with a known value it will clone the repository, check out the matching branch and describe it to generate a version. The resulting SRPM has properties which prevent it from ever escaping to release. This is all the responsibility of "make sources" though and not Koji's problem; anyone who does not attempt magic will see no change in behaviour.

Now you might say to just keep the source and the spec together, but there are other workflow reasons why I can't have that solution.

As of Koji 1.18 I can get what I want by abusing the ability to set per-tag RPM macros, and use a different build target for magic dev builds, so this is obsolete and can be closed.