Jonathan Wakely wrote:
> How do you get that directly from koji in a script?
>
> Is it as easy as a single git command to check if rawhide and
> rawhide-build are the same ref?
>
> It looks to me like I need to parse the build ID from the output of
> "koji latest-build <tag> <name>" and then use "koji buildinfo <id>"
> and then parse that for the Source: line. Is there a better way?
To be honest, I don't know.
> It is if a provenpackager bumped it in the meanwhile.
>
> Now the maintainer has to resolve the fact that they thought they'd
> pushed their work, but what they have locally isn't on the server.
They will have the same issue if the provenpackager bumped the package while
they were working on it without the server having force-pushed anything.
They will either way have to merge or rebase onto the server's HEAD. (IMHO,
rebasing is the right way in this situation, and I think pull with rebase
should be the default, but that is another topic.)
> If you are comfortable using Git, that's trivial to do. But requiring
> every maintainer to be comfortable with that would be a change.
We already require every maintainer to be comfortable with Git conflict
management. The mere act of using Git makes that requirement. See my
previous paragraph.
If we want to excuse maintainers from dealing with conflicts, we have to
switch to a locking-based SCM, with all the problems and drawbacks that come
with that. Otherwise, conflicts can and will happen, there is no (other) way
around them.
> If they just do a git pull they're likely to get conflicts (to the
> %changelog if nothing else) to resolve. Again, many of us will be able
> %to resolve those easily. But for somebody who thought they'd pushed
> %all their changes to the server already, having to re-apply them
> %might not be trivial.
Again, the exact same thing will happen if only the concurrent change
without the CI force push happened.
> Again, I can't believe that "rewriting git history causes issues" even
> needs explanation.
Rewinding to a previous state is a special case of rewriting history, which
causes fewer issues than the general case.
Keep in mind that rewinding can naturally happen if the server had a disk
failure and was restored from an old backup. Git is prepared to deal with
that situation.
>>On the other hand, I am strongly opposed to introducing a rawhide-build
>>branch as you suggest. It does not address the problem at hand and I fail
>>to see what problem it actually addresses.
>
> I don't need to use koji to find out the commit that built, I can just
> use git commands.
That is a feature and not by itself a solution to a problem, because you
have not given a concrete use case for the feature. :-) But I get your
point. Now, is it worth the implementation effort? It does not solve the
problem that started this thread in any case.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
