Git Tip of the Day – find commits (not) merged upstream

Yes, the series is not over, I’m back! 🙂 I don’t give up so easily.

When working with git, you might have come across the situation: You found a bug in a project and decided to write a patch for it. You cloned their git repo, wrote a patch and posted it into their mailing conference. They approved the patch and said that a responsible person would commit it to the master branch soon.

Some weeks later you decided to check whether your patch had been already committed. How do you do that?

You can grep the log for your name, but what if they didn’t assign it as the author name properly? You can grep the log for your commit summary, but what if they changed it?

The answer is: You can use “git cherry”. This command will compare commits in your branch against its tracking branch, and differentiate commits that you have in common from commits that are in your local branch only. However, it does not compare SHA1 commit checksums, it compares patch IDs, which do not change if some commit metadata are changed. Therefore if your very diff stayed intact (although commit metadata changed), “git cherry” would consider them as the same commit.

This is an example that prints changes between my HEAD and its tracking branch:

$ git cherry -v
+ a7b769f180c59c4c14aefdde5c4736c0991af617 README update
+ 63e549e21eae448381bdfed043320cb31add7481 TODO update

Commits appearing only in my local branch are prefixed with “+”, commits appearing in both branches are prefixed with “-“. You can see that I have two commits in my HEAD (pun intended) that were not yet merged upstream and also there are no commits in upstream that would we have in common since I branched it.

I can also specify branch targets. Let’s say I want to compare master and stable branches in my project:

$ git cherry -v stable master
+ 495a213b6e79b48bdfb39e7befa01d18955fefbf cron: decrease scheduling period for koji watcher to 30 min
+ 97e6316647b90e39813ac24df84a76e0f8aaaf57 Changed the overall architecture from hooks to event/watcher + refactored autoqa
- 42fe19e89bbaf275be0c03e64a4c2007838b77c7 initscripts: fix unassigned variable causing crash
+ f875df5f3975aba0945871f2dffb786b3efbfbf7 compose_tree: Add -p PUNGI_ARGS value
+ 6b7aa3701b1d45886f9907fb77aa79dd70099918 remove front-ends (israwhidebroken) directory
+ f76e9d2d1c79e58767cae896aeeef0aadc250639 286 - upgradepath reporting; minor depcheck changes
- e988b38567c5d07a140081ad8a0dd6b0ceb5b462 fix for #292 - When publishing results to bodhi, link to output.log
+ 53aa452e605b61944d6b657bc09813972be2b262 depcheck: download only necessary archs
- a8ee9f32f5df5fcd4c830d28f8253287336b32e7 Update for autoqa-0.4.7
+ 5e26d21fbd9635e517cd90cc95dc8ca0e99ac282 compose_tree: add lorax to the list of packages to run for
+ 36dbec7ed1fb88e99df9a42551eb0c3dcc38a269 koji_utils: allow package download caching

You can see that there are many commits exclusively in master (prefixed with “+”), but some of the commits were cherry-picked to stable and therefore are the same in both branches (prefixed with “-“).

I’m sure you can find other usages.

Happy gitting!

AutoQA: Why Upgradepath test fails so often?

As part of the AutoQA test suite we have an Upgradepath test that ensures that package dependencies won’t be broken when upgrading from one Fedora release to a higher one. There is often some confusion among package maintainers why it fails so often when they propose an update for several Fedora release at once. I’d like to explain.

Here’s an example failure log:

========================================
wordpress-3.1.2-1.fc13 into dist-f13-updates
========================================
[ OK ] dist-f13
	Latest package: wordpress-2.8.6-2.fc13
[FAIL] dist-f14 + dist-f14-updates
	Latest package: wordpress-3.1-1.fc14
	Error: Proposed package must be less than or equal to the latest package
[FAIL] dist-f15 + dist-f15-updates
	Latest package: wordpress-3.1-1.fc15
	Error: Proposed package must be less than or equal to the latest package
[ OK ] dist-f16
	Latest package: wordpress-3.1.2-1.fc16
RESULT: FAILED

The proposed update for F13-updates fails upgradepath, because that package exists in F14(+updates) and F15(+updates) only in lower versions. You wouldn’t be able to upgrade from F13 to F14 correctly if the proposed update landed.

But here’s the tricky part – wordpress maintainer proposed this update also for F14-updates and F15-updates, not just F13. And the obvious question now is:

Why does upgradepath fail for F13, when the same update for F14 and F15 is already proposed?

The answer is:

Because we can’t be sure all of them are going to be pushed at the same time.

Various things might happen. Let’s imagine RelEng team will push the update for F13, but will reject the same update for F14. Or the F14 update will get unpushed in the meantime. Or something else.

This calls for some kind of transactional behavior: “All these updates for F13, F14 and F15 must be pushed at the same time. Or just F15 update can be pushed. But no other way.” Unfortunately we can’t do this, yet. Until we can, there is only one way how to be perfectly sure that upgradepath constraint is fulfilled, and that means the updates for higher Fedora releases must land in the repos first.

Nevertheless we strive to be more user-friendly, especially concerning log readability and test understandability. It’s our current top priority. We will improve the logs to contain helpful information as much as we can, to explain this issue better. Very soon every test will have its own documentation wiki page. Upgradepath documentation is already available, please have a look at AutoQA test/Upgradepath. And we will continue to improve that.

If you have some suggestions, please send them to autoqa-devel. Thanks.

Missing AutoQA logs

Maybe you noticed that some AutoQA result links that are posted as Bodhi comments (example) return “Not Found” error when you try to click on them. They can be just a few days old. That’s unfortunate and we have recently worked on fixing that issue.

First of all, some of our tests got stuck in a loop and generated many GBs of log files. Because our disk space is not immense, it quickly depleted our free space. On top of that, a bug in tmpwatch seemed to prune our log files much more frequently than we asked for. That resulted in deletion of many fresh logs.

We have provided quick fixes for those problems and everything should be back in normal. We aim for keeping the logs for at least a month.

If you have anything on your mind, contact as at autoqa-devel. Thanks.